MySQL主从复制故障案例二

解决思路：

1，登录从库 

show processlist；

查看两个线程的更新状态

结果说明：

之前主从同步正常

分别登录其余2个从库32,33查看：

cat   /data/3306/data/master.infocat   /data/3307/data/master.info

比较，那个POS最大，说明更接近主库，那么我们就选举此slave作为新的master。

或者利用半同步技术，直接选举实时同步了的这个库为新的master

如果，master down掉，此时master还在有写入，我们需要将master的binlog拉到新选中的slave，

进行数据补全，在把其他slave执行新选中的master，使其继续同步。

切换步骤以及注意事项：

1，确保所有的relay_log 全部更新完毕

在每个从库执行

stop slave io_thread；show processlist；直达看到Has read all relay log; 表示从库更新都执行完毕；

2，登录

新选举的master（也就是旧的一个slave），执行以下命令

stop slave;reset master;quit;

3,进入新选举的slave数据目录，删除master.info relay-log.info ，防止继续从旧的master读数据

cd   /data/3306/datarm -rf  master.info relay-log.info

检查授权表，read-only 等参数，需要删除

4，提升次新选举的从库为主库

vim  /data/3306/my.cnf

开启binlog：

log-bin = mysql-bin如果存在以下参数，一定要删除log-slave-updatesread-only--replication-do-db     --replication-ignore-db  --replication-do-table    --replication-ignore-table --replication-wild-do-table  --replication-wild-ignore-table

重启服务、提升主库完毕

5，如果主库服务器没宕，需要去主库拉去binlog，补全主库的从库

6，其他从库操作

检查（同步user，rep均存在，意思就是保证其他slave有权限连接新的master）

登录slave：

stop slavechange master to master_host=‘new_master_ip‘;如果不同步，就指定POSstart slave；show slave statusG；

++++++++++++主库宕机切换成功

7，修改程序配置文件，将之前的masterIP更换为新的masterIP

   重启服务

本文出自 “crazy_sir” 博客，请务必保留此出处http://douya.blog.51cto.com/6173221/1795367

MySQL主从复制故障案例二

标签：master   slave   一主多从   故障切换   

小编还为您整理了以下内容，可能对您也有帮助：

关于mysql 主从复制的错误

项目上 MySQL 还原 SQL 备份经常会碰到一个错误如下，且通常出现在导入视图、函数、存储过程、事件等对象时，其根本原因就是因为导入时所用账号并不具有SUPER 权限，所以无法创建其他账号的所属对象。ERROR 1227 (42000) : Access denied; you need (at least one of) the SUPER privilege(s) for this operation常见场景：1. 还原 RDS 时经常出现，因为 RDS 不提供 SUPER 权限；2. 由开发库还原到项目现场，账号权限等有所不同。

处理方式：

1. 在原库中批量修改对象所有者为导入账号或修改 SQL SECURITY 为 Invoker；2. 使用 mysqlmp 导出备份，然后将 SQL 文件中的对象所有者替换为导入账号。
二、问题原因我们先来看下为啥会出现这个报错，那就得说下 MySQL 中一个很特别的权限控制机制，像视图、函数、存储过程、触发器等这些数据对象会存在一个 DEFINER 和一个 SQL SECURITY 的属性，如下所示：

--视图定义CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW v_test




--函数定义CREATE DEFINER=`root`@`%` FUNCTION `f_test()` RETURNS varchar(100) SQL SECURITY DEFINER




--存储过程定义CREATE DEFINER=`root`@`%` PROCEDURE `p_test`() SQL SECURITY DEFINER




--触发器定义CREATE DEFINER=`root`@`%` trigger t_test




--事件定义CREATE DEFINER=`root`@`%` EVENT `e_test`

DEFINER：对象定义者，在创建对象时可以手动指定用户，不指定的话默认为当前连接用户；

SQL SECURITY：指明以谁的权限来执行该对象，有两个选项，一个为 DEFINER，一个为 INVOKER，默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行； INVOKER：表示按调用者的权限来执行。

如果导入账号具有 SUPER 权限，即使对象的所有者账号不存在，也可以导入成功，但是在查询对象时，如果对象的 SQL SECURITY 为 DEFINER，则会报账号不存在的报错。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist




