MySQL踏浪之途第三遍
Posted 以数据之名
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL踏浪之途第三遍相关的知识，希望对你有一定的参考价值。
合抱之木，生于毫末
九层之台，起于累土
千里之行，始于足下
01
—
背景介绍
上篇，我们谈了mysql索引模型结构说明和查询性能调优方案，破冰之旅，进阶升华，百炼成型。
本篇，我们聊下MySQL基础架构演进策略和常用架构设计方案，踏浪之途，翻江倒海，奔流不息。
02
—
基础架构演进背景
一切脱离应用实际，空谈架构的言论都是流氓行为。要聊MySQL基础架构演进策略，那就必须要依托应用的发展阶段、当期用户体量和预期支撑目标等背景来看，才能更客观的分析适合当前应用的数据库架构。为了大家能够更清楚的认知应用背景和数据库架构对应关系，我们先来看一看某宝数据库发展的三阶段：
第一阶段：2003年某宝上线初期，仅靠的是几台单机MySQL，应用系统拆分为前后台两大体系，且严重依赖于数据库系统；
第二阶段：早期单机式的MySQL，在业务高速发展的前景下，性能很快达到瓶颈。MySQL迁移到Oracle，同时存储也由低端的PC Server升级到高端的IBM小型机，几年的时间里，满足了某宝业务快速变化发展的需要；
第三阶段：第一、二阶段的单台数据库里，用户、商品、交易、评价、收藏等数据都在一起，存在很多的数据关联查询，应用耦合度极高。小型机的内存有限，同时Oracle数据库有连接数瓶颈，5000个以后就相当吃力。着手中心化、服务化建设，建设了用户、商品、交易三大中心。应用中心化后，底层数据库系统按照不同的业务数据进行了一系列的垂直拆分。核心业务从Oracle逐步迁移到分布式的MySQL集群，大量存储也由IBM小型机切换至PC Server；
第四阶段：全量切入蚂蚁自主研发的金融级分布式关系数据库OceanBase
03
—
基础架构演进策略
上一小节，我们以某宝数据库架构演进历程为背景，介绍了架构演进的基础要点及其关联性。本节我们从纯MySQL（毕竟对于初创型企业，免费开源才是王道）角度来切入，谈一谈基础数据架构演进的策略方向，具体演进方向如下图：
从上面MySQL技术架构演进图来看，我们可知总体上的演进策略方向主要有横向扩展和纵向扩展两个方面。
Scale Out：横向扩展，增加处理节点提高整体处理能力
Scale Up：纵向扩展，通过提升单个节点的处理能力达到提升整体处理能力的目的
一般MySQL架构模式都是基于Master-Slaves主从复制原理实现的，常用的主就要有以下几种：
一主两从(Master-Slave-Slave)
两主两从(Master-Master-Slave-Slave)：2个master节点互相同步更新。因为MySQL的异步复制方式，为了防止数据冲突造成的不一致性，一般仅将其中一台用于写操作，另一台不用或仅用于读操作。目的是其中一台master停机维护或者故障中断时可以使用另一台master
MySQL MHA主从复制架构
MySQL MHA的级联集群架构
MySQL MGR集群架构
MySQL InnoDB Cluster集群架构
04
—
Master-Slaves主从复制原理
主从复制（Master-Slave）
主服务器上面的任何修改都会保存在二进制日志Binary log里面，从服务器上面启动一个I/O thread（实际上就是一个主服务器的客户端进程），连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Realy log里面。从服务器上面开启一个SQL thread定时检查Realy log，如果发现有更改立即把更改的内容在本机上面执行一遍。
级联复制（Master-Slave-Slave）
在Master-Slave-Slave中，这时主库既要负责写，又要负责为几个从库提供二进制日志。如果Slaves过多replication将增加master的负载，这时可以让master只将二进制日志发送给其中几个Slave节点分发更新日志，这几个Slave节点再开启二进制日志，同时这几个Slave节点作为一级节点再向下级节点分发更新日志。或者是干脆这几个Slave节点不记录，只负责将二进制日志转发给其它Slave，这样架构起来性能可能要好得多，而且数据之间的延时应该也要小一些。
05
—
Master-Slaves一主两从架构
架构描述
Master主库负责写请求，Slave1和Slave2备库读请求
通过使用分布式数据库中间件MyCAT、ShardingSphere等连接数据库集群，可对M-S1-S2集群做自动负载均衡
架构特点
优点：对于读多写少的场景支持比较友好
缺点：主库M存在单点故障
06
—
Master-Slaves两主两从架构
架构描述
Master主库M1或M2负责写请求，Slave1和Slave2备库读请求
通过使用分布式数据库中间件MyCAT、ShardingSphere等连接数据库集群，可对M1-M2-S1-S2集群做自动负载均衡，通过VIP访问M1或M2，保证集群主库高可用
架构特点
优点：对于读多写少的场景支持比较友好；主库M的高可用得到一定保证，M1或M2任意一个宕机，都能切换到另外一个
缺点：仅是冷备，可靠性比双活低
07
—
MySQL MHA架构
架构介绍
在MySQL故障切换和主从提升的高可用方面，MHA（Master High Availability）目前是一个相对成熟的解决方案。在MySQL故障切换过程中，MHA能做到0~30秒之内自动完成数据库的故障切换操作，并且能最大程度上保证数据库的一致性，以达到真正意义上的高可用。
MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群，也可以部署在一台Slave上。当Master出现故障时，它可以自动将最新数据的Slave提升为新的Master，然后将所有其他的Slave重新指向新的Master。整个故障转移过程对应用程序是完全透明的。
工作原理
从宕机崩溃的Master保存二进制日志事件（binlog event）；
识别含有最新更新的Slave；
应用差异的中继日志（relay log）到其他Slave；
应用从Master保存的二进制日志事件；
提升一个Slave为新的Master；
使其他的Slave连接新的Master进行复制；
适用场景
目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群必须最少有3台数据库服务器，一主二从，即一台充当Master，一台充当备用Master，另一台充当从库。出于成本考虑，淘宝在此基础上进行了改造，开发了支持一主一从的TMHA。
组成架构
MHA软件由两部分组成，Manager工具包和Node工具包，具体如下。
1、Manager工具包：
masterha_check_ssh:检查MHA的SSH配置情况。masterha_check_repl:检查MySQL复制状况。masterha_manager:启动MHA。masterha_check_status:检测当前MHA运行状态。masterha_master_monitor:检测Master是否宕机。masterha_master_switch:控制故障转移（自动或手动）。masterha_conf_host:添加或删除配置的server信息。
2、Node工具包：
通常由MHA Manager的脚本触发，无需人工操作
save_binary_logs:保存和复制Master的binlog日志。apply_diff_relay_logs:识别差异的中级日志时间并将其应用到其他Slave。filter_mysqlbinlog:去除不必要的ROOLBACK事件（已经废弃）purge_relay_logs:清除中继日志（不阻塞SQL线程）
重点补充：为了尽可能的减少因为主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议必须配置MySQL5.5半同步复制，默认也是半同步复制。
存在隐患
在MHA自动故障切换的过程中，MHA试图从宕掉的主服务器上保存二进制日志，最大程度保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过SSH访问，MHA没有办法保存二进制日志，只能进行故障转移而丢失了最新数据。再比如，MySQL服务挂了，但是可以从服务器拷贝二进制。但如果硬件宕机或者SSH不能连接，不能获取到最新的binlog日志，如果复制出现延迟，会丢失数据。
使用MySQL5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以和半同步复制结合起来。如果只有一个Slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有Slave服务器上，保持数据一致性。
最新版0.56版本，增加了支持GTID的功能，建议在MySQL5.6及之后版本使用。MySQL5.5建议使用管理节点版本0.55，数据节点0.54。
08
—
MySQL MHA主从复制架构
架构描述
Master主库M1负责写请求，Slave1和Slave2备库读请求
通过使用分布式数据库中间件MyCAT、ShardingSphere等连接数据库集群，可对M1-S1-S2集群做自动负载均衡
MHA Manager Node负责管理Master-Slave集群
架构特点
优点：对于读多写少的场景支持比较友好；主库M1宕机后，Manager Node能及时监测到，并在极短时间内把S1或S2（参考具体实际配置）提升为Master，完成整个数据库的故障切换操作，保障Master-Slave集群的高可用；在进行故障切换的过程中，MHA能最大程度上保障数据的一致性
缺点：需要部署MHA第三方软件
09
—
MySQL MHA级联集群架构
架构描述
Master主库M1负责写请求，Slave1和Slave2备库读请求
通过使用分布式数据库中间件MyCAT、ShardingSphere等连接数据库集群，可对多套M1-S1-S2集群做自动负载均衡
1套MHA Manager Node负责管理多套Master-Slave集群
各个集群可以对数据库的库和表，按照垂直或水平方式做数据分片拆分
架构特点
优点：能够友好的支撑大数据量读多写多的场景；主库M1宕机后，Manager Node能及时监测到，并在极短时间内把S1或S2（参考具体实际配置）提升为Master，完成整个数据库的故障切换操作，保障Master-Slave集群的高可用；在进行故障切换的过程中，MHA能最大程度上保障数据的一致性
缺点：需要部署MHA第三方软件
10
—
MySQL MGR集群架构
架构描述
为了解决传统异步复制和半同步复制可能产生数据不一致的问题，MySQL从5.7.17版本后开始支持MGR（MySQL Group Replication）插件。
MySQL MGR支持单主模式和多主模式，官方推荐的是单主模式。
单主模式的MGR集群中MySQL使用分布式一致性Paxos协议进行Master选举，选举出Master节点，剩下的都为Slave节点。集群中Master负责读写请求，Slave负责读请求。
当Master发生故障宕机，MGR集群能够快速从Slave中选举出新的Master，做到故障自愈Failover。
架构特点
MGR集群主从复制延迟比异步复制小很多，可以说基本没有延迟
数据一致性保障：确保集群中大部分节点收到日志
多节点写入支持：多写模式下支持集群中的所有节点都可以写入
Fault Tolerance：确保系统发生脑裂等故障依然可用，双写对系统无影响
需要依赖HA+Keepalive插件，实现主备库各自的负载均衡和故障转移，才可以保障集群服务真正意义上的高可用
11
—
MySQL InnoDB Cluster集群架构
架构描述
MySQL从8.0版本后开始支持MySQL InnoDB Cluster集群模式，MySQL InnoDB Cluster基于群组复制，提供了易于管理的API、应用故障转移和路由、易于配置，提供比群组复制更高级别的，完全高可用的数据库解决方案。
MySQL InnoDB Cluster 主要由三个模块构成：1、MySQL Server：该模块支持Group Replication 功能，实现了组内通信、故障转移、故障恢复；2、MySQL-Shell：实现快速部署，主要提供了一套AdminAPI，可以自动化配置Group Replication，让我们无须再手动配置cluster中group replication相关参数。3、MySQL-Router：MySQL Router 是一个轻量级的中间件，可以提供负载均衡和应用连接的故障转移，在应用程序和任何后端MySQL服务器之间提供透明路由。自动根据MySQL InnoDB Cluster中的metadata自动调整。
架构特点
优点：MySQL InnoDB Cluster具备MySQL MGR所有优点；MySQL InnoDB Cluster集群本身具备故障转移、故障恢复、读写分离、负载均衡等高可用模块，可同时用于读操作、写操作都都密集的应用；MySQL官方提供的MySQL Router模块，可以提供负载均衡和应用连接的故障转移，不依赖第三方插件
缺点：只支持InnoDB存储引擎，且表必须都有主键；建议事物隔离级别Read Commit；多主模式下不支持序列化事务隔离级别；多主模式下不支持并发DDL和DML，这对于DDL在其他实例上操作有未检出的风险；多主模式下不支持并发DDL和DML，这样对于DDL在其他实例上操作有未检出的风险；多主模式下可能导致未知冲突，因为多级外键依赖对引起多级操作，建议打开
group_replication_enforce_update_everywhere_checks=ON；针对于大事务操作，超过5秒未提交，会导致组通信失败；多主模式下：select * for update 会导致死锁，因为这个锁并非全组共享；部分复制不支持：组复制下，设置部分复制，会过滤事物，导致组事物不一致；不支持Savepoints和Replcation event checksums。
12
—
总结
前人栽过的树，让我们乘了凉，感激之情溢于言表
今天种下新苗，愿你们得此凉，奋起之心跃然纸上
以上是关于MySQL踏浪之途第三遍的主要内容，如果未能解决你的问题，请参考以下文章