MySQL生产环境高可用架构详解_mysql高可用

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.01 sec)
mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
2 rows in set, 1 warning (0.01 sec)
mysql> set global rpl_semi_sync_slave_enabled = on;
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
2 rows in set, 1 warning (0.00 sec)
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

3、主从集群与读写分离

到这里可以看到，在MySQL主从架构中，是需要严格限制从服务的数据写入的，一旦从服务有数据写入，就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。
如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设为1( set global read_only=1; )。这样就可以限制用户写入数据。但是这个属性有两个需要注意的地方：
 
1、read_only=1设置的只读模式，不会影响slave同步复制的功能。 所以在MySQL slave库中设定了read_only=1后，通过 "show slavestatus\G" 命令查看salve状态，可以看到salve仍然会读取master上的日志，并且在slave库中应用日志，保证主从数据库同步一致；
2、read_only=1设置的只读模式， 限定的是普通用户进行数据修改的操作，但不会限定具有super权限的用户的数据修改操作。 在MySQL中设置read_only=1后，普通的应用用户进行insert、update、delete等会
产生数据变化的DML操作时，都会报出数据库处于只读模式不能发生数据变化的错误，但具有super权限的用户，例如在本地或远程通过root用户登录到数据库，还是可以进行数据变化的DML操作； 如果需要限定
super权限的用户写数据，可以设置super_read_only=0。另外 如果要想连super权限用户的写操作也禁止，就使用"flush tables with readlock;"，这样设置也会阻止主从同步复制！
 

三、了解MySQL的其他高可用方 案

这一部分方案只需要了解即可，因为一方面，这些高可用方案通常都是运维需要考虑的事情，作为开发人员没有必要花费太多的时间精力，偶尔需要用到的时候能够用起来就够了。另一方面，随着业界技术的不断
推进，也会冒出更多的新方案。例如ShardingSphere的5.x版本的目标实际上就是将ShardingSphere由一个数据库中间件升级成一个独立的数据库平台，而将MySQL、PostGreSql甚至是RocksDB这些组件作为数据库的后端支撑。等到新版本成熟时，又会冒出更多新的高可用方案。

1、MMM

MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理

器)是一套由Perl语言实现的脚本程序，可以对mysql集群进行监控和故障迁移。他

需要两个Master，同一时间只有一个Master对外提供服务，可以说是主备模式。

他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。整个集群中，在主节点上

会通过一个VIP地址来提供数据读写服务，而当出现故障时，VIP就会从原来的主节

点漂移到其他节点，由其他节点提供服务。

优点：

提供了读写VIP的配置，使读写请求都可以达到高可用 工具包相对比较完善，不需要额外的开发脚本 完成故障转移之后可以对MySQL集群进行高可用监控

缺点：

故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率 目前MMM社区已经缺少维护，不支持基于GTID的复制

适用场景：

读写都需要高可用的

基于日志点的复制方式

2、MHA

Master High Availability Manager and Tools for MySQL。是由日本人开发的一 个基于Perl脚本写的工具。这个工具专门用于监控主库的状态，当发现master节点 故障时，会提升其中拥有新数据的slave节点成为新的master节点，在此期间， MHA会通过其他从节点获取额外的信息来避免数据一致性方面的问题。MHA还提 供了mater节点的在线切换功能，即按需切换master-slave节点。MHA能够在30秒 内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性。在淘宝内 部，也有一个相似的TMHA产品。

MHA是需要单独部署的，分为Manager节点和Node节点，两种节点。其中 Manager节点一般是单独部署的一台机器。而Node节点一般是部署在每台MySQL 机器上的。 Node节点得通过解析各个MySQL的日志来进行一些操作。 Manager节点会通过探测集群里的Node节点去判断各个Node所在机器上的 MySQL运行是否正常，如果发现某个Master故障了，就直接把他的一个Slave提升

为Master，然后让其他Slave都挂到新的Master上去，完全透明。

优点：

MHA除了支持日志点的复制还支持GTID的方式 同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每 次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

缺点：

MHA需要自行开发VIP转移脚本。

MHA只监控Master的状态，未监控Slave的状态

3、MGR

