高可用MySQL的整体解决方案、体系化原理和指导思路

一、常见的高可用MySQL解决方案

 1.1、主从复制解决方案

主从复制解决方案实现原理

主从复制的整体逻辑是： 《1》客户端需要写入数据，一般是先写到主库【即：主库启动就开启binlog功能（实现将写入到主库的每一个SQL操作都会做记录）】； 《2》与此同时主库在启动的时候就启动了【load dump线程】（该线程的主要作用是监测binlog的变化，一旦监测到binlog有变化就将变化的内容发送到所有从库）； 《3》从库的【IO线程】是用来接收处理主库发送来的binlog日志（该线程接收到binlog日志后会在本地生成【中继日志(relay log)并不断地追加写入】中继日志写入到从库磁盘后会返回一个响应给到主库；主库接收到响应就认为从库接收到的内容写入成功了） 《4》从库的【SQL线程】是监测中继日志(Relay Log)的，当监测到中继日志变动后该线程会立刻解析中继日志的内容，并且将中继日志上的SQL内容都全部执行一遍(又叫做回放)这样就实现了从库和主库的数据同步。
MySQL Replication是一个从Master复制到一个或多个Slave的、异步的过程，在Master与Slave之间实现整个复制过程主要由三个线程来完成，其中一个IO线程在Master端，另两个线程（Sql线程和IO线程）在Slave端。         要实现Mysql Replication，首先要在Master服务器上打开MySQL的Binary Log（产生二进制日志文件）功能，因为整个复制过程实际上就是Slave从Master端获取该日志，然后在自身上将二进制文件解析为SQL语句并完全顺序的执行SQL语句所记录的各种操作。更详细的过程如下：
1	首先Slave上的IO线程连接上Master，然后请求从指定日志文件的指定位置或者从最开始的日志位置之后开始读取日志内容。
2	Master在接收到来自Slave的IO线程请求后，通过自身的IO线程，根据请求信息读取指定日志位置之后的信息，并返回给Slave端的IO线程。返回信息中除了日志所包含的信息之外，还包括此次返回的信息在Master端对应的Binary Log文件的名称以及在Binary Log中的位置。
3	Slave的IO线程接收到信息后，将获取到的日志内容依次写入Slave端的Relay Log文件（类似于mysql-relay-bin.xxxxxx）的最后，并且将读取到的Master端的Binary Log的文件名和位置记录到一个名为master-info文件中，以便在下一次读取的时候能够迅速定位从哪个位置开始往后读取日志信息。
4	Slave的SQL线程在检测到Relay Log文件中新增加了内容后，会马上解析该Relay Log文件中的内容，将日志内容解析为SQL语句，然后在自身执行这些SQL，由于是在Master端和Slave端执行了同样的SQL操作，所以两端的数据是完全一样的。至此整个复制过程结束。
主从复制方案的数据同步非常依赖网络，若主从之间的网络抖动不稳定，会出现主从数据同步不及时的情况，因此主从复制服务器都在同一网段内是比较稳定的。

 1.2、双主复制解决方案

双主复制解决方案

《1》首先通过mysql官方提供的可以配置主从复制（Master-Slave Replication）架构，mysql本身提供了基于binlog的增量数据同步方案。 《2》然后在mysql各主机上配置一个Keepalive脚本监测当前主机，Keepalived使用虚拟路由冗余协议（VRRP）来管理虚拟IP地址，并确保只有一个服务器在处理流量。同时定期检查服务器的健康状态，如果服务器出现故障或不可用，会自动进行切换。这个过程对应用是透明的。 【双主复制适用于中小型企业】。
双主复制解决方案的优势	双主复制解决方案的劣势
配置部署比较简单有效，只有两个节点，不存在多主机选主的问题，故障自动切换，也能提供不错的可用性保障。	Keepalived单点故障，但如果Keepalived本身出现故障或配置不当，可能会导致无法及时切换或切换失败。
	数据一致性较差：在主从复制过程中，由于网络延迟、复制延迟或复制错误等原因，可能会导致主从数据库之间的数据不一致。如果应用程序在故障切换后继续写入数据到旧的主服务器（在Keepalived切换后可能仍被视为活动节点），则会导致数据丢失或冲突。 比如主键冲突，更新丢失等。

 1.3、MHA高可用解决方案

