MySQL 5.7 uses pt-table-sync to repair inconsistent data

Continued from the previous article: MySQL 5.7 uses pt-table-checksum to check master-slave data consistency


If the master-slave data is found to be inconsistent through pt-table-checksum, the data can be synchronized through pt-table-sync.


Principle description:

Data changes are always performed on the master, and then synchronized to the slave, without directly changing the data of the slave. The changes performed on the master are based on the current data on the master and will not change the data on the master. Be careful to back up your data before use to avoid data loss. Before executing execute, it is best to switch to --print or --dry-run to see what data will be changed.

Parameter Description:

parameter
illustrate
--replicate
Specify the table obtained by pt-table-checksum, these two tools will be used almost all the time.
--databases
Specify the database to perform synchronization, multiple separated by commas.
--tables
Specify the table to perform synchronization, multiple separated by commas.
--sync-to-master
Specify a DSN, that is, the slave's IP, and it will automatically find the master through show processlist or show slave status.
h=127.0.0.1
The server address, there are 2 ips in the command, the first time is the address of M, and the second time is the address of Slave.
u=root
account number.
p=123456 
password.
--print 
prints, but does not execute the command.
--execute
Excuting an order.

For the found lines with inconsistent master and slave, use the replace into statement, execute it once in the master library to generate the full binlog of the line, and synchronize it to the slave library, which will repair the slave library based on the master library data;

For the lines that the master library has but the slave library does not have, use replace to insert on the master library (must not be insert);

For rows that are in the slave library but not in the master library, delete them by executing delete in the master library (pt-table-sync strongly recommends that all data repairs be performed only in the master library, and it is not recommended to directly modify the slave library data; but there are also special cases. , which will be described later).


Try to run it first, the --print parameter just prints the result and does not execute the command:

[root@qht131 ~]# pt-table-sync h=172.17.61.131,u=repl,p=repl,P=3306 --databases=l5m --tables=t2 --replicate=percona.checksums --print
Failed to /*!50108 SET @@binlog_format := 'STATEMENT'*/: DBD::mysql::db do failed: Access denied; you need (at least one of) the SUPER privilege(s) for this operation [for Statement "/*!50108 SET @@binlog_format := 'STATEMENT'*/"] at /usr/local/bin/pt-table-sync line 10863.

This tool requires binlog_format=STATEMENT, but the current binlog_format is set to ROW and an error occurred while attempting to change it.  If running MySQL 5.1.29 or newer, setting binlog_format requires the SUPER privilege.  You will need to manually set binlog_format to 'STATEMENT' before running this tool.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle ;host=172.17.61.132;port=3306;mysql_read_default_group=client at /usr/local/bin/pt-table-sync line 10866.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle ;host=172.17.61.131;port=3306;mysql_read_default_group=client at /usr/local/bin/pt-table-sync line 10866.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle ;host=172.17.61.131;port=3306;mysql_read_default_group=client at /usr/local/bin/pt-table-sync line 10866.

The solution to this error is to increase the corresponding permissions on the slave:

slave server:

mysql>  grant select,create,drop,insert,delete,update,alter on percona.* to repl@'172.17.61.%';
Query OK, 0 rows affected (0.00 sec)

mysql> grant SELECT,LOCK TABLES,PROCESS,SUPER on *.* to  repl@'172.17.61.%';
Query OK, 0 rows affected (0.00 sec)

mysql>  flush privileges;
Query OK, 0 rows affected (0.00 sec)

Try again on the main repository:

[root@qht131 ~]# pt-table-sync h=172.17.61.131,u=repl,p=repl,P=3306 --databases=l5m --tables=t2 --replicate=percona.checksums --print
DELETE FROM `l5m`.`t2` WHERE `c4`='34' LIMIT 1 /*percona-toolkit src_db:l5m src_tbl:t2 src_dsn:P=3306,h=172.17.61.131,p=...,u=repl dst_db:l5m dst_tbl:t2 dst_dsn:P=3306,h=172.17.61.132,p=...,u=repl lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:2955 user:root host:qht131*/;

Since the slave library only has one more piece of data than the master library, pt-table-sync will take the master library as the criterion, perform a delete operation event in the master library, and then the slave will apply this event to complete the synchronization.

But when it is actually executed, the following error is encountered:

[root@qht131 ~]# pt-table-sync h=172.17.61.131,u=repl,p=repl,P=3306 --databases=l5m --tables=t2 --replicate=percona.checksums --execute
DELETE command denied to user 'repl'@'qht131' for table 't2' [for Statement "DELETE FROM `l5m`.`t2` WHERE `c4`='34' LIMIT 1 /*percona-toolkit src_db:l5m src_tbl:t2 src_dsn:P=3306,h=172.17.61.131,p=...,u=repl dst_db:l5m dst_tbl:t2 dst_dsn:P=3306,h=172.17.61.132,p=...,u=repl lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3035 user:root host:qht131*/"] at line 10744 while doing l5m.t2 on 172.17.61.132

Since repl does not have delete permissions, the master and slave are given the following permissions:

mysql>  grant select,create,drop,insert,delete,update,alter on *.* to repl@'172.17.61.%';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

Execute it again without a problem

[root@qht131 ~]# pt-table-sync h=172.17.61.131,u=repl,p=repl,P=3306 --databases=l5m --tables=t2 --replicate=percona.checksums --execute

Check the data of the slave library, at this time the inconsistent data has been deleted.

mysql> select * from l5m.t2;
+------+------+------+----+
| c1   | c2   | c3   | c4 |
+------+------+------+----+
|    1 | abc  |   22 | 33 |
+------+------+------+----+
1 row in set (0.00 sec)

It should be noted that the table to be synchronized must have a primary key or a unique index, otherwise an error will occur.


The simplest test is carried out on the pt-table-checksum and pt-table-sync tools. In fact, running this set of commands does not necessarily need to be performed on the main library of the master-slave structure. Any computer in the network segment can be used. To run, the premise is that this tool is installed. In addition, --recursion-method is not specified in pt-table-checksum. At this time, the tool will automatically find the slave library in the master library from show processlist. Of course, you can also use Host and dsn to connect the master and slave libraries. I don't have one. Test both methods.



Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326739373&siteId=291194637