MySQL主从复制(Replication)架构的演变

一.MySQL主从复制(Replication)架构的演变概述

    传统的主从复制(Classic replication)满足不了我们生产者的需求，因为主库负责写入和读取，从库只用作备份这无疑是浪费服务器资源。

    为了让主从复制两个节点都能充分利用服务器资源，所以就有了主从架构演变的事情发生。

二.MySQL原生态支持的主从架构

1.一主一从

    所谓的一主一从，就是指一个主库和一个从库。主要用做热备份。

2.一主多从

    所谓的一主多从，就是指一个主库和多个从库，生产环境中比较常见的比如"一主两从","一主三从"架构，通常从库的数量波动范围在"2-5"个。

3.多级主从

    所谓的多级主从，就是指在已有的主从架构的从库再次作为主库，有另外的服务器以现有的从库作为主库。

4.双主结构

    所谓的双主结构，就是指互为主从的架构。

5.延迟从库

    所谓的延迟从库，就是指从库的SQL线程延迟"回放"中继日志的场景。

6.过滤复制

    所谓的过滤复制，就是指从库的SQL线程过滤

7.组复制(MySQL Group Replication，简称MGR)

    基于传统异步复制和半同步复制的缺陷就是数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制(MySQL Group Replication，简称MGR)。

    引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。

    组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。

    其提供的多写方案，给我们实现多活方案带来了希望。由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。

    举个例子:
        由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。

    温馨提示:
        由于MGR是在MySQL 5.7.17中引入的，因此在MySQL 5.7可能应用的还不是特别广泛，但在MySQL 8.0.17+版本的MGR主从复制可能会被广泛推广。

8.半同步复制（了解即可）

半同步复制与传统复制的区别
    传统的主从复制(Classic replication):
        指的是基于二进制日志的位置点来进行复制，本质上是异步非GTID复制。当然，这依赖于TCP/IP的三次握手通信机制。
        其工作原理是主库的dump线程只需要将数据发送给从库的IO线程后，IO线程在网络层做出ACK响应后，主库就认为数据复制成功，而从库何时将接收的数据落地到中继日志而交由从库的IO线程来异步完成。
        优点:
            效率高。
        缺点:
            当从库有不可控因素宕机后，可能会导致主从数据不一致的情况。

    半同步复制:
        MySQL 5.5版本为了保证主从数据的一致性问题，引入了半同步的组件(以插件形式应用，即在主库和从库上各自安装一个应用层的插件)。
        其工作原理如下:
            (1)在主从结构中，都加入了半同步复制的插件，控制从库I/O线程是否将中继日志落盘，一旦落盘通过插件返回ACK给ACK_REC。接收到ACK之后，主库的事务才能提交成功;
            (2)在默认情况下，如果超过10秒没有返回ACK，此次复制行为会切换为异步复制。
        优点:
            解决了数据一致性问题。
        缺点:
            需要单独安装插件，一旦从库超时，则半同步复制效果荡然无存。

    尽管半同步复制在MySQL 5.6，MySQL 5.7版本当中和也加入了一些比较好的特性(例如:"After commit","After sync","无损复制")，也不能完全保证99.999%的数据一致。

    综上所述，如果你在生产环境中比较关注主从数据最终一致，我们推荐使用MGR的架构，或者PXC等一致性架构。

半同步复制已经成为历史，了解即可
    半同步复制的原理了解之后，想必很多人并不会在生产环境中应用它们，如果对主从数据一致性有要求的场景，强烈建议使用MGR，PXC等解决方案。

温馨提示:    
    如果对半同步复制技术感兴趣的小伙伴可自行查阅文档，毕竟这种文档已经烂大街了。

三.MySQL非原生态支持的主从架构，即需要第三方组件支持的主从架构

1.可用性：高可用架构

    全年无故障率级别指标:
        99%:
            级别: 
                一般。
            允许故障时间: 
                1% x 365 = 3.65天
                1% x 356 x 24 =  87小时
                1% x 356 x 24 x 60 = 5256分钟
                1% x 356 x 24 x 60 x 60 = 315360秒
        99.9%:
            级别:
                普通。
            允许故障时间:
                0.1% x 365 = 0.365天
                0.1% x 356 x 24 =  8.76小时
                0.1% x 356 x 24 x 60 = 525.6分钟
                0.1% x 356 x 24 x 60 x 60 = 31536秒
        99.99%:
            级别:
                准高可用。
            允许故障时间:
                0.01% x 365 = 0.0365天
                0.01% x 356 x 24 =  0.876小时
                0.01% x 356 x 24 x 60 = 52.56分钟
                0.01% x 356 x 24 x 60 x 60 = 3153.6秒
            代表产品:
                MySQL MHA等。
        99.999%:
            级别:
                金融。
            允许故障时间:
                0.001% x 365 = 0.00365天
                0.001% x 356 x 24 =  0.0876小时
                0.001% x 356 x 24 x 60 = 5.256分钟
                0.001% x 356 x 24 x 60 x 60 = 315.36秒
            代表产品:
                MySQL InnoDB Cluster，MySQL PXC，MySQL MGC，Oracle RAC，Sysbase Cluster等。
        99.9999%:
            级别:
                超金融级别，据说K8S针对无状态的服务就可以达到该级别哟~
            允许故障时间:
                0.0001% x 365 = 0.00365天
                0.0001% x 356 x 24 =  0.0876小时
                0.0001% x 356 x 24 x 60 = 0.5256分钟
                0.0001% x 356 x 24 x 60 x 60 = 31.536秒

    综上所述，为了保证全年无故障率级别达到金融级别(即5个9)，因此需要高可用架构来支撑业务。

    温馨提示:
        全年无故障率指的是计划外的意外宕机的情况，如果是有计划的维护停机(比如新上线功能需要停机维护，升级数据库版本等)则不能算哟~

2.性能： 读写

    读多写少:
        解决方案:
            读写分离方案。
        代表产品:
            Altas，ProxySQL，Maxschle，Mycat等。

    读少写多:
        解决方案:
            分布式方案。
        代表作品:
            Mycat(DBLE)，Altas-sharding，sharding-jdbc