环境
系统: CentOS release 6.10 (Final)
MySQL:1,5.7.26-log MySQL Community Server (GPL)
2, 搭建多源复制, 存在俩个不同 channel, 假设为: zerolh_v1,zerolh_v2
3, 存在复制过滤, change replication filter REPLICATE_WILD_IGNORE_TABLE
用途: BI 数据分析使用
现象
因为 BI 数据分析的同事执行大事务产生了临时表将磁盘空间即将打满, DBA 同事尝试有过 kill 但是发现磁盘空间大小还未释放, 最后 DBA 同事通过重启手段释放磁盘空间, 但是发现 channel 从之前的 2 个变成了 3 个. 并且当时读取的 relay-log 信息已经无法获取得到, 导致主从复制监控告警.
解决方案
1, 因为 master_info_repository 是 TABLE 类型, 故猜想可以通过删除 MySQL.master_info_repository 的手段删除多出来的一行 channel, 然后重启从库, 但是实际重启之后相关的 channel 信息还存在.
- MySQL> show global variables like '%master%';
- +------------------------+-------+
- | Variable_name | Value |
- +------------------------+-------+
- | master_info_repository | TABLE |
- | master_verify_checksum | OFF |
- | sync_master_info | 1 |
- +------------------------+-------+
- 3 rows in set (0.00 sec)
2, 通过查询官网获取可以执行 reset slave all for channel 'channel_name' 可以直接清除掉相关的 master 信息.
- MySQL> reset slave all for channel 'zerolh_v4';
- Query OK, 0 rows affected (0.00 sec)
- MySQL>
官网
通过查询官网可以很明显得获取得到, master 的在 master_info_repository=TABLE 的时候不仅仅是存放在表中, 并且也会存放在内存当中, 故当正常重启 MySQL 的时候, 删除 slave_master_info 表中的信息是无法清除 master 的信息的.
实验
1, 通过 insert 语句在 MySQL.slave_master_info 插入一条 channel, 然后执行 show slave status(分重启和非重启)
2, 在 MySQL.slave_master_info 插入相同 master_host 和 master_port 的值是否生效
3, 在 MySQL.slave_master_info 删除一条 channel 然后重启
结论
1, 人为在 MySQL.slavemasterinfo 添加一条记录是可以通过 show slave status 查看得到的, 但是必须得重启
2,MySQL.slave_master_info 表是 innodb 引擎表, 并且只存在主键 channel_name.
3,MySQL 实例重启之后是会读取内存获取得到 master 的信息.
事故猜想
通过一系列实验和资料, 比较可能原因是因为 MySQL.slave_master_info 里面的表多出来一条记录, 但是没有生效, 重启之后生效获取得到多出的 channel 信息, 但是还是无法理解为什么会多出来一条信息.
1, 人为操作 (这个有可能, 但是这边实在是想不起有这个操作)
2, 通过主从复制, 因为 change replication filter 复制过滤是过滤掉 MySQL 这个 schema, 但是只是在 MySQL 命令行操作, 并没有在配置文件中添加相关的参数信息, 故重启之后复制信息就会全部丢失.
来源: http://www.bubuko.com/infodetail-3483835.html