Log management method, server, and database system

Patent metadata

Field	Value
Publication number	US-11748215-B2
Application number	US-202016892590-A
Country	US
Kind code	B2
Filing date	Jun 4, 2020
Priority date	Dec 5, 2017
Publication date	Sep 5, 2023
Grant date	Sep 5, 2023

Abstract

In a log management method performed by a server, the server receives a transaction and generates a command log of the transaction. When detecting the transaction is a multi-partition transaction or a non-deterministic transaction, the server generates a data log of the transaction. When the server is faulty, the server recovers data according to the command log or the data log.

First claim

What is claimed is:

1. A database log management method implemented by a server and comprising:
receiving a first write transaction;
generating a first command log of the first write transaction;
storing the first command log;
detecting that the first write transaction is a first multi-partition transaction for operating at least two partitions;
generating, based on detecting that the first write transaction is the first multi-partition transaction, a first data log of the first write transaction; and
storing the first data log.

2. The database log management method of claim 1 , wherein when the server is faulty, the database log management method further comprises:
obtaining a data snapshot that backs up first data for the server;
obtaining a second command log generated after a generation time point of the data snapshot;
obtaining a second data log of a second write transaction corresponding to the second command log when the second write transaction is a second multi-partition transaction; and
recovering second data by replaying the second data log.

3. The database log management method of claim 1 , further comprising:
receiving a second write transaction;
generating a second command log of the second write transaction;
storing the second command log;
detecting that the second write transaction is a non-deterministic transaction for which at least two execution results are not unique;
generating a second data log of the second write transaction; and
storing the second data log.

4. The database log management method of claim 3 , wherein when the server is faulty, the database log management method further comprises:
obtaining a data snapshot that backs up first data for the server;
obtaining a third command log generated after a generation time point of the data snapshot;
obtaining a third data log of a third write transaction corresponding to the third command log when the third write transaction is a third multi-partition transaction or a third non-deterministic transaction; and
recovering second data by replaying the third data log.

5. The database log management method of claim 3 , further comprising:
sending, after storing the first command log, a first response message of the first write transaction, wherein the first response message indicates that execution of the first write transaction has completed; and
sending, after storing the second command log, a second response message of the second write transaction, wherein the second response message indicates that execution of the second write transaction has completed.

6. The database log management method of claim 1 , further comprising:
sharing a shared storage system with a slave node of the server;
further storing the first command log in the shared storage system; and
further storing the first data log in the shared storage system.

7. The database log management method of claim 1 , further comprising sending the first command log and the first data log to a slave node of the server.

8. A server in a database system and comprising:
a memory configured to store instructions;
a processor coupled to the memory and configured to execute the instructions to cause the server to:
receive a first write transaction;
generate a first command log of the first write transaction;
store the first command log;
detect that the first write transaction is a first multi-partition transaction for operating at least two partitions;
generate, based on detecting that the first write transaction is the first multi-partition transaction, a first data log of the first write transaction; and
store the first data log.

9. The server of claim 8 , wherein when the server is faulty, the processor is further configured to execute the instructions to cause the server to:
obtain a data snapshot that backs up first data for the server;
obtain a second command log generated after a generation time point of the data snapshot;
obtain a second data log of a second write transaction corresponding to the second command log when the second write transaction is a second multi-partition transaction; and
recover second data by replaying the second data log.

10. The server of claim 8 , wherein the processor is further configured to execute the instructions to cause the server to:
receive a second write transaction;
generate a second command log of the second write transaction;
store the second command log;
detect that the second write transaction is a non-deterministic transaction for which at least two execution results are not unique;
generate a second data log of the second write transaction; and
store the second data log.

11. The server of claim 10 , wherein when the server is faulty, the processor is further configured to execute the instructions to cause the server to:
obtain a data snapshot that backs up first data for the server;
obtain a third command log generated after a generation time point of the data snapshot;
obtain a third data log of a third write transaction corresponding to the third command log when the third write transaction is a third multi-partition transaction or a third non-deterministic transaction; and
recover second data by replaying the third data log.

12. The server of claim 10 , wherein the processor is further configured to execute the instructions to cause the server to:
send, after storing the first command log, a first response message of the first write transaction, wherein the first response message indicates that execution of the first write transaction has completed; and
send, after storing the second command log, a second response message of the second write transaction, wherein the second response message indicates that execution of the second write transaction has completed.

13. The server of claim 8 , wherein the processor is further configured to execute the instructions to cause the server to:
share a shared storage system with a slave node of the server;
further store the first command log in the shared storage system; and
further store the first data log in the shared storage system.

14. The server of claim 8 , wherein the processor is further configured to execute the instructions to cause the server to send the first command log and the first data log to a slave node of the server.

15. A database system comprising:
a client configured to send a first write transaction; and
a first server communicatively coupled to the client and configured to:
receive the first write transaction from the client;
generate a first command log of the first write transaction;
store the first command log;
detect that the first write transaction is a first multi-partition transaction for operating at least two partitions;
generate, based on detecting that the first write transaction is the first multi-partition transaction, a first data log of the first write transaction; and
store the first data log.

16. The database system of claim 15 , wherein when the first server is faulty, the first server is further configured to:
obtain a data snapshot that backs up first data for the first server;
obtain a second command log generated after a generation time point of the data snapshot;
obtain a second data log of a second write transaction corresponding to the second command log when the second write transaction is a second multi-partition transaction; and
recover second data by replaying the second data log.

17. The database system of claim 15 , wherein the first server is further configured to:
receive a second write transaction

Assignees

• Huawei Tech Co Ltd

Inventors

• Liang Xiaohao
• Zhang Huimin
• Wang Weisong
• Wang Tieying

Classifications

• G06F11/1471 Primary

  involving logging of persistent data for recovery · CPC title

• G06F11/1469

  Backup restoration techniques · CPC title

• G06F11/1474

  in transactions (updating of structured data in databases G06F16/23) · CPC title

• G06F16/2379

  Updates performed during online database operations; commit processing · CPC title

• G06F2201/84

  Using snapshots, i.e. a logical point-in-time copy of the data · CPC title