前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MYSQL 多源复制故障另类恢复过程复盘

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

作者头像
AustinDatabases
发布2021-07-15 14:56:09
1.3K0
发布2021-07-15 14:56:09
举报
文章被收录于专栏:AustinDatabasesAustinDatabases

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

问题 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

代码语言:javascript
复制

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陈乙升提供

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AustinDatabases 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档