IC, MySQL dual-master architecture, it can be played like this

Friends often ask about the consistency of MySQL dual masters. Let’s talk briefly today.

Why does MySQL use dual-master architecture?

The most common cluster architecture of MySQL is an architecture with one master and multiple slaves, master-slave synchronization, and read-write separation. In this way, the read performance of the database can be expanded and the high availability of the read library can be ensured, but at this time, the write library is still a single point.

In order to ensure the high availability of the MySQL writing database, two main databases can be set up in a MySQL database cluster, and two-way synchronization can be set up to ensure the high availability of the writing database in a redundant writing database.

What are the problems with MySQL dual-master architecture?

If MySQL dual-master architecture provides services at the same time, it may cause data consistency problems. Because there is a time difference in data synchronization, concurrent writing may cause data synchronization to fail and cause data loss.

Take a chestnut:
IC, MySQL dual-master architecture, it can be played like this
As shown in the figure above, suppose that the main database uses auto increment as the self-incrementing primary key:
(1) The two-way synchronization of the two MySQL main databases can be used to ensure the high availability of the main database;
(2) Existing databases in the database The primary key of the record is 1, 2, 3;
(3) A record is inserted in the main library 1, and the primary key is 4, and
data is synchronized with the main library 2 ; (4) Before the data synchronization is successful, the main library 2 also inserted a record, because The data has not been synchronized successfully. The primary key generated by inserting the record is also 4, and the data is also synchronized to the main database 1.
(5) Both the main database 1 and the main database 2 have inserted the record with the primary key 4, and the dual-master synchronization failed, and the data is inconsistent ;

Can it be ensured that the primary keys generated by the two main libraries do not conflict at the MySQL level?

Yes, you only need to set the auto-increment ID of the two main libraries:
(1) Set different initial values;
(2) Set the same increase step size;
IC, MySQL dual-master architecture, it can be played like this

As shown in the figure above:
(1) The two-way synchronization of the two MySQL main libraries can be used to ensure the high availability of the main library;
(2) The initial value of auto-increment of library 1 is 1, and the initial value of auto-increment of library 2 is 2, increasing The step length is 2;
(3) The primary key of data inserted in bank 1 is 1/3/5/7, and the primary key of data inserted in bank 2 is 2/4/6/8, which does not conflict;
(4) After data two-way synchronization, The two main libraries will contain all data;
IC, MySQL dual-master architecture, it can be played like this

As shown in the figure above, the two main libraries will eventually contain all the data of 1/2/3/4/5/6/7/8. Even if one of the main libraries is down, the other main library can guarantee the high writing library. Available.

The above scheme depends on the configuration of the database. Can the application ensure data consistency?

The answer is yes, the application uses a unified ID generator to ensure that ID generation does not conflict.
IC, MySQL dual-master architecture, it can be played like this
As shown in the figure above, when the caller inserts data, it can also solve this problem by bringing in a globally unique ID instead of relying on the auto increment of the database.
Voiceover: How to generate a globally unique ID with an increasing trend without expansion.

The root cause of the inconsistency is to ensure that the two main libraries that are highly available provide services to the outside world. If only one main library provides services to the outside world, the other main library does not usually provide services, and only provides services when the main library is down. Does it eliminate the inconsistency of the above data?
The answer is pessimistic, and it still doesn't work.

The virtual IP+keepalived method is used to ensure the high availability of the main database. Usually only one main database provides services, and data inconsistencies may also occur.
IC, MySQL dual-master architecture, it can be played like this
As shown in the figure above:
(1) Two-way synchronization of the two main MySQL libraries can be used to ensure the high availability of the main library;
(2) Only the main library 1 provides external writing services;
(3) The two main libraries have the same virtual settings. IP, when the main library 1 hangs up or the network is abnormal, the virtual IP automatically drifts, and the standby main library is on top to ensure the high availability of the main library;

During the switching process, since the virtual IP does not change, the switching process is transparent to the caller, but in extreme cases, data inconsistencies may still occur.
IC, MySQL dual-master architecture, it can be played like this
As shown in the figure above:
(1) Two-way synchronization of the two MySQL main libraries can be used to ensure the high availability of the main library, and the same virtual IP is set;
(2) Before the network shakes, the main library 1 provides writing to the upstream Service, a record is inserted, the primary key is 4, and data is synchronized to the backup master database 2;
(3) Suddenly the network of the master database 1 is abnormal. After Keepalived detects the abnormality, virtual IP drift is implemented, and the backup master database 2 starts to provide services;
( 4) Before the data synchronization of primary key 4 was successful, the main database 2 inserted a record and also generated a record with primary key 4, which resulted in inconsistent data;

Is there any way to alleviate the above problems?

Virtual IP drift, data inconsistency caused by the dual-master synchronization delay, in essence, the virtual IP offset needs to be implemented after the dual-master synchronization completes the data.

Use intranet DNS detection to alleviate the above problems:
(1) Use the intranet domain name to connect to the database, for example: db.kg.org;
(2) Set up dual master synchronization for main database 1 and main database 2, instead of using the same virtual IP. Use ip1 and ip2 respectively;
(3) At first db.kg.org points to ip1;
(4) Use a small script to poll and detect the connectivity of the ip1 main library;
(5) When the ip1 main library is abnormal, the script delays A delay of x seconds, wait for the main database 2 to synchronize the data, and then resolve db.kg.org to ip2;
(6) Reconnect the application with the intranet domain name to automatically connect to the ip2 main database and ensure Data consistency;
Voiceover: In essence, this is a compromise between availability and consistency.

to sum up

MySQL main database is highly available, the main database is consistent, some tips:
(1) Dual master synchronization is a common way to ensure the high availability of the write database;
(2) Set the phase synchronization length and different initial values ​​to avoid auto increment Generate conflicting primary keys;
(3) It does not rely on the database, it is a good method for the business caller to generate a global unique ID;
(4) The dual master guarantees the high availability of the writing library, and only one writing library provides services, which cannot completely guarantee consistency;
( 5) Intranet DNS detection can realize that after the main library 1 has a problem, delay a time, and then switch the main library to ensure data consistency, but at the expense of a few seconds of high availability;

I hope everyone has gained, thank you for turning.

The original function is restored, "Glorious".
"Account was fined, a little unhappy"
"Account was fined, the result of the appeal came out, sure enough"

Guess you like

Origin blog.51cto.com/jyjstack/2547663