MHA高可用解决方案

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 注意：MHA方案只能在MySQL8.0及其更低的版本使用【MHA的底层还是主从复制，采用半同步复制】；而在MySQL8.0之后的更高版本就不支持了，因为高版本的主从复制、插件等、配置、命令等内容都发生了很大的变化，因此就无法使用了。

MHA有如下五点优势： 《1》故障切换快； 《2》master故障不会导致数据不一致； 《3》无需修改当前的MySQL设置； 《4》无性能下降； 《5》适用于任何存储引擎。

 1.4、MySQL InnoDB Cluster高可用解决方案

MySQL InnoDB Cluster高可用解决方案

MySQL InnoDB Cluster是MySQL官方提供的一种原生高可用性和高可扩展性解决方案。它通过使用Group Replication来实现数据的自动复制和高可用性，并结合MySQL Shell及MySQL Router提供了更全面的高可用解决方案。
MySQL InnoDB Cluster高可用解决方案优势	MySQL InnoDB Cluster高可用解决方案劣势
高可用性         通过MySQL Router自动故障转移和内置的管理功能，确保数据库的高可用性。	性能稳定性一般         一方面多了MySQL Router转发节点。一方面MySQL Servers集群对网络的稳定性要求较高，因为Paxos 协议节点之间需要进行频繁的通信和数据同步。
数据一致性         基于Group Replication 组复制架构，使用 Paxos 协议确保了数据在各个服务器实例之间的强一致性。
易于管理         使用MySQL Shell和AdminAPI，可以简化集群的安装、配置和管理。
可扩展性         可以轻松地添加或删除服务器实例，以适应不同的业务需求。

二、MySQL主从复制的三种类型

 2.1、异步复制

异步复制

在mysql异步复制的情况下，Master Server将自己的binlog通过复制线程传输出去以后，Mysql Master Sever就自动返回数据给客户端，而不管slave上是否接受到了这个二进制日志。 那么，当master宕机后，如果master不能恢复，此时，只能用slave代替master，但slave处于同步落后的状态，就会导致数据丢失。
优点：复制的性能最好	缺点：master挂掉后，slave可能会丢失事务，数据不完整。

 2.2、全同步复制

全同步复制

在全同步复制中，master将自己的binlog写入到bin-log文件并且sync，然后向存储引擎提交事务，然后一直等待ACK，同时要求所有slave接收到binlog，写入relay-log后，并完成日志回放，同时返回ACK确认信息，master在接收到所有从库ACK确认信息后，才将结果返回给客户端。
优点：数据不会丢失	缺点：会阻塞master session，性能太差，非常依赖网络

 2.3、半同步复制

        半同步复制，又分为两种，分别是【传统半同步复制】和【无损半同步复制】；是介于异步复制与全同步复制之间。

  2.3.1、传统半同步复制

传统半同步复制

在传统半同步复制的架构下，master将自己的binlog写入到bin-log文件并且sync，且向存储引擎提交事务，然后一直等待ACK。当至少一个slave接收到binlog后，写入relay-log并返回ACK确认信息。master在接收到从库任意一个ACK确认信息后，就将结果返回给客户端。
优点：会有数据丢失风险，但很低。	缺点：会阻塞master session，性能稍差，非常依赖网络。
由于master是在三段提交的最后commit阶段完成后才等待，所以master的其他session是可以看到这个提交事务的，所以这时候master上的数据和slave不一致，master crash后，slave有数据丢失。

  2.3.2、无损半同步复制

无损半同步复制

master将自己的binlog写入到binlog文件并且sync，之后会进入等待ACK，当至少一个slave接收到binlog之后，写入relay-log并返回ACK确认信息。master接收到从库ACK确认信息之后，向存储引擎提交事务，最终返回给客户端。
优点：数据零丢失，性能好	缺点：会阻塞master session，非常依赖网络
重点：由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的，所以这时候master上的数据和slave一致，master crash后，slave没有丢失数据。

#要开启【无损半同步复制】，需要设置如下几个参数
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 5000

