Principle introduction

MySQL instance supports two data replication (or copy) modes (namely, asynchronous replication and semi-synchronous replication). Raft Financial Baidu AI Cloud Database RDS adopts Raft strong synchronous replication mode. Principles of the three replication modes are as follows:

• Asynchronous: Asynchronous replication refers to the process, in which, if the application sends updating requests (namely data adding, deletion, and modification), the master database immediately responds to the application after completing current actions. Meanwhile, the master database replicates data asynchronously to the backup database. Thus, operations on the master database are not influenced when the backup database is unavailable. However, if the master database incurs downtime when the operation and submission are completed, the data have yet to be sent to the backup database, then there are no submitted transaction modification data in the backup database. In this case, if the backup database is switched to a new master database, it leads to data loss. On the whole, there is a small probability of data inconsistency between the master database and backup database resulting from the unavailable master database.
• Semi-synchronous replication: to resolve data loss in asynchronous replication, MySQL introduces the semi-synchronous replication feature. Semi-synchronous replication refers to the state in which the transaction log needs to be written to the master database and transmitted to at least one backup database and written to this backup database during the MySQL replication process and after the transaction is submitted on the master database. Only after giving a notice to the master database can the transactions on the master database be successfully submitted. In the semi-synchronous replication mode, the transactions submitted on the master database, can be retrieved on at least one backup database. Thus, it helps resolve data loss in asynchronous replication. However, at least one backup database must be subject to data persistence, and confirmation must be sent. Time delay for transaction submission on master database increases, so TPS decreases. If master-backup replication is abnormal, replication mode changes into asynchronous replication. Only after the abnormal situation is resolved, can the replication mode be restored. Thus, the unavailable master database still leads to a small probability of data inconsistency,
• Raft strong synchronous replication: raft data replication mode ensures every data writing is synchronized to most nodes of the cluster. Compared to the traditional MySQL official master-slave asynchronous replication mode, the Raft strong synchronization features strong data consistency. Also, it ensures zero loss of data submitted to the master database after abnormal switching. Also, it puts an end to the split-brain problem (multiple masters alive simultaneously) likely resulting from traditional modes at the time of network fault and further improves the data consistency.

By default, the dual-computer high-availability RDS for MySQL instance adopts asynchronous replication mode. And, the Raft Financial RDS for MySQL instance adopts Raft strong synchronization mode.

Modify data replication mode

Click the instance name to enter the “Basic Information” page, and select “Data Synchronization Mode” and modify it.

Notes: You can view only the data synchronization mode on the read-only instance’s “Basic Information” page. If you need to modify the mode, go to the master instance’s “Basic Information” page.