1 单机 =》集群
根据云厂商Benchmark结果，4核8G机器运行 MySQL 5.7 时，可支撑TPS 500，QPS 10000。
但随着数据量的增大，读写并发的增加，系统可用性要求的提升，单机 MySQL 出现危机：
- 容量问题，难以扩容，考虑数据库拆分、分库分表
- 读写压力，QPS 过大，特别是分析类需求会影响到业务事务，考虑多机集群、主从复制
- 高可用性不足，易宕机，考虑故障转移、MHA/MGR/Orchestrator
- 高峰时数据库连接数经常超过上限
- 一致性问题
考虑分布式事务，X/A 柔性事务
读写分离的实现是基于主从复制架构：一主多从，只写主库，主库会自动将数据同步到从库。
主从复制的意义
高并发场景下MySQL的一种优化方案，依靠主从复制使得MySQL实现了数据复制为多份，增强了抵抗高并发读请求的能力，提升了MySQL查询性能同时，也提升了数据的安全性。当某一个MySQL节点，无论是主库还是从库故障时，还有其他的节点中存储着全量数据，保证数据不会丢失。
2 MySQL主从复制
2.1 发展史
2000年，MySQL 3.23.15版本引入了复制
2002年，MySQL 4.0.2版本分离 IO 和 SQL 线程，引入了 relay log
2010年，MySQL 5.5版本引入半同步复制
2016年，MySQL 在5.7.17中引入 InnoDB Group Replication
2.2 核心
- 主库写 binlog
- 从库 relay log
主从复制的过程
- 主库将变更写binlog日志，然后从库连接到主库后，从库有个I/O线程，将主库的binlog日志拷贝到本地，写入一个中继日志
- 接着从库中有个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容。即在本地再次执行一遍SQL，确保跟主库数据相同
binlog格式
- ROW
记录详细，但日志量较大 - Statement
记录简单，只记录SQL，无查询语句 - Mixed
# 查看binlog mysqlbinlog -vv mysql-bin.000005
异步复制
异步复制：经典的主从复制，Primary-Secondary Replication，2000年MySQL 3.23.15版本引入 Replication。
传统的MySQL复制提供了一种简单的主从复制方案。有一个主（source）并且有一或多个从（replicas）。主数据库execute事务，将其commit，然后将它们异步发给从库，以re-executed（在基于语句的复制中）或apply（在基于行的复制中）。它是一个无共享系统，默认情况下所有服务器都具有数据的完整副本。
MySQL 异步复制
优点
简单
缺点
- 网络或机器故障，会造成数据不一致
SQL的每个增删改的会改变数据的操作，除了会更新数据外，对这个增删改操作还会写入一个日志文件，记录这个操作的日志，即binlog。
MySQL 5.7新版本的并行复制，多个SQL线程，每个线程从relay日志里读一个库的日志，重放。
从库同步主库数据的过程是串行化的，即主库上并行的操作，在从库会串行执行。
由于【从库】从【主库】拷贝日志及串行执行SQL的特点，在高并发下就有延时，从库数据一定比主库慢。
所以经常出现，刚写入主库的数据读不到，要过几十甚至几百ms才能读到。
从库串行化过程：
- 读取binlog日志
- 写relay日志、应用日志变更到自己本地数据
从库的I/O线程，读取主库的binlog日志时，老版本是单线程，5.6.x之后的新版本改为多线程读取。
若主库宕机时，恰好数据还没同步到从库，则有些数据可能在从库上没有，可能就这么丢失了。
所以MySQL实际上在这有两个机制：
半同步复制
它向协议添加了一个同步步骤。这意味着主库在提交时，等待从库确认已接收到事务。只有这样，主库才会恢复提交操作。
2010 年引入Semisynchronous Replication，5.5 可用，解决主库数据丢失问题，保证主从的最终一致性。
需启用插件。
- 主库写入binlog日志后，会强制立即将数据同步到从库
- 从库将日志写入自己的relay log后，会返回ack给主库
- 主库接收到至少一个从库的ack后，才认为写操作完成
上面的图片可看到经典的异步MySQL复制协议（及其半同步变量）的示意图。不同实例之间的箭头表示服务器之间交换的消息或服务器与客户端应用程序之间交换的消息。
组复制
2016年引入，5.7 开始，启用插件。
基于 Paxos 协议实现的组复制，保证数据一致性。
组复制是一种可用于实施容错系统的技术。复制组是一组服务器，每个服务器都有自己的完整数据副本（无共享复制方案），并通过消息传递相互交互。通信层提供了一组保证，例如原子消息和总订单消息传递。这些功能非常强大，可以转化为非常有用的抽象，可以用来构建更高级的数据库复制解决方案。
MySQL组复制建立在这些属性和抽象之上，并在所有复制协议中实现多源更新。一个复制组由多个服务器组成，该组中的每个服务器可以随时独立执行事务。但是，所有读写事务只有在组批准后才提交。换句话说，对于任何读写事务，组都需要决定是否提交，因此提交操作不是来自原始服务器的单方面决定。只读事务无需组内的任何协调即可立即提交。
当读写事务准备好在原始服务器上提交时，服务器自动广播写值（已更改的行）和相应的写集（已更新的行的唯一标识符）。由于事务是通过原子广播发送的，因此该组中的所有服务器都将接收该事务，否则将不会。如果他们收到了，那么相对于之前发送的其他事务，他们都将以相同的顺序收到它。因此，所有服务器都以相同的顺序接收相同的交易集，并且为交易建立了全局总订单。
但是，在不同服务器上同时执行的事务之间可能存在冲突。通过在称为认证的过程中检查并比较两个不同并发事务的写集，可以检测到此类冲突。在认证过程中，冲突检测是在行级别执行的：如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。冲突解决过程指出，已首先订购的事务在所有服务器上提交，而已订购第二的事务中止，因此在原始服务器上回滚并由组中的其他服务器丢弃。例如，如果t1和t2在不同的站点上同时执行，都更改了同一行，并且t2在t1之前排序，则t2赢得了冲突，并且t1被回滚。这实际上是一个分布式的首次提交胜出规则。请注意，如果两个事务之间的冲突经常发生，那么在同一个服务器上启动它们是一个好习惯，在那里，它们有机会在本地锁管理器上进行同步，而不必由于认证而回滚。
对于应用和外部化已认证的交易，如果不破坏一致性和有效性，组复制允许服务器偏离交易的约定顺序。组复制是最终的一致性系统，这意味着一旦传入流量减慢或停止，所有组成员将具有相同的数据内容。当流量在流动时，可以按略有不同的顺序对事务进行外部化，或者对某些成员先进行外部化。例如，在多主要模式下，尽管尚未应用全局顺序中较早的远程事务，但是本地事务可能会在认证后立即被外部化。当证明过程确定交易之间没有冲突时，这是允许的。在单主模式下，在主服务器上，并发，无冲突的本地事务以与组复制所同意的全局顺序不同的顺序进行提交和外部化的可能性很小。在不接受来自客户端的写操作的辅助服务器上，事务始终按照约定的顺序进行提交和外部化。
下图描述了MySQL组复制协议，通过将其与MySQL复制（甚至MySQL半同步复制）进行比较，您可以看到一些区别。请注意，为清楚起见，此图中缺少一些基本的共识和Paxos相关的消息。
