By

文章目录
  1. 1. 集群复制环境
  2. 2. 问题分析结论
  3. 3. 问题验证
    1. 3.1. 切换日志
  4. 4. 总结

最近有一套业务数据库(一主两从复制结构)空间出现紧张, 要进行大盘机器进行替换,
由于该集群使用的是MHA + Semi-sync的高可用架构. 切换的过程中, 源主库出现了一个
数据冲突的复制报错.

集群复制环境

现有环境如下: 

A  <-->  B
    -->  C

增加两个大盘节点 D E

A  <-->  B
    -->  C 
    -->  D
    -->  E

整个切换操作通过online switch操作将主库切成D 

D  <--> A
    --> B
    --> C 
    --> E

切换之后: 节点A有如下报错: 

1
2018-03-09 05:17:18 38499 [ERROR] Slave SQL: Could not execute Write_rows event on table xxxxx ; Duplicate entry '135678063' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlogxxxx.000042, end_log_pos 319174907, Error_code: 1062

这个切过程是成功的, 不过切换之后, 其他节点正常, 只有A节点复制是异常的.

问题分析结论

经过对冲突的数据对应的Binlog Event进行分析, 来源都是D节点, Server_ID都是
同一个. 这就奇怪了, 再次咨询分析发现, 原有集群复制结构中 A 和 B节点是双向复制的
(这也就是问题的根源).

配合A节点中冲突的数据的Binlog事件以及 Alert日志的报错. 可以确定数据冲突的原因是: 新主库D写打开之后, 正好有数据data01写入, 数据data01线复制到了B(此时A的master还是B)
进而直接到了A. A节点就有了这条数据data01, 之后MHA将 A节点change master 到 D
(D和B的change的位点是一致的),又复制了Data01,进而产生数据冲突, 报了上述错误.

问题验证

结合MHA的源码及切换日志信息进行验证判定.

切换日志

排查切换日志, 验证猜测, 看到日志里面其实是 read_only 关闭之后, 紧接着并行做slave切换.

1
2
3
4
5
6
7
8
9
/usr/local/bin/master_dns_online_change --command=start --orig_master_host=A  --orig_master_ip=A --orig_master_port=3307 --orig_master_user='xxxxx' --orig_master_password='xxxxx' --new_master_host=D --new_master_ip=D  --new_master_port=3307 --new_master_user='xxxxx' --new_master_password='xxx' --orig_master_ssh_user=xxxx --new_master_ssh_user=xxx  --orig_master_ssh_port=xxxx  --new_master_ssh_port=xxx --orig_master_is_new_slave 
[info]  ok.
[info] Setting read_only=0 on D(D:3307)..
[info]  ok.
[info] 
[info] * Switching slaves in parallel..
[info] 
[info] -- Slave switch on host 
....

该过程正巧和的是B先change了, A再其之后. 出现了上述问题.

总结

由于公司高可用架构包括两种: a. 主从复制(双向复制) , b. MHA(一主两从+半同步). 
出问题的集群是MHA架构的一主两从, 但是主库和其中一个库做了双向复制. 算是一个小坑. 
借此做一下记录.
文章目录
  1. 1. 集群复制环境
  2. 2. 问题分析结论
  3. 3. 问题验证
    1. 3.1. 切换日志
  4. 4. 总结