三、补充资料

 3.1、什么是高可用

        高可用需要解决的主要有两个问题：【如何实现数据共享或同步数据】【如何处理故障转移(failover)】。

        数据共享一般的解决方案是通过SAN（Storage Area Network）来实现，而数据同步可以通过rsync软件或DRBD技术来实现；故障转移(failover)的意思就是当服务器死机或出现错误时可以自动切换到其他备用的服务器，不影响服务器上业务系统的运行。

 3.2、MySQL Replication简介、类型和架构

MySQL Replication简介、类型和架构

MySQL Replication是MySQL自身提供的一个主从复制功能（其实也就是一台MySQL服务器（称为Slave）从另一台MySQL服务器（称为Master）上复制日志，然后再解析日志并应用到自身的过程）。 《1》MySQL Replication是单向、异步复制；基本复制过程为（Master服务器首先将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志的循环。这些日志文件可以发送到Slave服务器进行更新。当一个Slave服务器连接Master服务器时，它从Master服务器日志中读取上一次成功更新的位置。然后Slave服务器开始接收从上一次完成更新后发生的所有更新，所有更新完成，将等待主服务器通知新的更新）。 《2》MySQL Replication支持链式复制（也就是说Slave服务器下还可以再链接Slave服务器，同时Slave服务器也可以充当Master服务器角色。这里需要注意的是，在MySQL主从复制中，所有表的更新必须在Master服务器上进行，Slave服务器仅能提供查询操作）。
MySQL Replication支持多种类型的复制方式，常见的有【基于语句的复制】【基于行的复制】【混合类型的复制】
基于语句的复制	MySQL默认采用基于语句的复制，效率很高。基本方式是：在Master服务器上执行的SQL语句，在Slave服务器上再次执行同样的语句。而一旦发现没法精确复制时，会自动选择基于行的复制。
基于行的复制	基本方式为：把Master服务器上改变的内容复制过去，而不是把SQL语句在从服务器上执行一遍， 从mysql5.0开始支持基于行的复制。
混合类型的复制	其实就是上面两种类型的组合，默认采用基于语句的复制，如果发现基于语句的复制无法精确的完成，就会采用基于行的复制。
MySQL Replication常用架构
一主一从	一个Master服务器和一个Slave服务器，这是最常见的架构。
一主多从	一个Master服务器和两个或两个以上Slave服务器。经常用在写操作不频繁、查询量比较大的业务环境中
主主互备	又称双主互备，两个MySQL Server互相将对方作为自己的Master，自己又同时作为对方的Slave来进行复制。主要用于对MySQL写操作要求比较高的环境中，避免了MySQL单点故障。
双主多从	其实就是双主互备，然后再加上多个Slave服务器。主要用于对MySQL写操作要求比较高，同时查询量比较大的环境中。
其实可以根据具体的情况灵活地将Master/Slave结构进行变化组合，但万变不离其宗，在进行Mysql Replication各种部署之前，有一些必须遵守的规则： 《1》同一时刻只能有一个Master服务器进行写操作。 《2》一个Master服务器可以有多个Slave服务器。 《3》无论是Master服务器还是Slave服务器，都要确保各自的Server ID唯一，不然双主互备就会出问题。 《4》一个Slave服务器可以将其从Master服务器获得的更新信息传递给其他的Slave服务器。

 3.3、MySQL的主从复制高可用

        主从复制是MySQL自身提供的一种高可用解决方案（数据同步方法采用的是MySQL replication技术）。【MySQL replication】就是一个日志的复制过程，在复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器，简单说就是从服务器到主服务器拉取二进制日志文件，然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。
    【MySQL replication】技术仅仅提供了日志的同步执行功能，而从服务器只能提供读操作，并且当主服务器故障时，必须通过手动来处理故障转移(failover)，通常的做法是将一台从服务器更改为主服务器。这种解决方案在一定程度上实现了MySQL的高可用性，可以实现90.000%的SLA。
    为了达到更高的可用性，在实际的应用环境中，一般都是采用MySQL replication技术配合高可用集群软件（如：keepalived、Heartbeat）来实现自动故障转移(failover)，这种方式可以实现95.000%的SLA。