MySQL 05主从集群、高可用方案（分库分表的前章）

1、主从集群

这次实验的目的，并不是要大家就学会去搭建MySQL集群，而是带大家对生产环境下的MySQL架构有一定的理解，能够在自己的生产项目中运用上MySQL的生产架构。

同时，也是为后面学习ShardingSphere 分库分表打下基础。

主从集群、主从复制、读写分离 三者之间的关系

1、理论基础

主从架构有什么用？通过搭建MySQL主从集群，可以缓解MySQL的数据存储以及访问的压力。 主从集群的作用，在我们开发角度更大的是作为读写分离的支持

1. 数据安全

   • **给主服务增加一个数据备份。**基于这个目的，可以搭建主从架构，或者也可以基于主从架构搭建互主的架构。

2. 读写分离

   • ​ 对于大部分的JAVA业务系统来说，都是读多写少的，读请求远远高于写请求。这时，当主服务的访问压力过大时，可以将数据读请求转为由从服务来分担，主服务只负责数据写入的请求，这样大大缓解数据库的访问压力。

   • ​ 要理解，MySQL的主从架构+主从复制只是实现读写分离的一个基础。根据读写分离实现的层级，读写分离一般有两种方式实现，通过应用程序层实现和通过中间件层实现。

     • 通过应用程序层实现是指在网页内部实现数据查询语言和数据操作语言分别指向不同的MySQL主库和从库。

       这样做的优点是减少了部署的难度，部署安装即用，且性能较好，

       缺点是当架构拓展时也要修改代码，难以实现自动分库、分表等高级操作，在一些大型应用场景中不是很适用。

       

     • 通过中间件来实现，比如ShardingSphere。

       通过中间件层实现是指在应用程序层统一将所有的SQL语句指向一个中间件设备，由该中间件设备将不同的SQL语句指向不同的数据库服务器进行操作。

       这样做的优点是架构设计更加灵活，对业务代码影响较小，可移植性好，并且可以实现高级控制，

       但是这种架构需要专业的运维人员对架构进行维护。

       

3. 故障转移-高可用:

   • 当MySQL主服务宕机后，可以由一台从服务切换成为主服务，继续提供数据读写功能。

   • 对于高可用架构，主从数据的同步也只是实现故障转移的一个前提条件，要实现MySQL主从切换，还需要依靠一些其他的中间件来实现。比如MMM、MHA、MGR。

   • 在一般项目中，如果数据库的访问压力没有那么大，那读写分离不一定是必须要做的，但是，主从架构和高可用架构则是必须要搭建的。

2、同步的原理

​ MySQL服务的主从架构一般都是通过binlog日志文件来进行的。

• 即在主服务上打开binlog记录每一步的数据库操作，然后从服务上会有一个IO线程，负责跟主服务建立一个TCP连接，请求主服务将binlog传输过来。
• 这时，主库上会有一个IO dump线程，负责通过这个TCP连接把Binlog日志传输给从库的IO线程。
• 接着从服务的IO线程会把读取到的binlog日志数据写入自己的relay日志文件中。然后从服务上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目的。
• 我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。

MySQL的binlog不光可以用于主从同步，还可以用于缓存数据同步等场景。

例如Canal，可以模拟一个slave节点，向MySQL发起binlog同步，然后将数据落地到Redis、Kafka等其他组件，实现数据实时流转。

搭建主从集群时，有两个必要的要求：

• 双方MySQL必须版本一致。至少需要主服务的版本低于从服务
• 两节点间的时间需要同步。

3、搭建主从集群

1. 配置master主服务器

   配置说明：主要需要修改的是以下几个属性：

   server-id：服务节点的唯一标识。需要给集群中的每个服务分配一个单独的ID。

   log_bin：打开Binlog日志记录，并指定文件名。

   log_bin-index：Binlog日志文件

2. 配置slave从服务

   配置说明：主要需要关注的几个属性： server-id：服务节点的唯一标识 relay-log：打开从服务的relay-log日志。 log-bin：打开从服务的bin-log日志记录。

3. 主从集群测试

   • 主从复制注意：
     • 写操作只能在主库操作，主库会自动同步到从库中
     • 如果在从库中写，从库不会同步到主库中，出现数据不一致的情况
     • 数据永远是 单向同步的

