mysql怎么看主备 mysql 查看主备命令

MySQL实战问题03 mysql如何保证主备一致

MySQL 主备的基本原理主备流程切换

创新互联于2013年成立，先为临猗等服务建站，临猗等地企业，进行企业商务咨询服务。为临猗企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的

当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。

M-S模式中, 为什么建议把备库设为readonly? 有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作； 防止切换逻辑有 bug，比如切换过程中出现双写，造成主备不一致 可以用 readonly 状态，来判断节点的角色。 把备库设置成只读了，还怎么跟主库保持同步更新呢？

因为 readonly 设置对超级 (super) 权限用户是无效的，而用于同步更新的线程，就拥有超级权限。

节点 A 到 B 这条线的内部流程是什么样的

下图画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接

一个事务日志同步的完整过程是这样的: 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。 在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。 主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。 备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。 sql_thread 读取中转日志，解析出日志里的命令，并执行。 binlog 的三种格式对比

三种格式分别是: statement row mixed

为了便于描述 binlog 的这三种格式间的区别, 创建并初始化一个表

mysql CREATE TABLE `t` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `t_modified`(`t_modified`) ) ENGINE=InnoDB; insert into t values(1,1,'2018-11-13'); insert into t values(2,2,'2018-11-12'); insert into t values(3,3,'2018-11-11'); insert into t values(4,4,'2018-11-10'); insert into t values(5,5,'2018-11-09');

删除一行, 分析binlog

mysql delete from t /*comment*/ where a=4 and t_modified='2018-11-10' limit 1; 查询binlog命令: mysql show binlog events in 'master.000001'; 当 binlog_format=statement 时

binlog 里面记录的就是 SQL 语句的原文:

分析一下上图输出的结果: 第一行可以先忽略. 第二行是一个 BEGIN，跟第四行的 commit 对应，表示中间是一个事务； 第三行是真实的执行语句, 在delete命令前,还有一个use test命令, 是mysql自动添加的. 最后一行是一个 COMMIT, 包含一个xid. 如果使用statement格式, 记录到binlog 的是语句原文. 会有什么问题出现呢?

如果delete 带有 limit, 很可能出出现住主备数据库不一致的情况

在主库执行这条 SQL 语句的时候，用的是索引 a；而在备库执行这条 SQL 语句的时候，却使用了索引 t_modified

当 binlog_format= row 时:

与statement相比, begin 与 commit 是一致的, 但是row格式没有记录原文, 而是替换成了两个event, 粉笔是table_map 与 delete_rows

Table_map event，用于说明接下来要操作的表是 test 库的表 t; Delete_rows event，用于定义删除的行为。 使用mysqlbinlog工具分析解析binlog中内容 mysqlbinlog -vv data/master.000001 --start-position=8900;

解析结果:

server id 1，表示这个事务是在 server_id=1 的这个库上执行的。 每个 event 都有 CRC32 的值，这是因为参数 binlog_checksum 设置成了 CRC32。 Table_map event 显示了接下来要打开的表，map 到数字 226。现在我们这条 SQL 语句只操作了一张表，如果要操作多张表呢？每个表都有一个对应的 Table_map event、都会 map 到一个单独的数字，用于区分对不同表的操作。 在 mysqlbinlog 的命令中，使用了 -vv 参数是为了把内容都解析出来，所以从结果里面可以看到各个字段的值（比如，@1=4、 @2=4 这些值）。 binlog_row_image 的默认配置是 FULL，因此 Delete_event 里面，包含了删掉的行的所有字段的值。如果把 binlog_row_image 设置为 MINIMAL，则只会记录必要的信息，在这个例子里，就是只会记录 id=4 这个信息。 最后的 Xid event，用于表示事务被正确地提交了。 为什么会有 mixed 格式的 binlog？为什么会有 mixed 这种 binlog 格式的存在场景？ 因为有些 statement 格式的 binlog 可能会导致主备不一致，所以要使用 row 格式。 但 row 格式的缺点是，很占空间。比如你用一个 delete 语句删掉 10 万行数据，用 statement 的话就是一个 SQL 语句被记录到 binlog 中，占用几十个字节的空间。但如果用 row 格式的 binlog，就要把这 10 万条记录都写到 binlog 中。这样做，不仅会占用更大的空间，同时写 binlog 也要耗费 IO 资源，影响执行速度。 所以，MySQL 就取了个折中方案，也就是有了 mixed 格式的 binlog。mixed 格式的意思是，MySQL 自己会判断这条 SQL 语句是否可能引起主备不一致，如果有可能，就用 row 格式，否则就用 statement 格式。 如何解决双M结构的循环复制问题解决两个节点间的循环复制的问题的逻辑 规定两个库的 server id 必须不同，如果相同，则它们之间不能设定为主备关系； 一个备库接到 binlog 并在重放的过程中，生成与原 binlog 的 server id 相同的新的 binlog； 每个库在收到从自己的主库发过来的日志后，先判断 server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。 按照这个逻辑，如果我们设置了双 M 结构，日志的执行流就会变成这样： 从节点 A 更新的事务，binlog 里面记的都是 A 的 server id； 传到节点 B 执行一次以后，节点 B 生成的 binlog 的 server id 也是 A 的 server id； 再传回给节点 A，A 判断到这个 server id 与自己的相同，就不会再处理这个日志。所以，死循环在这里就断掉了。

