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,如果是自己这边出去的,则不执行。