Log synchronization method and device, equipment and storage medium

Abstract

The embodiment of the invention discloses a log synchronization method and device, equipment and a storage medium. The method comprises the following steps: a main library generates a to-be-synchronized log packet according to a synchronized log packet sequence number array, a synchronized log sequence value array and a received data modification operation, and sends the to-be-synchronized log packet to each standby library; the standby library carries out replay according to the received to-be-synchronized log packet, and after log packet parameters of the standby library are modified according to the to-be-synchronized log packet, the log packet serial number of the to-be-synchronized log packet and the maximum log sequence value in the to-be-synchronized log packet are fed back to the main library; and the main library updates the synchronized log packet sequence number array and the synchronized log sequence value array according to the received log packet sequence number and the maximum log sequence value. According to the technical scheme, log truncation is allowed when the database breaks down, the availability and reliability of the database cluster are improved, and the running speed of the main database in the database cluster is increased.

Description

technical field [0001] Embodiments of the present invention relate to the technical field of databases, and in particular, to a log synchronization method, device, device, and storage medium. Background technique [0002] With the rapid development of information technology, databases play an extremely important role in daily work, business activities and people's lives. In order to avoid downtime during database use and unable to provide services normally, existing applications often adopt the method of building database clusters, that is, multiple databases are divided into main database and standby database, so that the standby database can still continue when the main database is down. Provide services. [0003] In order to ensure the data synchronization of each database in the database cluster, redo logs will be generated after data modification operations such as adding, deleting, and modifying are performed on the main database, and the redo logs will be sent to the...

AI Technical Summary

Problems solved by technology

[0004] However, under the above mechanism, the persistence of the redo log on the local disk can be equivalent to the persistence of the data page, so the redo log cannot be truncated at will. If you want to truncate the redo log, you need to truncate the redo log The data modification recorded in the log is rolled back from the corresponding data page

For traditional databases, after the redo log is written to the disk, it is not excluded that the data page will also be written to the disk immediately (for example, when the checkpoint is being advanced). If the transaction that executes the data page modification has been committed, these modifications It will be stored in the database persistently (transaction persistence feature). Even if the database fails, these data pages cannot be rolled back after the failure recovery, so traditional databases cannot support log truncation

Based on this feature, when a traditional database cluster supports automatic failover, it must confirm the failure through a third-party arbitration, otherwise there may be a wrong switch and the old master database cannot be added back (for example, the master database and the standby database cannot be added back). Only a network exception occurs between the databases. The main database is still running normally and writing local data. Due to the network failure, the standby database thinks that the main database has failed and automatically switches to the new main database. The data currently written by the old main database is stored in the new primary database The database does not exist, and the old master database cannot truncate the log and roll back the data. The old master database and the new master database have inconsistent data, and cannot rejoin the cluster)

Furthermore, in order to ensure real-time data synchronization between the primary database and the standby database in traditional database clusters, the primary database needs to receive responses from all standby databases after sending redo logs before continuing to generate new redo logs. Data processing delay will greatly affect the running speed of the main library

Images