4. 集群搭建扩展（关注）

   1. 全库同步与部分同步

      • 我们目前配置的主从同步是针对全库配置的，而实际环境中，一般并不需要针对全库做备份，而只需要对一些特别重要的库或者表来进行同步。

   2. 读写分离配置

      • 为什么要做读写分离？
        • 因为MySQL的主从集群架构下，数据同步是单向的，只能从主同步到从。所以为了保证数据一致，需要保证数据只能在主服务上写，从服务只能进行数据读取。这个功能就是大名鼎鼎的读写分离！ShardingSphere是业务端做读写分离的一个框架工具。
        • 我们要注意，目前我们的这个MySQL主从集群是单向的，也就是只能从主服务同步到从服务，而从服务的数据表更是无法同步到主服务的。
        • 所以，在这种架构下，为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。这个功能，就是大名鼎鼎的读写分离。
        • 但是这里要注意下，mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现。这也是我们后面要学的ShardingSphere的一个重要功能。

   3. ​ 其他集群方式

      我们到这里搭建出了一个一主一从的MySQL主从同步集群，具有了数据同步的基础功能。而在生产环境中，通常会以此为基础，根据业务情况以及负载情况，搭建更大更复杂的集群。

      • 为了进一步提高整个集群的读能力，可以扩展出一主多从。而为了减轻主节点进行数据同步的压力，可以继续扩展出多级从的主从集群。
      • ​ 为了提高整个集群的高可用能力，可以扩展出多主的集群。
      • 我们也可以扩展出互为主从的互主集群甚至是环形的主从集群，实现MySQL多活部署。

   4. GTID同步集群

      • ​ 上面我们搭建的集群方式，是基于Binlog日志记录点的方式来搭建的，这也是最为传统的MySQL集群搭建方式。
      • 另外一种搭建主从同步的方式，是GTID搭建方式。这种模式是从MySQL5.6版本引入的。
        • GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。

4、集群扩容

​ 我们现在已经搭建成功了一主一从的MySQL集群架构，那要扩展到一主多从的集群架构，其实就比较简单了，只需要增加一个binlog复制就行了。

​ 但是如果我们的集群是已经运行过一段时间，这时候如果要扩展新的从节点就有一个问题，之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时，就需要增加一个数据复制的操作。

• MySQL的数据备份恢复操作相对比较简单，可以通过SQL语句直接来完成。具体操作可以使用mysql的bin目录下的mysqldump工具。

  mysqldump -u root -p --all-databases > backup.sql
  #输入密码
  

• ​ 通过这个指令，就可以将整个数据库的所有数据导出成backup.sql，然后把这个backup.sql分发到新的MySQL服务器上，并执行下面的指令将数据全部导入到新的MySQL服务中。

  mysql -u root -p < backup.sql
  #输入密码
  

  这样新的MySQL服务就已经有了所有的历史数据，然后就可以再按照上面的步骤，配置Slave从服务的数据同步了。

5、异步复制机制 & 半同步复制

1、理解半同步复制

到现在为止，我们已经可以搭建MySQL的主从集群，互主集群，但是我们这个集群有一个隐患，就是有可能会丢数据。这是为什么呢？这要从MySQL主从数据复制分析起。

1. ​ MySQL主从集群默认采用的是一种异步复制的机制。主服务在执行用户提交的事务后，写入binlog日志，然后就给客户端返回一个成功的响应了。而binlog会由一个dump线程异步发送给Slave从服务。

由于这个发送binlog的过程是异步的。主服务在向客户端反馈执行结果时，是不知道binlog是否同步成功了的。这时候如果主服务宕机了，而从服务还没有备份到新执行的binlog，那就有可能会丢数据。

那怎么解决这个问题呢，这就要靠MySQL的半同步复制机制来保证数据安全。

2. 半同步复制机制是一种介于异步复制和全同步复制之前的机制。

   **主库在执行完客户端提交的事务后，并不是立即返回客户端响应，而是等待至少一个从库接收并写到relay log中，才会返回给客户端。**MySQL在等待确认时，默认会等10秒，如果超过10秒没有收到ack，就会降级成为异步复制。

这种半同步复制相比异步复制，能够有效的提高数据的安全性。

• 但是这种安全性也不是绝对的，他只保证事务提交后的binlog至少传输到了一个从库，并且并不保证从库应用这个事务的binlog是成功的。

• 另一方面，半同步复制机制也会造成一定程度的延迟，这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时，主服务需要等待的时间就会更长，要等到从服务的服务恢复或者请求超时才能给用户响应。

2、搭建半同步复制集群

todo 本篇文章不做说明，后期有机会，可以单独出一篇文章

6、主从架构的数据延迟问题

• 在我们搭建的这个主从集群中，有一个比较隐藏的问题

  就是这样的主从复制之间会有延迟。 这在做了读写分离后，会更容易体现出来。 即数据往主服务写，而读数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不到。

• 出现这个问题的根本在于：

  面向业务的主服务数据都是多线程并发写入的，而从服务是单个线程慢慢拉取binlog，这中间就会有个效率差。 所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。

• MySQL自5.7版本后就已经支持并行复制了。

  可以在从服务上设置slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK，这就可以了。

2、MySQL的高可用方案

如果是MySQL主服务挂了，从服务是没办法自动切换成主服务的。而如果要实现MySQL的高可用，需要借助一些第三方工具来实现。

• 常见的MySQL集群方案有三种: MMM、MHA、MGR。这三种高可用框架都有一些共同点：

  对主从复制集群中的Master节点进行监控 自动的对Master进行迁移，通过VIP。 重新配置集群中的其它slave对新的Master进行同步

MMM（使用较少）

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