MGR：MySQL Group Replication。 是MySQL官方在5.7.17版本正式推出的一种 组复制机制。主要是解决传统异步复制和半同步复制的数据一致性问题。 由若干个节点共同组成一个复制组，一个事务提交后，必须经过超过半数节点的决 议并通过后，才可以提交。引入组复制，主要是为了解决传统异步复制和半同步复 制可能产生数据不一致的问题。MGR依靠分布式一致性协议(Paxos协议的一个变 体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(方案落地后

是否可靠还有待商榷)。 支持多主模式，但官方推荐单主模式：

多主模式下，客户端可以随机向MySQL节点写入数据

单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节 点都可以进行读请求处理

优点：

高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提 供一致数据安全保证；

高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同 节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且 内置了自动化脑裂防护机制；

高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上 同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自 动更新组信息，自动维护新的组信息；

高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都 在主上进行；多主模式下，所有server都可以同时处理更新操作。

缺点:

仅支持InnoDB引擎，并且每张表一定要有一个主键，用于做write set的冲突检 测； 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set； 主从状态信息存于表中（--master-info-repository=TABLE 、--relay-loginfo-repository=TABLE），--log-slave-updates打开； COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景 目前一个MGR集群最多支持9个节点 不支持外键于save point特性，无法做全局间的约束检测与部分事务回滚

适用的业务场景：

对主从延迟比较敏感

希望对对写服务提供高可用，又不想安装第三方软件

数据强一致的场景

四、分库分表方案介绍

1、分库分表有什么用

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立 的数据库拆分成若干数据库组成 ，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变 小，从而达到提升数据库性能的目 的。

例如：微服务架构中，每个服务都分配一个独立的数据库，这就是分库。而对一些

业务日志表，按月拆分成不同的表，这就是分表。

2、分库分表的方式

分库分表包含分库和分表 两个部分，而这两个部分可以统称为数据分片，其目的都 是将数据拆分成不同的存储单元。另外，从分拆的角度上，可以分为垂直分片和水 平分片。

垂直分片： 按照业务来对数据进行分片，又称为纵向分片。他的核心理念就是转 库专用。在拆分之前，一个数据库由多个数据表组成，每个表对应不同的业务。 而拆分之后，则是按照业务将表进行归类，分布到不同的数据库或表中，从而将 压力分散至不同的数据库或表。例如，下图将用户表和订单表垂直分片到不同的

数据库：

垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对业务需求快速 变化的。而且，他也无法真正的解决单点数据库的性能瓶颈。垂直分片可以缓解数 据量和访问量带来的问题，但无法根治。如果垂直分片之后，表中的数据量依然超 过单节点所能承载的阈值，则需要水平分片来进一步处理。

水平分片：又称横向分片。相对于垂直分片，它不再将数据根据业务逻辑分类， 而是通过某个字段(或某几个字段)，根据某种规则将数据分散至多个库或表中， 每个分片仅包含数据的一部分。例如，像下图根据主键机构分片。

常用的分片策略有：

取余\取模 ： 优点 均匀存放数据，缺点 扩容非常麻烦

按照范围分片 ： 比较好扩容， 数据分布不够均匀

按照时间分片 ： 比较容易将热点数据区分出来。

按照枚举值分片 ： 例如按地区分片

按照目标字段前缀指定进行分区：自定义业务规则分片

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表 的标准解决方案。

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表 方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技 术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。

3、分库分表要解决哪些问题

之前说过，分库分表其实并不只是字面意义上的拆分数据，他还有一系列的问题 需要解决。虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但是分布 式的架构在获得收益的同时，也引入了非常多新的问题。而这些，都是一个成熟的 分库分表方案需要考虑的问题。

事务一致性问题

原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分库分表 后，由于数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。 跨节点关联查询问题 在没有分库时，我们可以进行很容易的进行跨表的关联查询。但是在分库后，表 被分散到了不同的数据库，就无法进行关联查询了。 这时就需要将关联查询拆分成多次查询，然后将获得的结果进行拼装。

跨节点分页、排序函数 跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。 需要先在不同的分片节点中将数据 进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。 这时非常容易出现内存崩溃的问题。

主键避重问题

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自 增长将无用武之地，某个分区数据 库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重 复问题。

公共表处理

实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于 高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份，并且 所有对公共表的操作都要分发到所有的分库去执行。

运维工作量

面对散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操 作都变得非常繁重。对于每一次数据读写操作，他们都需要知道要往哪个具体的 数据库的分表去操作，这也是其中重要的挑战之一。

4、什么时候需要分库分表？

在阿里巴巴公布的开发手册中，建议MySQL单表记录如果达到500W这个级别， 或者单表容量达到2GB，一般就建议进行分库分表。而考虑到分库分表需要对数据 进行再平衡，所以如果要使用分库分表，就要在系统设计之初就详细考虑好分库分 表的方案，

这里要分两种情况。

       一般对于用户数据这一类后期增长比较缓慢的数据，一般可以按照三年左右的业 务量来预估使用人数，按照标准预设好分库分表的方案。 而对于业务数据这一类增长快速且稳定的数据，一般则需要按照预估量的两倍左 右预设分库分表方案。并且由于分库分表的后期扩容是非常麻烦的，所以在进行分 库分表时，尽量根据情况，多分一些表。最好是计算一下数据增量，永远不用增加 更多的表。

       另外，在设计分库分表方案时，要尽量兼顾业务场景和数据分布。在支持业务场 景的前提下，尽量保证数据能够分得更均匀。

        最后，一旦用到了分库分表，就会表现为对数据查询业务的灵活性有一定的影 响，例如如果按userId进行分片，那按age来进行查询，就必然会增加很多麻烦。如 果再要进行排序、分页、聚合等操作，很容易就扛不住了。这时候，都要尽量在分 库分表的同时，再补充设计一个降级方案，例如将数据转存一份到ES，ES可以实现 更灵活的大数据聚合查询。