三、改写内容上述这个 DEFINER 问题，个人想到最简单的解决方式就是 mysqlmp 导出时直接摘除掉相关属性，但是 mysqlmp 本身并不提供对应参数，所以比较蛋疼，无论是原库走脚本变更或是备份后修改 SQL 文件都不是非常方便，尤其是触发器的 DEFINER，只能先 DROP 再 CREATE 才可以变更。只能看下是否可以从 mysqlmp 源码中去掉 DEFINER 定义。本次 mysqlmp 改写主要有 2 个目的：1. 摘取备份中视图、函数、存储过程、触发器等对象的 DEFINER 定义；2. 尝试加上比较简单的备份进度显示（原生 mysqlmp 的 verbose 参数不是非常清晰，想要实现 navicate 备份时的那种行数显示）。

改写好处：1. 可以避免还原时遇到 DEFINER 报错相关问题；2. 根据输出信息知道备份是否正常进行，防止备份中遇到元数据锁无法获取然后一直卡住的情况。

关于mysql 主从复制的错误

项目上 MySQL 还原 SQL 备份经常会碰到一个错误如下，且通常出现在导入视图、函数、存储过程、事件等对象时，其根本原因就是因为导入时所用账号并不具有SUPER 权限，所以无法创建其他账号的所属对象。ERROR 1227 (42000) : Access denied; you need (at least one of) the SUPER privilege(s) for this operation常见场景：1. 还原 RDS 时经常出现，因为 RDS 不提供 SUPER 权限；2. 由开发库还原到项目现场，账号权限等有所不同。

处理方式：

1. 在原库中批量修改对象所有者为导入账号或修改 SQL SECURITY 为 Invoker；2. 使用 mysqlmp 导出备份，然后将 SQL 文件中的对象所有者替换为导入账号。
二、问题原因我们先来看下为啥会出现这个报错，那就得说下 MySQL 中一个很特别的权限控制机制，像视图、函数、存储过程、触发器等这些数据对象会存在一个 DEFINER 和一个 SQL SECURITY 的属性，如下所示：

--视图定义CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW v_test




--函数定义CREATE DEFINER=`root`@`%` FUNCTION `f_test()` RETURNS varchar(100) SQL SECURITY DEFINER




--存储过程定义CREATE DEFINER=`root`@`%` PROCEDURE `p_test`() SQL SECURITY DEFINER




--触发器定义CREATE DEFINER=`root`@`%` trigger t_test




--事件定义CREATE DEFINER=`root`@`%` EVENT `e_test`

DEFINER：对象定义者，在创建对象时可以手动指定用户，不指定的话默认为当前连接用户；

SQL SECURITY：指明以谁的权限来执行该对象，有两个选项，一个为 DEFINER，一个为 INVOKER，默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行； INVOKER：表示按调用者的权限来执行。

如果导入账号具有 SUPER 权限，即使对象的所有者账号不存在，也可以导入成功，但是在查询对象时，如果对象的 SQL SECURITY 为 DEFINER，则会报账号不存在的报错。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist




三、改写内容上述这个 DEFINER 问题，个人想到最简单的解决方式就是 mysqlmp 导出时直接摘除掉相关属性，但是 mysqlmp 本身并不提供对应参数，所以比较蛋疼，无论是原库走脚本变更或是备份后修改 SQL 文件都不是非常方便，尤其是触发器的 DEFINER，只能先 DROP 再 CREATE 才可以变更。只能看下是否可以从 mysqlmp 源码中去掉 DEFINER 定义。本次 mysqlmp 改写主要有 2 个目的：1. 摘取备份中视图、函数、存储过程、触发器等对象的 DEFINER 定义；2. 尝试加上比较简单的备份进度显示（原生 mysqlmp 的 verbose 参数不是非常清晰，想要实现 navicate 备份时的那种行数显示）。

改写好处：1. 可以避免还原时遇到 DEFINER 报错相关问题；2. 根据输出信息知道备份是否正常进行，防止备份中遇到元数据锁无法获取然后一直卡住的情况。

mysql 主从复制报错,不知道是什么原因

1、从库上看到如下错误