• 他是通过一个VIP(虚拟IP)的机制来保证集群的高可用。

  整个集群中，在主节点上会通过一个VIP地址来提供数据读写服务，而当出现故障时，VIP就会从原来的主节点漂移到其他节点，由其他节点提供服务。

• 优点：

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

• 缺点：

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

• 适用场景：

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

MHA（目前用的最多）

• Master High Availability Manager and Tools for MySQL

  这个工具专门用于监控主库的状态，当发现master节点故障时，会提升其中拥有新数据的slave节点成为新的master节点

• 优点

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

• 缺点

  MHA需要自行开发VIP转移脚本。 MHA只监控Master的状态，未监控Slave的状态

MGR

• 是MySQL官方在5.7.17版本正式推出的一种组复制机制。主要是解决传统异步复制和半同步复制的数据一致性问题。

• 由若干个节点共同组成一个复制组，一个事务提交后，必须经过超过半数节点的决议并通过后，才可以提交。

• 适用的业务场景：

  对主从延迟比较敏感 希望对对写服务提供高可用，又不想安装第三方软件 数据强一致的场景

3、分库分表

主从集群的作用，在我们开发角度更大的是作为读写分离的支持

分库分表就是业务系统将数据写请求分发到master节点，而读请求分发到slave节点的一种方案，可以大大提高整个数据库集群的性能。

但是要注意，分库分表的一整套逻辑全部是由客户端自行实现的。 而对于MySQL集群，数据主从同步是实现读写分离的一个必要前提条件

分库分表有什么用（优点）

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

• 例如：微服务架构中，每个服务都分配一个独立的数据库，这就是分库。而对一些业务日志表，按月拆分成不同的表，这就是分表。

分库分表的方式

分库分表包含分库和分表 两个部分，而这两个部分可以统称为数据分片，其目的都是将数据拆分成不同的存储单元。

从分拆的角度上，可以分为垂直分片和水平分片。

垂直分片：(按业务分库)

按照业务来对数据进行分片，又称为纵向分片。 他的核心理念就是分库专用。 微服务的思想

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

水平分片：（通过某个字段，根据某种规则将数据拆分）

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

• 常用的分片策略有：

  ​ 取余\取模 ： 优点 均匀存放数据，缺点 扩容非常麻烦 ​ 按照范围分片 ： 比较好扩容， 数据分布不够均匀 ​ 按照时间分片 ： 比较容易将热点数据区分出来。 ​ 按照枚举值分片 ： 例如按地区分片 ​ 按照目标字段前缀指定进行分区：自定义业务规则分片 水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

一般来说，在系统设计阶段就应该 根据业务耦合松紧来确定垂直分库，垂直分表方案，

在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。

若数据量极大，且持续增长，再考虑水平分库水平分表方案

分库分表的缺点

• 事务一致性问题

  原本单机数据库有很好的事务机制能够帮我们保证数据一致性。

  但是分库分表后，由于数据分布在不同库甚至不同服务器， 不可避免会带来分布式事务问题。

• 跨节点关联查询问题

  在没有分库时，我们可以进行很容易的进行跨表的关联查询。 但是在分库后，表被分散到了不同的数据库，就无法进行关联查询了。

  这时就需要将关联查询拆分成多次查询，然后将获得的结果进行拼装。

• 跨节点分页、排序函数

  跨节点多库进行查询时，limit分页、order by排序等问题，就变得比较复杂了。

  需要先在不同的分片节点中将数据 进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。

  这时非常容易出现内存崩溃的问题。

• 主键避重问题

  在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，

  某个分区数据 库生成的ID无法保证全局唯一。

  因此需要单独设计全局主键，以避免跨库主键重复问题。

• 公共表处理

  实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。

  这一类表一般就需要在每个数据库中都保存一份，并且所有对公共表的操作都要分发到所有的分库去执行。

• 运维工作量

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

什么时候需要分库分表

• 建议MySQL单表记录如果达到500W这个级别，或者单表容量达到2GB，一般就建议进行分库分表

• 一般对于用户数据这一类后期增长比较缓慢的数据，一般可以按照三年左右的业务量来预估使用人数，按照标准预设好分库分表的方案。

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

• 最后，一旦用到了分库分表，就会表现为对数据查询业务的灵活性有一定的影响

  • 例如如果按userId进行分片，那按age来进行查询，就必然会增加很多麻烦。
  • 如果再要进行排序、分页、聚合等操作，很容易就扛不住了。

• 这时候，都要尽量在分库分表的同时，再补充设计一个降级方案，例如将数据转存一份到ES，ES可以实现更灵活的大数据聚合查询。

常见的分库分表组件

• shardingSphere

  • harding-JDBC是当当网研发的开源分布式数据库中间件，他是一套开源的分布式数据库中间件解决方案组成的生态圈
  • 它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成

• mycat

  • 基于阿里开源的Cobar产品而研发
  • MyCAT虽然是从阿里的技术体系中出来的，但是跟阿里其实没什么关系。

• DBLE

  • 其中分布式中间件可以认为是MyCAT的一个增强版，专注于MySQL的集群化管理