Major faults caused by inconsistent Master/Slave Data! Please note!

Fault description: master-slave architecture. After the master node goes down, it switches to the slave node. The result is a lot of data loss from the master node (data consistency is not verified before the master node goes down). At that time, there was no synchronization latency, the user cannot be verified in the database when logging on.

Fault description: master-slave architecture. After the master node goes down, it switches to the slave node. The result is a lot of data loss from the master node (data consistency is not verified before the master node goes down). At that time, there was no synchronization latency, the user cannot be verified in the database when logging on.

Fault description: master-slave architecture. After the master node goes down, it switches to the slave node. The result is a lot of data loss from the master node (data consistency is not verified before the master node goes down). At that time, there was no synchronization latency, when a user logs on, the user cannot be verified in the database. As a result, a large number of users cannot log on, resulting in complaints.

I wrote a PPT to check whether the Master/Slave Data is consistent.

The master-slave synchronization is normal. The Hong Kong virtual host does not mean the master-slave data consistency. Why? Here is an example:
The master database has a user, password 123456, and a Hong Kong VM. the user is not in the slave database. If user a does not update the password, you can use show slave status \ G from the database and find that there is no error message because this record is not triggered. Believe it or not, you can try it.

So the following tool exists: (Note! This tool locks the table. The larger the table, the longer the lock time)

Note: The Master-slave architecture must ensure data consistency to avoid serious faults on my side today!

This article is from the "hechun's technical column" blog. Be sure to keep this source