6.主主复制实战

1.主主复制架构
两个节点均为Master，两个节点互为Slave，一个节点出现故障时，无需切换。平时只使用一个数据库进行读写操作，另一个节点设置为只读，当写库压力过大时，也可以进行读写分离，减轻写库压力，其架构如下图所示。

2.容灾
(1).正常

(2).A不可用

(3).B切换为读写数据库

(4).A恢复后将其设置为只读数据库

3.实操
(1).开始前确保每个节点的主从状态一致

(2).主节点复制从节点

#暂停主从复制
mysql> STOP SLAVE; 

mysql> CHANGE MASTER TO MASTER_HOST='121.4.191.124',MASTER_USER='root',MASTER_PASSWORD='********',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=120;

#开始主从复制
mysql> START SLAVE; 

mysql> SHOW SLAVE STATUS \G; 

(3).主从各插入一条数据测试

4.问题
(1).数据冲突
两边插入相同ID时，可能会出现冲突。解决方案，只写一个主，另一个只读。或者两边约定好插入不同ID，使用分布式ID框架获取。

(2).客户端切换
应用自己切换比较麻烦，解决方案使用keepalived等手段完成自动切换。

(3).循环复制
A插入一条数据，A将binlog发送给B，B执行一次。然后B执行新增了一条数据，也产生新的binlog，并发送给A，产生循环复制问题。未开启GTID的解决方案，使用serverID过滤，A将binlog发送给B时会带上serverID，B产生新的binlog，会加上数据的来源，也是A的serverID，那么A接收B的binlog日志，执行时会检查serverID，如果是自己这边出去的，则不执行。