Mysql主从架构及几种高可用方案
一、主从复制
1、主从概念、优点及用途
概念： 主库提供读写操作，从库对外提供读操作。
2、主从复制的原理
主从复制：涉及到
2个日志(binlog、relaylog日志)、
3个线程：master（dump线程）、slave（I/O线程、SQL线程）
主dump线程：数据库中数据更新时，创建一个dump线程通知slave有数据更新，传给slave的IO线程（binlog和更新位置传给slave I/O 线程）
I/O线程：接收到dump线程发来的 binlog文件，存放到本地relay log中
sql线程：读取relay log中的内容，本地做redo操作，将主库事件本地执行一遍，最终保证主从数据的一致性
3、基本过程：
1、主库写入数据并且生成binlog文件，即MySQL将事务串行的写入二进制日志
2、master通知存储引擎提交事务
3、从服务器IO线程连接至master，请求binlog 指定位置读取到从库
4、主服务器接收到请求，会根据slave请求信息分批读取binlog文件，返回给从库IO线程
5、IO线程获取到maser的日志内容、文件、问之后，会将binlog写到slave自身的relay log中。
6、从服务器中SQL 监测到本地Relay Log中新增了日志内容，翻译成SQL 执行，并更新从库数据
优点：
1、故障转移-高可用 主服务宕机后，可以由从服务切换成为主服务
2、读写分离 数据库读请求从服务分担（一些查询大请求，仅查从库）
3、数据安全 数据的热备，后备数据库，避免数据丢失
缺点：
1、正常情况下，数据也会不能实时同步
2、主从服务，主机挂掉，数据丢失问题（mysql默认异步复制，设置半同步复制）
半同步复制：主库执行完客户端提交的事务后，等待至少一个从库接收并写到relay log中，才返回。等待确认时，默认会等10秒，如果超过10秒没有收到ack，会降级成异步复制。
3、主库宕机，无法自动切换
二、高可用方案
2.1 MMM
有一套脚本对集群进行监控和故障转移，需要2个master，通过一个VIP机制保证集群高可用，当主节点故障，vip从原来的主节点漂移到其它节点。
优点：
1、部署简单，不需要额外开发脚本
2、高可用，出现故障自动切换
缺点：
1、故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率
2、社区缺少维护，不支持GTID
适用场景：
1、读写都需要高可用
2、基于binlog复制
2.2 MHA（公司主流使用）
一个mysql解决方案，通过一套脚本来保证数据库系统的高可用.在宕机的时间内（通常10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，
优点：
1、支持日志点复制、GTID复制
2、同MMM相比，会尝试从旧的Master中恢复旧的二进制日志，未必每次都能成功
缺点：
1、需要自行开发vip转移脚本
2、只监控Master状态，未监控Slave状态
2.3 MGR
mysql 5.7.17版本推出的组复制机制，主要是解决传统 异步复制和半同步复制的数据一致性问题
由若干个节点共同组成一个复制组，一个事务提交后，必须经过超过半数节点的决议并通过后，才可以提交。
优点：
1、基本无延迟，延迟比异步的小很多
2、数据的强一致性，可以保证数据事务不丢失
缺点：
1、仅支持innodb，且每个表必须提供主键
2、只能用在GTID模式下，且日志格式为row格式
适用场景：
1、对主从延迟比较敏感
2、数据强一致的场景
三、主从延迟
延迟的原因：
1、从库性能比主库差
2、从库读耗费大量cpu资源
3、大事务执行（比如 insert ... select ...,产生多条日志，只能等事务提交才可以传输）
4、主库DDl（alter、drop、create ）
比如主库增加字段执行很长时间，从库也消耗很多时间
5、锁冲突
从库一些select ... for update
减少主从延迟：
1、提供从库机器的配置，提供主库写与从读的效率差
2、优化sql，避免慢sql
3、降低多线程大事务并发执行的概率
4、缩短主库与从库服务器的距离，提升端口带宽，减少binlog延时
5、打开参数配置，设置多个库并行复制
1、开启mysql并行复制
设置slave_parallel_workers > 0
2、 slave_parallel_type = LOGICAL_CLOCK 基于组提交的并行复制
DATABASE .. 库...