Distributed database disaster recovery method based on log pushing

Abstract

The invention discloses a distributed database disaster recovery method based on log pushing, and belongs to a database disaster recovery method. The method comprises the steps of: when a client conducts transaction operation through a main database cluster, enabling the main database cluster to start a transaction log synchronization thread, and synchronously recording the operation of a current transaction as a transaction log; and sending the transaction log to a log pushing instance, and pushing the transaction log to a transaction log table of a standby database cluster by the log pushing instance. Compared with the method that the standby database cluster pulls the transaction logs from the main database cluster in the MySQL database, the method has the advantages that the pulling time is saved, and the data synchronization of the main database cluster and the standby database cluster is more efficient; and in the data pushing process of the main and standby database clusters, abnormal conditions can be processed, so that the transaction log consistency of the main and standby database clusters is ensured, and the risk of data inconsistency of the main and standby database clusters is effectively reduced.

Description

technical field [0001] The present invention relates to a database disaster recovery method, and more specifically, the present invention mainly relates to a distributed database disaster recovery method based on log push. Background technique [0002] In the field of database distributed database, disaster recovery technology is very important to customers, so it has always been one of the hot research directions in the field. At present, the mainstream data synchronization schemes of active and standby database clusters are similar to the data synchronization of MySQL active and standby database clusters. MySQL database mainly consists of three synchronization schemes, namely asynchronous replication, semi-synchronous replication and full synchronous replication. The aforementioned three methods all exist. Their own shortcomings, in asynchronous replication, binlog logs are recorded in the primary database cluster, and the standby database cluster needs to pull binlog logs...

AI Technical Summary

Problems solved by technology

After the main database cluster executes the transaction submitted by the client, it will wait for all the standby database clusters to receive and write the transaction in the replay log before returning to the client. There is no data inconsistency between the main and standby database clusters. The database cluster is returned to the client after the playback is completed, so the performance is very poor

Therefore, there is a certain risk of loss of MySQL database that records binlog logs on the primary database cluster. Although the full synchronous replication strategy can ensure that the data in the primary and standby database clusters is consistent, the performance of full synchronous replication will be poor, and full synchronization Replication also records binlog logs in the primary database cluster. The standby database cluster needs to pull data from the primary database cluster, and then the standby database cluster performs binlog log playback operations.

Images