MYSQL 多源复制故障另类恢复过程复盘

2021-07-05 00:00:00 执行 信息 方式 复制 建立


公司做了一个多源复制的库，主要的功能是将逻辑分库的信息进行合并，便于在一个物理库上进行合并查询。而问题在于之前设计的过程中并没有想过要做聚合库，所以就为目前的故障埋下了伏笔。


问题  1  数据库添加账号并不是DB 来做，而是运维来做的。

         2  每个实例里面存在同样的用户名，并且新建的用户他们也是基本按照人名来进行的建立。


[ERROR] [MY-010584] [Repl] Slave SQL for channel 'channel3': Worker 1 failed executing transaction 'cd620c28-aeb1-11ea-a3d5-205056a53593:14681474' at master log mysql-bin.000020, end_log_pos 233325466; Error 'Operation CREATE USER failed for 'ampuser'@'%'' on query. Default database: ''. Query: 'CREATE USER 'ampuser'@'%' IDENTIFIED WITH 'mysql_native_password' AS '*A07FDB5BE1BAA865EBB6A8ACC83AFE92D57C4B3C'', Error_code: MY-001396

2021-06-27T08:46:19.547720+08:00 73 [Warning] [MY-010584] [Repl] Slave SQL for channel 'channel3': ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: MY-001756


从错误中看果不其然，就是建立用户冲突了，说明之前已经有用户有建立过ampuser ，这是又在另外一个库上建立了ampuser 然后出现的问题。导致复制冲突，引擎复制停止了。



这边根据错误日志留下的信息，将重新进行操作，重新连接

change master to
master_host='10.5.31.18',
master_user='xxx',
master_password='xxxx',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=0,
MASTER_LOG_FILE='mysql-bin.000021',
MASTER_LOG_POS=936884232,
MASTER_CONNECT_RETRY=10
for channel 'channel3' ;


相关的复制恢复了，但是我们想将BINLOG  POS 的复制方式转换为GIDB的方式。


使用多源复制如果使用BINLOG + POS 的方式是方便的, 可以使用MYDUMPER来操作. XTRABACKUP 的方式就比较困难了,同样使用GTID的方式.

这里需要通过如下的方法来进行操作恢复.


1   目前是三台从库连接并且复制数据到多源复制的数据库中,我们停止三台从库的复制.并获取当时的GTID 的信息,同时也停止多源复制库的信息.


2   复制每台从库的GTID 信息,(此时保证多源复制的机器都在正常的复制当中.


3  RESET MASTER 在多源复制的机器中执行.


4   直接在机器上执行 SET @@GLOBAL.gtid_purged = "2174B383-5441-11E8-B90A-C80AA9429562:1-1029, 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695,2174B383-5441-11E8-B90A-C80AA9429562:1-1029 "

将所有的GTID 用逗号来分割,执行.


5  start slave;  查看复制是否正常


6  在打开三台复制库的start slave.  融合库恢复正常.


做一个实验我们有三台服务器  


10.50.133.81

10.50.133.116 

两个都是主库

10.50.133.82

从库


现在我们将目前的BINLOG  POS 的复制方式改为 GTID  AUTO Position 的方式.


1  由于 10.50.133.81  和 10.50.133.116  都是从库(对于他们所在的集群中)

首先我们先STOP SLAVE 两个MYSQL 的服务器.


2  10.50.133.82 上STOP SLAVE , 然后在RESET MASTER



3  在所谓的主库上 81  116 两台机器找到

我们需要找到 来台服务器的   gtid_purged 的信息


81

 37bdf984-8737-11e9-9b67-005056ad64ac:4,

a0b7d2f0-887d-11eb-880c-005056b296ae:1-2193324,

a2c06443-7271-11eb-8569-005056b296ae:1-206327


116 

 0f033762-8874-11eb-a1f1-005056b2bc71:3:25


然后我们在 82 上执行


 set @@global.gtid_purged='

37bdf984-8737-11e9-9b67-005056ad64ac:4,

a0b7d2f0-887d-11eb-880c-005056b296ae:1-2193324,

a2c06443-7271-11eb-8569-005056b296ae:1-206327,0f033762-8874-11eb-a1f1-005056b2bc71:3:25';


然后我们在从库上 reset slave  ,然后在重新做 change master 并将 mater_auto_postion=1








整体的多源复制 auto postion = 1 GTID 就恢复

后我们在从库执行下面的语句将多个主库建立同样账号的问题导致从库停止复制的问题解决了.


CHANGE REPLICATION FILTER  REPLICATE_WILD_IGNORE_TABLE = ('mysql.user');


后打开81 ,116从库的start slave

___________________________________________________________________________


以上内容由我司 ,DBA陈乙升提供



相关文章