mysql> show slave statusG;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.18.10.11                  Master_User: rep                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000021          Read_Master_Log_Pos: 273               Relay_Log_File: mysql-relay-bin.000051                Relay_Log_Pos: 336        Relay_Master_Log_File: mysql-bin.000021             Slave_IO_Running: Yes            Slave_SQL_Running: No                从库SQL线程已经停止              Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 1007              报错（错误代码1007）                   Last_Error: Error ‘Can‘t create database ‘shaw‘; database exists‘ on query. Default database: ‘shaw‘. Query: ‘create database shaw‘                 Skip_Counter: 0          Exec_Master_Log_Pos: 190              Relay_Log_Space: 721              Until_Condition: None               Until_Log_File:                 Until_Log_Pos: 0           Master_SSL_Allowed: No           Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: NULLMaster_SSL_Verify_Server_Cert: No                Last_IO_Errno: 0                Last_IO_Error:                Last_SQL_Errno: 1007               Last_SQL_Error: Error ‘Can‘t create database ‘shaw‘; database exists‘ on query. Default database: ‘shaw‘. Query: ‘create database shaw‘  Replicate_Ignore_Server_Ids:              Master_Server_Id: 11 row in set (0.00 sec)

2、查看错误代码，确定错误类型

3、根据错误提示和错误代码，我们可以确定，从库已经有"shaw",这个库，导致同步主库上的"shaw"库时，发生冲突

4、解决方法（从库上操作）

mysql> stop slave;Query OK, 0 rows affected (0.00 sec)mysql> set global sql_slave_skip_counter=1;Query OK, 0 rows affected (0.00 sec)mysql> start slave;Query OK, 0 rows affected (0.00 sec)

5、再次查看状态（从库）

mysql> show slave statusG;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.18.10.11                  Master_User: rep                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000021          Read_Master_Log_Pos: 273               Relay_Log_File: mysql-relay-bin.000052                Relay_Log_Pos: 253        Relay_Master_Log_File: mysql-bin.000021             Slave_IO_Running: Yes            Slave_SQL_Running: Yes              Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                   Last_Error:                  Skip_Counter: 0          Exec_Master_Log_Pos: 273              Relay_Log_Space: 721              Until_Condition: None               Until_Log_File:                 Until_Log_Pos: 0           Master_SSL_Allowed: No           Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No                Last_IO_Errno: 0                Last_IO_Error:                Last_SQL_Errno: 0               Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 11 row in set (0.00 sec)

6、测试主从同步是否正常

mysql> show databases;    主库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || shaw               || test               |+--------------------+

mysql> show databases;    从库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || shaw               || test               |+--------------------+

mysql> drop database shaw;        主库上删除数据Query OK, 0 rows affected (0.01 sec)mysql> show databases;+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || test               |+--------------------+

mysql> show databases;        从库已经同步主库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || test               |+--------------------+

mysql主从复制-故障案例一

标签：

mysql 主从复制报错,不知道是什么原因

1、从库上看到如下错误

mysql> show slave statusG;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.18.10.11                  Master_User: rep                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000021          Read_Master_Log_Pos: 273               Relay_Log_File: mysql-relay-bin.000051                Relay_Log_Pos: 336        Relay_Master_Log_File: mysql-bin.000021             Slave_IO_Running: Yes            Slave_SQL_Running: No                从库SQL线程已经停止              Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 1007              报错（错误代码1007）                   Last_Error: Error ‘Can‘t create database ‘shaw‘; database exists‘ on query. Default database: ‘shaw‘. Query: ‘create database shaw‘                 Skip_Counter: 0          Exec_Master_Log_Pos: 190              Relay_Log_Space: 721              Until_Condition: None               Until_Log_File:                 Until_Log_Pos: 0           Master_SSL_Allowed: No           Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: NULLMaster_SSL_Verify_Server_Cert: No                Last_IO_Errno: 0                Last_IO_Error:                Last_SQL_Errno: 1007               Last_SQL_Error: Error ‘Can‘t create database ‘shaw‘; database exists‘ on query. Default database: ‘shaw‘. Query: ‘create database shaw‘  Replicate_Ignore_Server_Ids:              Master_Server_Id: 11 row in set (0.00 sec)

2、查看错误代码，确定错误类型

3、根据错误提示和错误代码，我们可以确定，从库已经有"shaw",这个库，导致同步主库上的"shaw"库时，发生冲突

