Secret master from MySQL data inconsistencies

Preface:

MySQL database is currently the most commonly used is the master-slave architecture, high availability architecture is the most evolved through a master-slave architecture. But the master data inconsistencies prone after a long run time from architecture, such as due to misuse can write or copy from the library caused by bug and so on, this article will explore in detail the main emerge from inconsistency and how to solve this problem.

1. From the main reason causing inconsistent

There are many inconsistencies from the main cause of possible causes, following a few simple list:

• Main library binlog format Statement, from the library to perform synchronized to the master-slave may cause inconsistent.
• Make changes before the main library has executed set sql_log_bin = 0, the main library will not be recorded binlog, can not change this part of the data from the database.
• Node is not provided from the read-only, write data is erroneous.
• Main library or from a library of unplanned downtime, downtime can cause binlog or relaylog file is damaged, leading to a master-slave inconsistent.
• Examples of inconsistent versions from the master, the master version is particularly high, low version from the case, the above functions supported by the main database, the database may not support the above function.
• MySQL bug itself cause.

2. From the main inconsistencies repair method

Here are the main method from inconsistent repair, note that this talk is to repair the master instead of repairing inconsistencies from master-slave synchronization errors.

To fix the master-slave inconsistent, we must first find from the main inconsistency, will be given the appropriate repair method according to different situations.

The first case: For example, when executing the script, for faster executed, the script adds set sql_log_bin = 0. Then all data changes the script will not be applied to the library, this time from the master data is inconsistent, the solution is first stopped from the master copy, and then manually execute this script library, master-slave replication that is finally open can.

The second situation: you may not set a read-only library from colleagues because architecture is not clear, made a mistake led to the write data from the database, this situation should be timely feedback and resolve. Solution: If you really need to execute these statements, it is possible to perform in the main library set sql_log_bin = 0, then the statement is executed; if you do not execute these statements, you need to roll back from the library out of previous misuse.

But sometimes the situation is not so simple, you may encounter more cases are: master-slave two instances already running for a long time, one day consistency check found inconsistencies from the master, it is difficult to find the cause and time of occurrence of the specific inconsistencies . So this time should be how to do it, it was said, to redo it again from the library, although this is a solution, but this program slow recovery time, and sometimes from the library also bear part of the query can not be hastily rebuilt. Fix in this case focused on the following talk next.

• Use percona-toolkit tools to assist.

  PT kit contains pt-table-checksum, and pt-table-sync two tools, primarily for detecting whether the main data from the same inconsistencies and repair. This program features high speed of repair, no need to stop the primary from the secondary, the disadvantage is the need for the accumulation of knowledge, if you had less likely to use this tool, it may take time to learn, to test, especially in a production environment, or to be careful in use.
  For how to use, refer to the following links:
  https://www.cnblogs.com/feiren/p/7777218.html

• Manually rebuild inconsistent table.

  For example, we found a few tables from the library and main library data inconsistencies, and that a few relatively large amount of data tables, manual alignment unrealistic data, and redo the entire library is relatively slow, only this time you can redo it few tables from the master to repair inconsistencies. For example: a1 b1 c1 these three tables from the master data inconsistencies, then we can do this:

  1, from the library to stop Slave replication
  mysql> stop slave;

  2, dump These three tables in the main database, and record the sync point and POS binlog
  mysqldump -uroot -p123456 -q --single-transaction --master -data = 2 yourdb a1 b1 c1> ./a1_b1_c1.sql

  3, file view a1_b1_c1.sql, identify and record binlog POS point
  more a1_b1_c1.sql
  e.g. MASTER_LOG_FILE = 'mysql-bin.002974', MASTER_LOG_POS = 55056952;

  4, the a1_b1_c1.sql copied onto Slave machine, and do Change master to point
  mysql> start slave until MASTER_LOG_FILE = ' mysql-bin.002974', MASTER_LOG_POS = 55056952;
  NOTE: me explain, this step is what is meant. Protection of other tables of data is not lost, has been synchronized, the synchronization finished until the end of that point, the data a1, b1, c1 table before the dump has been generated a snapshot, we only need to import to enter, and then synchronize to open.

  5, on introducing a1_b1_c1.sql Slave machine (when opened from the library to make binlog introduced to speed up and to be executed first SQL_LOG_BIN = 0 SET)
  MySQL -uroot--p123456 yourdb <./a1_b1_c1.sql

  6, after the import is complete, you can open the synchronization from the library.
  mysql> start slave;

  So we restored the three tables, and synchronization is also fixed. The disadvantage is that this program needs to be stopped during the import copy from the library, but also acceptable.

There may be other fixes, such as synchronization Navicat for comparison and other tools, but these tools only apply to a small amount of data, when there are tens of millions of data, then this approach is not realistic. Do you have a similar experience it, you can also leave a message at sharing.

3. How to avoid inconsistencies from the master

Through the above description, you probably may know the fix is ​​not easy, so we need to avoid the source, then how do we avoid inconsistencies from the master of it, here are a few suggestions, I hope useful to you.

• Main library using ROW binlog format.
• Main consistency from instance database version.
• Main library check account privileges to control, not perform set sql_log_bin = 0.
• Open read-only from the library, do not allow people write.
• Regular inspection from the main consistency.

to sum up: 

This article details the cause of the main reasons for the inconsistency, the method of repair and how to avoid inconsistencies from the main inconsistency. In particular inconsistency repair method, there may be other solutions, the need to consider the actual situation to select the appropriate method of repair. The original is not easy, I hope that we can support.