MySQL - 主备

在实际的生产中，为了解决Mysql的单点故障，一般都会采用「主备模式」。

MySQL几乎所有的高可用架构，都直接依赖于 binlog。虽然这些高可用架构已经呈现出越来越复杂的趋势，但都是从最基本的一主一备演化过来的。

下图为主备切换流程

在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。

当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。

在状态 1 中，虽然节点 B 没有被直接访问，但是依然建议把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：

图下图 中画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。

在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。

主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。

备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。

sql_thread 读取中转日志，解析出日志里的命令，并执行。

主库需要复制新增binlog到从库才能完成同步，这个同步过程就是同步延迟。主从延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。

「半同步策略」：Master至少会等待一个Slave回应后提交。

「异步策略」：Master不用等待Slave回应就可以提交。

「延迟策略」：Slave要落后于Master指定的时间。

对于不同的业务需求，有不同的策略方案，但是一般都会采用最终一致性，不会要求强一致性，毕竟强一致性会严重影响性能。

如何查询mysql主从ip地址

方法一

点击，电脑桌面上的 开始 --- 选择 运行

在运行程序输入框中输入 “cmd”（注意不要讲引号也复制进去啊）

进入dos界面后，大家再次输入 ipconfig /all 就会出现dos界面上边就有显示自己的电脑ip地址

方法二

打开打开网络和共享中心 查看本地连接，大家也可以直接查看本地连接。这都一样的

打开，本地连接之后 选择属性。 在出现的界面上 选择“详细信息”

在打开的 详细信息 之后就会显示自己的电脑ip地址了

方法三

百度搜索：ip地址查询

查看mysql是否为双机

mysql双机热备实现原理分析，在本文经过深思熟虑和多次用不同的方式实测试后。最后在这篇文章中，用一个小例子来完成mysql双机热备的实现。

Mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份的数据库中。实现mysql数据库的热备份。

要想实现双机的热备，首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都高于3.2。还有一个基本的原则就是作为从数据库的数据版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。

当然要实现mysql双机热备，除了mysql本身自带的REPLICATION功能可以实现外，也可以用Heartbeat这个开源软件来实现。不过本文主要还是讲如何用mysql自带的REPLICATION来实现mysql双机热备的功能。

1. 准备服务器

由于Mysql不同版本之间的（二进制日志）binlog格式可能会不太一样，因此最好的搭配组合是主（Master）服务器的Mysql版本和从（Slave）服务器版本相同或者更低，主服务器的版本肯定不能高于从服务器版本。

本次我用于测试的两台服务器版本都是Mysql-5.5.17。

2. Mysql 建立主－从服务器双机热备配置步骤

2.1环境描述

A服务器（主服务器Master）：59.151.15.36

B服务器（从服务器Slave）：218.206.70.146

主从服务器的Mysql版本皆为5.5.17

Linux环境下

将主服务器需要同步的数据库内容进行备份一份，上传到从服务器上，保证始初时两服务器中数据库内容一致。

