How to Use Percona Toolkit to solve the problem of Mysql master non-synchronization (1)

How to Use Percona Toolkit to solve the problem of Mysql master non-synchronization (1)

For various reasons, data inconsistency often occurs in the mysql Master/Slave architecture, which is roughly attributed to the following categories:

• 1: write data to the slave Database
• 2: Execute non-deterministic query
• 3: Roll Back transactions with mixed transaction tables and non-transaction tables
• 4: binlog or relay log data corruption

The danger of data synchronization to applications is fatal. When the Master/Slave Data is inconsistent, the common solution is to take the slave database offline first, then, we can find a third time in the middle of the night to stop the application and re-execute the synchronization. If the database volume is very large, the workload can be imagined and people will crash. This article describes how to use percona-toolkit to check and re-Synchronize the synchronization status of the mysql master-slave database.

I. Install percona-toolkit

 
 

  
  
# yum -y install perl-Time-HiRes 
  
  
# wget 
  
  
http://www.percona.com/downloads/percona-toolkit/2.2.13/tarball/percona-toolkit-2.2.13.tar.gz 
  
  
# tar -zxvpf percona-toolkit-2.2.13.tar.gz 
  
  
# cd percona-toolkit-2.2.13 
  
  
# perl Makefile.PL 
  
  
# make 
  
  
# make install 
 
 

Ii. Modify the binlog_format parameter of mysql to the row format.

Mysql binlog has three formats: Statement, Mixed, and ROW!

1. Statement:

Each SQL statement that modifies the data is recorded in the binlog.

Advantage: you do not need to record changes in each row, which reduces the binlog volume, saves IO, and improves performance. (The performance and log volume can be reduced compared to the row, which depends on the application's SQL condition. The log volume generated by modifying the same record normally or inserting the row format is smaller than the log volume generated by Statement, however, considering the conditional update operations, as well as the entire table deletion and alter TABLE operations, the ROW format will generate a large number of logs, therefore, when considering whether to use the ROW format log, it should be based on the actual situation of the application, the amount of logs generated will increase, and the IO performance problems .)

Disadvantage: Because only execution statements are recorded, in order that these statements can run correctly on slave, some related information of each statement must be recorded during execution, to ensure that all the statements can get the same results as the execution on the master end in slave. In addition, mysql replication, such as some specific function functions, slave can be consistent with the master, there will be many related problems (such as sleep () function, last_insert_id (), and user-defined functions (udf) problems ).

2. Row

The context information of the SQL statement is not recorded. Only the record that is saved is modified.

Advantage: binlog does not record the context-related information of the executed SQL statement. You only need to record what the record is modified. Therefore, rowlevel logs Clearly record the details of each row of data modification. In addition, there will be no problems in certain situations where stored procedures, functions, trigger calls and triggers cannot be correctly copied.

Disadvantage: When all statements executed are recorded in the log, they are all recorded with modifications recorded in each line. This may produce a large amount of log content, such as an update statement, if you modify multiple records, each modification to the binlog will be recorded, resulting in a large amount of binlog logs. Especially when you execute statements such as alter table, because of the table structure modification, if each record changes, each record in the table is recorded in the log.

3. Mixed

The preceding two levels are used in combination. For general statement modification, binlog is saved in statment format. For example, if statement cannot complete master-slave replication, binlog is saved in row format, mySQL will differentiate the log format of the Record Based on each specific SQL Statement executed, that is, select one between Statement and Row. the row level mode of the new MySQL squadron is also optimized. Not all modifications are recorded by row level, as if the table structure is changed, it will be recorded in statement mode. For statements that modify data such as update or delete, changes to all rows are recorded.

Modify the configuration items of the my. cnf file in the Master/Slave database as follows:

 
 

  
  
binlog_format=ROW