高可用方案
- 共享存储：SAN/NAS
- 操作系统实时数据块恢复：DRBD架构(MySQL+DRBD+Heartbeat)
- 主从复制架构
- 主从复制(一主多从)
- MMM架构(双主多从)
- MHA架构(多主多从)
- 数据库高可用架构
- GRT(MySQL Group Replication)
- Galera
- MySQL Cluster 和 PXC
- MySQL Cluster(ndb存储引擎比较复杂，并没有大规模使用)
- PXC(Percona XtraDB Cluster)
常见方案介绍
方案1 主从架构
- 主从复制的模式有哪些？https://zhuanlan.zhihu.com/p/307288925
- 怎么保证数据库一致性
方案2 MHA架构
MHA: Master Hight Availability Manager and Toolsfor MySQL
MHA(Master High Availability Manager and Toolsfor MySQL)目前在Mysql高可用方面是一个相对成熟的解决方案。它是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication 环境，目的在于维持Master主库的高可用性。
MHA是基于标准的MySQL复制(异步/半同步)。
MHA是由管理节点(MHA Manager)和数据节点(MHA Node)两部分组成。
MHA Manager可以单独部署在一台独立机器,也可以部署在一台slave上。
方案3 MMM架构
MMM，全称为Master-Master replication manager for Mysql，是一套支持双主故障切换和双主日常管理的脚本程序，MMM使用Perl语言开发。主要用来监控和管理MySQL Master-Master(双)复制。特别适合DBA做维护等需要主从复制的场景，通过双主架构避免了重复搭建从库的麻烦。虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时备选主的预热
MMM优缺点
优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。
缺点：Monitor节点是单点，可以结合Keepalived实现高可用
方案4 DRBD架构
https://www.linbit.com/en/drbd-community/drbd-download/
读写分离方案
客户端解决方案(应用层)
常用：DDL、 Sharding-Jdbc (常用shardding-jdbc)
优点：
- 程序自动完成，数据源方便管理
- 不需要维护，因为没用中间件
- 理论支持任何数据库 （sql标准）
缺点：
- 增加了开发成本、代码有入侵
- 不能做到动态增加数据源
- 程序员开发完成，运维参与不了。
中间件解决方案（代理层）
常用：mysql proxy、mycat、altas (常用mycat)
优点：
- 数据增加了都程序没用任何影响
- 应用层（程序）不需要管数据库方面的事情
- 增加数据源不需要重启程序
缺点：
- 程序依赖中间件，导致切换数据库变的困难
- 增加了proxy 性能下降
- 增加了维护工作、高可用问题
主从复制
Mysql为了保证数据库一致性，引入了集中复制类型，分别是
- 异步复制
- 半同步复制
- 全同步复制
主从复制整理分为以下三个步骤
- 主库将数据库的变更操作记录到Binlog日志文件(Master服务器对数据库更改操作记录在Binlog中，BinlogDump Thread接到写入请求后，读取Binlog信息推送给Slave的I/O Thread)
- 从库读取主库中的Binlog日志文件信息写入到从库的Relay Log中继日志中(Slave的I/O Thread将读取到的Binlog信息写入到本地Relay Log中)
- 从库读取中继日志信息在从库中进行Replay,更新从库数据信息(Slave的SQL Thread检测到Relay Log的变更请求，解析relay log中内容在从库上执行)
主库上并发的修改操作在从库上只能串行化执行，因为只有一个SQL线程来重放中继日志，这也是很多工作负载的性能瓶颈所在
异步复制
mysql主从复制存在的问题：
- 主库宕机后，数据可能丢失
- 从库只有一个SQL Thread，主库写压力大，复制很可能延时
半同步复制
为了提升数据安全，MySQL让Master在某一个时间点等待Slave节点的 ACK（Acknowledgecharacter）消息，接收到ACK消息后才进行事务提交，这也是半同步复制的基础，MySQL从5.5版本开始引入了半同步复制机制来降低数据丢失的概率。
介绍半同步复制之前先快速过一下 MySQL 事务写入碰到主从复制时的完整过程，主库事务写入分为 4个步骤：
-
InnoDB Redo File Write (Prepare Write)
-
Binlog File Flush & Sync to Binlog File
-
InnoDB Redo File Commit（Commit Write）
-
Send Binlog to Slave
当Master不需要关注Slave是否接受到Binlog Event时，即为传统的主从复制。
当Master需要在第三步等待Slave返回ACK时，即为 after-commit（Master先提交，等Slave ACK以后再，回复客户端），半同步复制（MySQL 5.5引入）。
当Master需要在第二步等待 Slave 返回 ACK 时，即为 after-sync（Master先写binlog，等Slave ACK以后再提交），增强半同步（MySQL 5.7引入）。
下图是 MySQL 官方对于半同步复制的时序图，主库等待从库写入 relay log 并返回 ACK 后才进行Engine Commit。
MySQL Group Replication
MySQL Group Replication是建立在已有MySQL复制框架的基础之上，通过新增Group Replication Protocol协议及Paxos协议的实现，形成的整体高可用解决方案
与原有复制方式相比，MGR主要增加了状态机一致性顺序复制和certify这两个环境
MySQL事务通过before_commit钩子进入MGR，before_commit位于MYSQL_BIN_LOG::commit()函数中，具体是在进入事务组提交MYSQL_BIN_LOG::ordered_commit()之前，这就意味着执行到before_commit这个钩子时，事务还未提交，产生的Binlog还未写入Binlog文件中，事务GTID还未产生
分布式数据库事务
分布式数据库实现分布式事务的主流方法还是2PC
如上图所示，当分布式事务提交时，会选择其中的一个数据分片作为协调者在所有数据分片上执行两阶段提交协议。由于所有数据分片都是通过 Paxos 复制日志实现多副本高可用的，当主副本发生宕机后，会由同一数据分片的备副本转换为新的主副本继续提供服务，所以可以认为参与者和协调者都是保证高可用不宕机的（多数派存活），绕开了协调者宕机的问题。
在参与者高可用的实现前提下，可以对协调者进行了“无状态”的优化。在标准的两阶段提交中，协调者要通过记录日志的方法持久化自己的状态，否则如果协调者和参与者同时宕机，协调者恢复后可能会导致事务提交状态不一致。但是如果我们认为参与者不会宕机，那么协调者并不需要写日志记录自己的状态。
所以在第一阶段所有参与者都回复prepare完成以后，即可以反馈事务提交成功，提升了2PC的效率
由于存在多副本，只要保证在prepare阶段，验证事务执行没有错误，协调者发出commit指令后，就可以乐观的认为，事务执行成功并反馈给事务发起者。相信commit消息会被多数副本收到，多数副本收到消息以后，剩下的就交给他们自己同步
在上图中（绿色部分表示写日志的动作），左侧为标准两阶段提交协议，用户感知到的提交时延是4次写日志耗时以及2次 RPC 的往返耗时；由于少了协调者的写日志耗时以及提前了应答客户端的时机，用户感知到的提交时延是1次写日志耗时以及1次 RPC 的往返耗时