不过这里说明下，由于我是利用Mysql在安装后就有的数据库test进行测试的，所以两台服务器里面是没有建立表的，只不分别在test里面建立了同样的一张空表tb_mobile;

Sql语句如下：

mysql create table tb_mobile( mobile VARCHAR(20) comment'手机号码', time timestamp DEFAULT now() comment'时间' );

2.2 主服务器Master配置

2.2.1 创建同步用户

进入mysql操作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。因为从mysql版本3.2以后就可以通过REPLICATION对其进行双机热备的功能操作。

操作指令如下：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

创建好同步连接帐户后，我们可以通过在从服务器（Slave）上用replicat帐户对主服务器（Master）数据库进行访问下，看下是否能连接成功。

在从服务器（Slave）上输入如下指令：

[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456

如果出现下面的结果，则表示能登录成功，说明可以对这两台服务器进行双机热备进行操作。

2.2.2 修改mysql配置文件

如果上面的准备工作做好，那边我们就可以进行对mysql配置文件进行修改了，首先找到mysql配置所有在目录，一般在安装好mysql服务后，都会将配置文件复制一一份出来放到/ect目录下面，并且配置文件命名为：my.cnf。即配置文件准确目录为/etc/my.cnf

(Linux下用rpm包安装的MySQL是不会安装/etc/my.cnf文件的，

至于为什么没有这个文件而MySQL却也能正常启动和作用，在点有两个说法，

第一种说法，my.cnf只是MySQL启动时的一个参数文件，可以没有它，这时MySQL会用内置的默认参数启动，

第二种说法，MySQL在启动时自动使用/usr/share/mysql目录下的my-medium.cnf文件，这种说法仅限于rpm包安装的MySQL，

解决方法，只需要复制一个/usr/share/mysql目录下的my-medium.cnf文件到/etc目录，并改名为my.cnf即可。)

找到配置文件my.cnf打开后，在[mysqld]下修改即可：

[mysqld]

server-id = 1

log-bin=mysql-bin //其中这两行是本来就有的，可以不用动，添加下面两行即可

binlog-do-db = test

binlog-ignore-db = mysql

2.2.3 重启mysql服务

修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。

2.2.4 查看主服务器状态

进入mysql服务后，可通过指令查看Master状态，输入如下指令：

注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。

注：这里使用了锁表，目的是为了产生环境中不让进新的数据，好让从服务器定位同步位置，初次同步完成后，记得解锁。

2.3 从服务器Slave配置

2.3.1修改配置文件

因为这里面是以主－从方式实现mysql双机热备的，所以在从服务器就不用在建立同步帐户了，直接打开配置文件my.cnf进行修改即可，道理还是同修改主服务器上的一样，只不过需要修改的参数不一样而已。如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

2.3.2重启mysql服务

修改完配置文件后，保存后，重启一下mysql服务，如果成功则没问题。

2.3.3用change mster 语句指定同步位置

这步是最关键的一步了，在进入mysql操作界面后，输入如下指令：

mysqlstop slave; //先停步slave服务线程，这个是很重要的，如果不这样做会造成以下操作不成功。

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

注：master_log_file, master_log_pos由主服务器（Master）查出的状态值中确定。也就是刚刚叫注意的。master_log_file对应File, master_log_pos对应Position。Mysql 5.x以上版本已经不支持在配置文件中指定主服务器相关选项。

遇到的问题，如果按上面步骤之后还出现如下情况：

则要重新设置slave。指令如下

mysqlstop slave;

mysqlreset slave;

之后停止slave线程重新开始。成功后，则可以开启slave线程了。

mysqlstart slave;

2.3.4查看从服务器（Slave）状态

用如下指令进行查看

mysql show slave status\G;

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

2.4 测试同步

之前开始已经说过了在数据库test只有一个表tb_mobile没有数据，我们可以先查看下两服务器的数据库是否有数据：

Master:59.151.15.36

Slave:218.206.70.146

好了，现在可以在Master服务器中插入数据看下是否能同步。

Master:59.151.15.36

Slave:218.206.70.146

可以从上面两个截图上看出，在Master服务器上进行插入的数据在Slave服务器可以查到，这就表示双机热备配置成功了。

3. Mysql 建立主－主服务器双机热备配置步骤

服务器还是用回现在这两台服务器

3.1创建同步用户

同时在主从服务器建立一个连接帐户，该帐户必须授予REPLIATION SLAVE权限。这里因为服务器A和服务器B互为主从，所以都要分别建立一个同步用户。

服务器A：

mysql grant replication slave on *.* to 'replicate'@'218.206.70.146' identified by '123456';

mysql flush privileges;

服务器B：

mysql grant replication slave on *.* to 'replicate'@'59.151.15.36' identified by '123456';

mysql flush privileges;

3.2修改配置文件my.cnf

服务器A

[mysqld]

server-id = 1

log-bin=mysql-bin

binlog-do-db = test

binlog-ignore-db = mysql

#主－主形式需要多添加的部分

log-slave-updates

sync_binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

replicate-do-db = test

replicate-ignore-db = mysql,information_schema

服务器B：

[mysqld]

server-id = 2

log-bin=mysql-bin

master-slave need

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

#主－主形式需要多添加的部分

binlog-do-db = test

binlog-ignore-db = mysql

log-slave-updates

sync_binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

3.3分别重启A服务器和B服务器上的mysql服务

重启服务器方式和上面的一样，这里就不做讲解了。

3.4分别查A服务器和B服务器作为主服务器的状态

服务器A：

服务器B：

3.5分别在A服务器和B服务器上用change master to 指定同步位置

服务器A：

mysqlchange master to

master_host='218.206.70.146',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000011 ',master_log_pos=497;

服务器B：

mysqlchange master to

master_host='59.151.15.36',master_user='replicate',master_password='123456',

master_log_file=' mysql-bin.000016 ',master_log_pos=107;

3.6 分别在A和B服务器上重启从服务线程

mysqlstart slave;

3.7 分别在A和B服务器上查看从服务器状态

mysqlshow slave status\G;

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

3.8 测试主－主同步例子

测试服务器A：

在服务器A上插入一条语句如下图所示：

之后在服务器B上查看是否同步如下图所示：

测试服务器B：

在服务器B上插入一条语句如下图所示：

然后在从服务器A上查看是否有同步数据如下图所示：

最后从结果可以看出主－主形式的双机热备是能成功实现的。

4. 配置参数说明

Server-id

ID值唯一的标识了复制群集中的主从服务器，因此它们必须各不相同。Master_id必须为1到232－1之间的一个正整数值，slave_id值必须为2到232－1之间的一个正整数值。

Log-bin

表示打开binlog，打开该选项才可以通过I/O写到Slave的relay-log，也是可以进行replication的前提。

Binlog-do-db

表示需要记录二进制日志的数据库。如果有多个数据可以用逗号分隔，或者使用多个binlog-do-dg选项。

Binglog-ingore-db

表示不需要记录二进制日志的数据库，如果有多个数据库可用逗号分隔，或者使用多binglog-ignore-db选项。

Replicate-do-db

表示需要同步的数据库，如果有多个数据可用逗号分隔，或者使用多个replicate-do-db选项。

Replicate-ignore-db

表示不需要同步的数据库，如果有多个数据库可用逗号分隔，或者使用多个replicate-ignore-db选项。

Master-connect-retry

master-connect-retry=n表示从服务器与主服务器的连接没有成功，则等待n秒（s）后再进行管理方式（默认设置是60s）。如果从服务器存在mater.info文件，它将忽略些选项。

Log-slave-updates

配置从库上的更新操作是否写入二进制文件，如果这台从库，还要做其他从库的主库，那么就需要打这个参数，以便从库的从库能够进行日志同步。

Slave-skip-errors

在复制过程，由于各种原因导致binglo中的sql出错，默认情况下，从库会停止复制，要用户介入。可以设置slave-skip-errors来定义错误号，如果复制过程中遇到的错误是定义的错误号，便可以路过。如果从库是用来做备份，设置这个参数会存在数据不一致，不要使用。如果是分担主库的查询压力，可以考虑。

Sync_binlog=1 Or N

Sync_binlog的默认值是0，这种模式下，MySQL不会同步到磁盘中去。这样的话，Mysql依赖操作系统来刷新二进制日志binary log，就像操作系统刷新其他文件的机制一样。因此如果操作系统或机器（不仅仅是Mysql服务器）崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，可以使用sync_binlog全局变量，使binlog在每N次binlog写入后与硬盘同步。当sync_binlog变量设置为1是最安全的，因为在crash崩溃的情况下，你的二进制日志binary log只有可能丢失最多一个语句或者一个事务。但是，这也是最慢的一种方式（除非磁盘有使用带蓄电池后备电源的缓存cache,使得同步到磁盘的操作非常快）。

即使sync_binlog设置为1，出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，Mysql服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在binlog中。可以用-innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。（注释：在Mysql 5.1版本中不需要-innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的binlog(sync_binlog=1)和（默认情况为真）InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，Mysql服务器从binlog剪切回滚的InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步（不接收回滚的语句）。

Auto_increment_offset和Auto_increment_increment

Auto_increment_increment和auto_increment_offset用于主－主服务器（master-to-master）复制，并可以用来控制AUTO_INCREMENT列的操作。两个变量均可以设置为全局或局部变量，并且假定每个值都可以为1到65,535之间的整数值。将其中一个变量设置为0会使该变量为1。

这两个变量影响AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset确定AUTO_INCREMENT列值的起点。

如果auto_increment_offset的值大于auto_increment_increment的值，则auto_increment_offset的值被忽略。例如：表内已有一些数据，就会用现在已有的最大自增值做为初始值。

mysql主备切换是什么意思？

这一般是数据库的安全策略，对于一些安全性要求比较高的系统，数据库通常是由主服务器和备份服务器组成，主备同时运行，主服务器有数据改动后，立刻会同步到备份服务器。所以在日常运维工作中，为了防患于未然，经常会进行主备切换，就是把生产对接的服务器从主数据库切换到备份库上，使用备份库运行一段时间，看看备份库运行是否正常，数据是否正确等。

切换的操作只需将连接池中，数据库服务器的Ip换成备份库Ip就可以了。

MySQL主备库数据一致性校验及修复

很多时候需要把一个从库提升为主库，但对从库和主库的数据一致性不敢保证，这时我们就可以利用 pt-table-checksum来检查主库数据的一致性，如果存在不一致的数据，我们可以利用pt-table-sync来修复这些不一致的数据。

在主（master）上通过执行校验的查询对复制的一致性进行检查，对比主从的校验值，从而产生结果。

下面通过实际的例子来解释该工具如何使用：

主库（10.8.23.209）数据：

从库（10.8.23.208）数据：

从库（10.8.23.210）数据：

很明显主备数据不一致，我们使用工具来检测下：

校验命令参数解释：

校验结果字段解释：

好了，命令以及常用参数都介绍了，一起解释下上面执行的效果，通过DIFFS 是1 就可以看出主从的表数据不一致。怎么不一致呢？ 通过指定—replicate=test.checksums 参数，就说明把检查信息都写到了checksums表中。

进入备库（10.8.23.208）中查看checksums表的信息：

进入备库（10.8.23.210）中查看checksums表的信息：

通过上面找到了这些不一致的数据，如何修复呢？利用另外一个工具 pt-table-sync。

高效的同步MySQL表之间的数据，他可以做单向和双向同步的表数据。他可以同步单个表，也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。接着上面的复制情况，主库和从库的aaa表数据不一致，需要修复。

参数解释：

命令介绍完了，一起解释下执行的效果：通过（--print）打印出来了修复数据的sql语句，可以手动的去从行执行，让他们数据保持一致性。那能否直接执行？当然可以，通过(--execute)

没发现任何异常，然后检查主从数据的一致性：

主库（10.8.23.209）数据：

从库（10.8.23.208）数据：

从库（10.8.23.210）数据：

OK，数据已经保持一致了。

不过建议还是--print 打印出来的好，这样就可以知道那些数据有问题，可以人为的干预下。

不然直接执行了，出现问题之后不好处理。总之还是在处理之前做好数据的备份工作。