4、解决方法（从库上操作）

mysql> stop slave;Query OK, 0 rows affected (0.00 sec)mysql> set global sql_slave_skip_counter=1;Query OK, 0 rows affected (0.00 sec)mysql> start slave;Query OK, 0 rows affected (0.00 sec)

5、再次查看状态（从库）

mysql> show slave statusG;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.18.10.11                  Master_User: rep                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000021          Read_Master_Log_Pos: 273               Relay_Log_File: mysql-relay-bin.000052                Relay_Log_Pos: 253        Relay_Master_Log_File: mysql-bin.000021             Slave_IO_Running: Yes            Slave_SQL_Running: Yes              Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                   Last_Error:                  Skip_Counter: 0          Exec_Master_Log_Pos: 273              Relay_Log_Space: 721              Until_Condition: None               Until_Log_File:                 Until_Log_Pos: 0           Master_SSL_Allowed: No           Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No                Last_IO_Errno: 0                Last_IO_Error:                Last_SQL_Errno: 0               Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 11 row in set (0.00 sec)

6、测试主从同步是否正常

mysql> show databases;    主库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || shaw               || test               |+--------------------+

mysql> show databases;    从库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || shaw               || test               |+--------------------+

mysql> drop database shaw;        主库上删除数据Query OK, 0 rows affected (0.01 sec)mysql> show databases;+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || test               |+--------------------+

mysql> show databases;        从库已经同步主库数据+--------------------+| Database           |+--------------------+| information_schema || gamedb             || mysql              || performance_schema || test               |+--------------------+

mysql主从复制-故障案例一

标签：

mysql的主从复制，linux重启后遇到问题。

主机的mysql重启，但是你的从机mysql肯定是没重启才出现binlog索引不一致的现象，我认为是，从机mysql在主机重启之前slave_io_running线程始终保持和主机通信，传输binlog的更新。当主机挂掉之后，slave_io_running一直等待，状态变成NO，整个复制就会停掉，应该说是处于sleep状态，后来主机恢复，从机是没法辨别的，只能stop slave 然后再start，或者change master操作下，实在不行，只能重启从机的mysql了

为什么mysql主从复制,从刚开始能复制一会就不行了

1. 在有主键或者唯一键的情况下，Slave 重放 Binlog 并不会去比较检索到的记录的每一列是否和BI相同，因此如果 Slave 和 Master 存在数据不一致，会直接覆盖 Slave 的数据而不会报错。
2. 在没有主键或者唯一键的情况下，Hash Scan / Hash Scan Over Index 的执行效率 在理论上分析高于 Table Scan 和Index Scan 。
3. 在没有主键或者唯一键的情况下，Slave 选择的二级索引是第一个所有的列都在 BI 中存在的索引，不一定是 Master 执行计划所选择的索引。

为什么mysql主从复制,从刚开始能复制一会就不行了

1. 在有主键或者唯一键的情况下，Slave 重放 Binlog 并不会去比较检索到的记录的每一列是否和BI相同，因此如果 Slave 和 Master 存在数据不一致，会直接覆盖 Slave 的数据而不会报错。
2. 在没有主键或者唯一键的情况下，Hash Scan / Hash Scan Over Index 的执行效率 在理论上分析高于 Table Scan 和Index Scan 。
3. 在没有主键或者唯一键的情况下，Slave 选择的二级索引是第一个所有的列都在 BI 中存在的索引，不一定是 Master 执行计划所选择的索引。

MySQL中主从复制不同步?

我也遇到了这个问题，我是这样解决的：
第一show variables like '%server_id%';看看是不是没有设置成功
第二看看是不是数据库的版本不同，

MySQL中主从复制不同步?

我也遇到了这个问题，我是这样解决的：
第一show variables like '%server_id%';看看是不是没有设置成功
第二看看是不是数据库的版本不同，

mysql主从复制发生误操作怎么恢复

mysql主从同步常见异常及恢复方法

1. 一般的异常只需要跳过一步即可恢复
>slave stop;
>SET GLOBAL sql_slave_skip_counter = 1;
>slave start;

