MySQL学习（三）：主从复制Replication实现高可用的架构模式

川长思鸟来 2022-03-10 07:29 216阅读 0赞

### 概述 ###

*  MySQL主从复制主要用于实现读写分离，所以主从架构一般为一主多从，即主库负责处理所有的写入请求，一个或多个从库负责处理所有的读请求，从而分散读写流量，实现读数据的高可用。除此之外，如果从库很多造成了主库复制负载太大，也可以考虑采用级联复制，即从库既作为主库的从库，也作为下一级从库的主库，从而降低主库的负载。
 *  以上架构都是针对读实现高可用，在主库写方面还是存在单点问题，故也可以基于MySQL主从复制实现一个双主架构，实现主库写的高可用。
 *  在双主架构基础上，还可以继续添加从库，从而实现读写分离和读写的高可用。

### Master-Slaves：一主多从架构 ###

*  一主多从架构是最简单的主从架构模式，由于从库直接复制主库，故在系统负载良好的情况下，从库的数据延迟是最小的，基本与主库保持实时一致性。所以这种架构模式也是生产环境最常用于实现读写分离的一种主从架构。具体架构示意图如下：（图片均引自《MySQL性能调优与架构设计》  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]
 *  这种架构模式存在的问题就是主库还是单点的，即没有实现主库写的高可用，一种方案是当主库停机时，将从库切换为主库，但是这样当主库重新起来，需要切换回来时，由于主库没有从库的binlog position，即不知道需要从当前担任主库的从库的什么位置复制数据，故需要重新搭建主机复制环境，这样会带来许多额外的工作量和风险。所以为了解决这个问题，实现自动切换和恢复，则可以使用双主架构。

### Master-Master：双主架构 ###

*  双主架构是实现主库写高可用的一种架构模式，两个主库互为对方的从库，两个主库均可以执行写操作，然后复制给对方。
 *  主库停机维护：由于双方都有对方的binlog position，即知道当前复制到对方什么位置了，故当其中一方停机可以使用另外一方来作为主库，当停机的主库重启恢复回来时，可以从原来的binlog position继续复制当前的主库的数据，实现自动切换恢复。
 *  主库故障自动切换：可以结合第三方的高可用工具HA来实现当其中一个主库挂掉时，自动切换到另外一个主库，实现故障自动切换和高可用。

##### 循环复制问题 #####

*  在这种模式下，由于双方都是主库，故均会将写操作记录到二进制日志中并复制给对方，这样会存在循环复制的问题。
 *  故为了解决这个问题，MySQL在设计中，在搭建主从复制时，各个库需要指定自己的server-id，并且不能相同，所以通过该server-id每个主库可以判断出这个写操作是否是自己产生的，如果是则忽略复制过来的写操作，如下为使用MySQL自带的mysqlbinlog工具查看的二进制日志的内容，其中包含server-id：
    
        # at 552
        ## 执行时间:17:50:46；pos点:665
        #131128 17:50:46 server id 1  end_log_pos 665   Query   thread_id=11    exec_time=0     error_code=0 
        SET TIMESTAMP=1385632246/*!*/;
        update t_user set name='xyz' where id=1             ## 执行的SQL
        /*!*/;
        # at 665
        #131128 17:50:46 server id 1  end_log_pos 692   Xid = 1454  ## 执行时间:17:50:46；pos点:692 
        
        注：
        server id 1     数据库主机的服务号
        end_log_pos 665 pos点
        thread_id=11    线程号
 *  其次，MySQL的二进制日志实现还提供了–log-slave-updates选项，如果不打开这个选项，则从库不会将主库同步过来的写操作记录到二进制日志中。默认为关闭的。具体可看官方文档：[log\_slave\_updates][log_slave_updates]

##### 架构模式 #####

*  双主架构的示意图如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 1]
 *  在实际应用中，并不是将两个同时用于提供写服务，而是其中一个提供写服务，另外一个提供读服务或者不提供任何服务，只做备份。这样设计的目的是，因为主从复制是异步的，存在延迟，如果两个都提供写服务，则可能会存在对同一个数据进行并发修改时，如主库A先执行，主库B后执行，在主库A同步给主库B之前，主库B已经执行了写操作，故会存在数据不一致问题，即正常情况下为：A写 -> A同步给B -> B重放A的写 -> B执行写，但是并发情况下，可能就是：A写 -> B写 -> A同步给B -> B重放A的写，这样就B的写就会被A的覆盖了。

### Master-slaves-slaves：级联复制架构 ###

*  级联复制架构主要用于解决主库由于存在太多从库而导致资源消耗过大，主库性能下降的问题，实现方式为：将一部分从库直连主库，另外一部分从库连接这些直连主库的从库的其中一个或多个，从而实现级联复制，如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 2]
 *  这种架构可以降低主库的负载，但是存在的问题是由于存在了多级复制，而主从复制由于是异步复制存在延迟问题，故最底层的从库会延迟更大，并且延迟随着级联层次的增大而增大，故如果读服务不能容忍太大的数据延迟，则不能采用这种架构模式。

### Master-Master-slaves：双主多从架构 ###

*  双主多从架构模式是一主多从和双主的结合，由之前的分析可知，在双主架构中不是两个都提供写服务，而是其中一个提供写服务，另外一个提供读服务或者备份。所以可以将该备份主库利用起来，即使从库连接这个备份主库，而不是直连提供写服务的主库，这样可以降低提供写服务主库的压力，如图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 3]
 *  这种架构模式下：当主库挂了或者需要停机维护，可以将备份主库升级了提供写服务的主库，此时从库无需变动；如果备份主库挂了或者需要停机维护，则可以将从库临时连接提供写服务的主库。
 *  其次这种架构模式下由于提供写服务的主库只需复制同步数据给备份主库，备份主库只需将数据复制给从库，故负载都较低，降低了因为负载问题而出现故障的概率，提供了系统整体的稳定性。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]: /images/20220310/92a8c9d8e19645e192eaf622a9b3df82.png
[log_slave_updates]: https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_log_slave_updates
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 1]: /images/20220310/a5f79cf0c2c04c7398f14b0ed45ad3a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 2]: /images/20220310/8198f9b50fec4d5f9438e28714985492.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 3]: /images/20220310/5150d98cb2c74c4d9a4c8fdc66df767b.png