主从复制如何工作
在主库把数据记录到binlog（二进制日志）。
备库开IO线程把binlog复制到自己的relaylog（中继日志）。
备库读取中继日志，重放到备库上。
半同步复制半同步复制可以确保备库拥有主库数据的拷贝，减少了数据丢失的危险。
半同步复制在提交过程中增加了一个延迟：提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输到一台备库上。
半同步不会阻塞主库上的事务提交，只有通知客户端被延迟了。
备库在接收到事务后发送ack而不是完成事务后发送。
如果备库一直没有回应，会超时转化为异步复制模式。
配置步骤 在master服务器上开启binlog开启gtid。
建立同步所用的数据库账号。
使用master_data参数备份数据库。
把备份文件传输到slave。
开启binlog开启gtid。
恢复master上的备份数据库。
使用change master配置链路。
使用start slave启动复制。
slave请求master的增量日志依赖于日志偏移量。
配置链路时需要指定参数。
支持MMM和MHA。
GTID复制
全局事务ID唯一，GTID=source_id:transaction_id。
slave增量同步master的数据依赖于其未同步的事务ID。
配置链路时，slave根据已经同步的事务ID继续自动同步。
支持MHA。
复制方式选择
兼容老版本和MMM选择日志点复制。
其他选择GTID复制。
MMM架构和MHA架构 MMM和MHA架构的作用
对主从复制集群中的master的健康监控。
当master宕机后把写VIP迁移到新的master。
重新配置集群中的其他slave对新的master同步。
MMM的主从复制架构
MMM是perl语言开发的用于管理MySQL主主同步架构的工具包。
主要作用：管理MySQL的主主复制拓扑，在主服务器失效时，进行主备切换和故障转移。
MMM无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高的场景。（因为主备上的数据不一定是最新的，可能还没从库的新。解决方法：开启半同步）。
VIP是基于ARP协议，因此所有节点必须处于同一局域网。
SLAVE：
已复制日志的恢复。
使用Change Master命令配置新主。
主备：
关掉read_only。
迁移写VIP到新主。
MMM架构的配置步骤配置主主复制的集群架构。
安装centos的yum扩展包。
安装所需的perl支持包。
安装mmm工具包。
配置并启用mmm服务。
提供了读写VIP的配置。
MMM缺点
故障切换会丢事务(主备使用半同步复制解决)。
不支持GTID。
社区不活跃。
MHA故障转移步骤
选出最新更新的slave。
尝试从宕机的master保存二进制日志。
应用差异的中继日志给到其他slave。
应用从master保存的二进制日志。
提升选举的slave为新的master。
配置其他slave向新的master同步。
MHA需要的资源1主DB。
2-N从DB。
n+2IP地址。
监控用户。
复制用户。
配置一主多从的复制架构。
安装centos的yum扩展源和依赖包。
配置集群内各主机的ssh免认证。
各节点安装mha_node软件。
管理节点安装mha_manager。
配置并启动mha管理进程。
基于gtid和日志点。
选举最合适的slave成为master。
MHA缺点
需要自行开发写vip脚本。
只监控master。
适用场景
使用gtid。
一主多从。
更少的数据丢失场景。
如何减小主从复制的延迟 主从复制延迟的原因执行了大事务(解决：化为多个小事务)。
解决方法
多线程复制。
使用MGR复制架构(类似PXC)。
MGR架构
MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用解决方案，以插件形式提供。
MGR基于分布式Paxos协议，实现组复制，保证数据一致性。有故障检测和自动选主功能。
提供单主模式与多主模式，多主模式支持多点写入。
基于ROW格式的二进制日志文件和GTID特性。
实现原理MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。