2.断电导致主从不能同步时，通主库的最后一个bin-log日志进行恢复
在主库服务器上，mysqlbinlog mysql-bin.xxxx > binxxxx.txt
tail -n 100000 binxxxx.txt > tail-binxxxx.txt
vim tail-binxxxx.txt 打开tail-binxxxx.txt文件找到最后一个postion值
然后在从库上，change host to 相应正确的值
>slave stop;
>change master to master_host='ip', master_user='username', master_password='password', master_log_file='mysql-bin.xxxx', master_log_pos=xxxx;
>slave start;
>show slave status\G;

3.主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定
略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断
[mysqld]
slave-skip-errors = 1062,1032,1060

mysql主从复制发生误操作怎么恢复

mysql主从同步常见异常及恢复方法

1. 一般的异常只需要跳过一步即可恢复
>slave stop;
>SET GLOBAL sql_slave_skip_counter = 1;
>slave start;

2.断电导致主从不能同步时，通主库的最后一个bin-log日志进行恢复
在主库服务器上，mysqlbinlog mysql-bin.xxxx > binxxxx.txt
tail -n 100000 binxxxx.txt > tail-binxxxx.txt
vim tail-binxxxx.txt 打开tail-binxxxx.txt文件找到最后一个postion值
然后在从库上，change host to 相应正确的值
>slave stop;
>change master to master_host='ip', master_user='username', master_password='password', master_log_file='mysql-bin.xxxx', master_log_pos=xxxx;
>slave start;
>show slave status\G;

3.主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定
略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断
[mysqld]
slave-skip-errors = 1062,1032,1060

运维mysql主从复制集群中,遇到过哪些问题,如何解决

group_replication_member_expel_timeout 指定组复制组成员在产生怀疑之后，从组中排除怀疑失败的成员之前等待的时间（以秒为单位）。在产生怀疑之前的最初 5 秒检测时间不计入该时间。直到并包括 MySQL 8.0.20 在内，group_replication_member_expel_timeout 默认值均为 0，这意味着没有等待时间，并且在 5 秒钟的检测时间结束后，可疑成员应立即被驱逐。从 MySQL 8.0.21 开始，该值默认为 5，这意味着在 5 秒钟的检测时间后如果该节点还是不正常，那会在等 5 秒钟，如果可疑成员还是不正常，超过这个时间将被驱逐。
为验证该参数对集群影响，我们通过实验模拟不同时长的网络延迟，然后调整group_replication_member_expel_timeout 值观察该参数值对集群驱逐故障节点的影响。

运维mysql主从复制集群中,遇到过哪些问题,如何解决

group_replication_member_expel_timeout 指定组复制组成员在产生怀疑之后，从组中排除怀疑失败的成员之前等待的时间（以秒为单位）。在产生怀疑之前的最初 5 秒检测时间不计入该时间。直到并包括 MySQL 8.0.20 在内，group_replication_member_expel_timeout 默认值均为 0，这意味着没有等待时间，并且在 5 秒钟的检测时间结束后，可疑成员应立即被驱逐。从 MySQL 8.0.21 开始，该值默认为 5，这意味着在 5 秒钟的检测时间后如果该节点还是不正常，那会在等 5 秒钟，如果可疑成员还是不正常，超过这个时间将被驱逐。
为验证该参数对集群影响，我们通过实验模拟不同时长的网络延迟，然后调整group_replication_member_expel_timeout 值观察该参数值对集群驱逐故障节点的影响。

mysql2016数据库表复制粘贴报错,如何终止导入?

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：
场景 1
如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。
修复步骤：
在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；
恢复到从库；
启动复制。
这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）
解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。
正确的修复步骤：
1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；
2. 设置复制过滤，过滤表 t：
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');
3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）;
START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';
4. 删除复制过滤，正常启动复制。
注意事项：这里要用 mysqlmp --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2
如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：
在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；
停止从库复制，GTID为 aaaa:1-20000；
恢复表 t 到从库；
启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。
解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。
正确修复步骤：
对表 t 加读锁；
在主库上备份表 t；
停止从库复制，恢复表 t；
启动复制；
解锁表 t。
如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

mysql2016数据库表复制粘贴报错,如何终止导入?

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：
场景 1
如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。
修复步骤：
在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；
恢复到从库；
启动复制。
这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）
解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。
正确的修复步骤：
1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；
2. 设置复制过滤，过滤表 t：
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');
3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）;
START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';
4. 删除复制过滤，正常启动复制。
注意事项：这里要用 mysqlmp --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2
如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：
在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；
停止从库复制，GTID为 aaaa:1-20000；
恢复表 t 到从库；
启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。
解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。
正确修复步骤：
对表 t 加读锁；
在主库上备份表 t；
停止从库复制，恢复表 t；
启动复制；
解锁表 t。
如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

故障分析 | MySQL 从机故障重启后主从同步报错案例分析

MySQL 从库所在主机故障重启后，sql_thread 线程报错：

通过报错信息可知，worker 线程在回放事务 '471c2974-f9bb-11eb-afb1-52540010fb89:88313207' 时，由于要插入的记录主键冲突报错。

主机重启前，主从同步正常，主机重启后，主从同步由于主键冲突报错，对比了冲突主键所在行记

录在主从库是一致的，初步分析事务 '471c2974-f9bb-11eb-afb1-52540010fb89:88313207' 在主机故

障前已经在从库进行了回放，那为何事务会重复回放呢？

在开启gtid模式下，如果指定 master_auto_position=1，start slave 时，从库会把

Retrieved_Gtid_Set 和 Executed_Gtid_Set 的并集发送给主库，主库将收到的并集和自己的

gtid_executed 比较，把从库 gtid 集合里缺失的事务全都发送给从库。

主机重启后，事务重复回放，表明 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的并集中有 GTID 事务

丢失，导致重复获取事务执行引发主键冲突错误。Retrieved_Gtid_Set 和 Executed_Gtid_Set 均为内存变

量，MySQL 重启后，Retrieved_Gtid_Set 初始化为空值，从而推断出 Executed_Gtid_Set 有 GTID 事务丢

失。

Executed_Gtid_Set 来源于 gtid_executed 变量，gtid_executed 变量持久化介质有

mysql.gtid_executed 表和 binlog ，其中 mysql.gtid_executed 表是 MySQL 5.7 后引入的，在 MySQL 5.6 中，从库要使用 GTID ，必须要先设置 log_bin=on,log_slave_updates=on ，因为从库执行过的 GTID 只保留在 binlog 中。

gtid_executed 变量值陈旧，推断出 binlog 未实时持久化，我们看一下参数 sync_binlog :

通过以上分析，此次故障来龙去脉就清楚了：

Worker 线程报 1062 主键冲突错误 --> gtid_executed 信息陈旧 --> binlog 未实时持久化

搭建一主一从测试环境，通过 sysbench 模拟主库并发插入，从库主机暴力关机后，故障复现：

既然错误原因是事务重复执行，那跳过错误就好了，有如下两种方式，根据需要选取其中一种方式执行：

如果最新 binglog 丢失的 GTID 较多，手工执行比较繁琐，需要不断试错。可写一个存储过程批量执行：

待主从同步正常后，再取消参数 slave_skip_errors 设置重启 MySQL 。

Mysql主从复制的问题

--主机开两个窗口，一个进入mysql，一个是shell
--主机阻断写操作
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 983407 | openser | mysql,test |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
--另外一个窗口导出主机数据库
mysqlmp -u root -ppassword --master-data=2 --opt -R openser > openser20120204.sql
--刚才的窗口主机解锁
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
mysql>
--打包数据文件到从机
drop database openser;
create database openser;
mysql -u root -ppassword openser < openser20120204.sql
--从机操作
SLAVE STOP;
reset slave;
CHANGE MASTER TO MASTER_HOST='192.168.21.26',
MASTER_USER='repl_user',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=983407;
start slave;
show slave status\G

Mysql主从复制的问题

--主机开两个窗口，一个进入mysql，一个是shell
--主机阻断写操作
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 983407 | openser | mysql,test |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
--另外一个窗口导出主机数据库
mysqlmp -u root -ppassword --master-data=2 --opt -R openser > openser20120204.sql
--刚才的窗口主机解锁
mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
mysql>
--打包数据文件到从机
drop database openser;
create database openser;
mysql -u root -ppassword openser < openser20120204.sql
--从机操作
SLAVE STOP;
reset slave;
CHANGE MASTER TO MASTER_HOST='192.168.21.26',
MASTER_USER='repl_user',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=983407;
start slave;
show slave status\G