目录
一、什么是主从复制
顾名思义，从库按照主库的构造、数据 复制出来一个同样的数据库环境，mysql默认一般为异步同步数据，还可以设置成半同步。
二、主从复制原理
1.1 主从复制涉及到4个文件，3个线程
1.1 文件：
主库：binlog文件（二进制文件）
从库：
relaylog（中继日志，从机本身会有binlog文件，relaylog是来记录主库binlog的文件）
master.info（存放主库信息的文件）
relaylog.info （记录relaylog存储ID到多少的文件）
1.2 线程：
DUMP：主机二进制有更新与从机IO线程进行交接的线程
IO_T：从机从DUMP线程拿到新数据写到relaylog的线程
SQL_T：SQL_T得知IO_T拿到新数据后执行sql语句
1.2 主从复制工作（过程）原理：
1.从库执行change master to 命令(主库的连接信息+复制的起点)
2.从库会将以上信息,记录到master.info文件
3.从库执行 start slave 命令,立即开启IO_T和SQL_T
4. 从库 IO_T,读取master.info文件中的信息,获取到IP,PORT,User,Pass,binlog的位置信息
5. 从库IO_T请求连接主库,主库专门提供一个DUMP_T,负责和IO_T交互
6. IO_T根据binlog的位置信息(mysql-bin.000004 , 444),请求主库新的binlog
7. 主库通过DUMP_T将最新的binlog,通过网络TP给从库的IO_T
8. IO_T接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
9.IO_T将TCP/IP缓存中数据,转储到磁盘relaylog中.
10. SQL_T读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
11. SQL_T会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
12. 从库会自动purge应用过relay进行定期清理
补充说明:
一旦主从复制构建成功,主库当中发生了新的变化,都会通过dump_T发送信号给IO_T,增强了主从复制的实时性。
三、异步复制、全同步复制、半同步复制解释
1.1 异步复制：
mysql默认的复制就是异步的，主库在执行完客户端提交的事务后会立刻将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题出来，主如果crash掉了，主上提交的事务可能并没有传到从库，如果此时强行将从提升为主，可能导致主上的数据不全。
1.2 全同步复制
当主库执行完一个事务，所有从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完事务才能返回，所以全同步复制的性能必然会收到严重影响。
1.3 半同步复制
这种复制方式是介于全同步复制和异步复制之间的一种，主库只需要等待至少一个从库节点收到并且Flush binlog到relaylog文件即可。不需要等待所有从库给主库反馈。同事，这里只是一个收到的反馈，而不是已经完全完成并且提交反馈，如此，节省了很多时间。
1.4 选型及设置说明
想选型得先了解三种复制方式的优弊端，异步同步性能最高，适用于普通互联网行业，全同步复制，既吃网速，又吃设备硬件，一般行业不会选择，半同步足够用。
四、MHA简介
MHA目前在mysql高可用方面是一个相对成熟的解决方案，是一套优秀的作为mysql高可用高可用性环境下故障切换和主从提升的高可用软件。在mysql故障切换过程中，MHA能做到在10~0秒之内自动完成数据库的故障切换操作，并且在运行故障切换过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA还提供在线主库切换功能，能过程够安全的切换当前运行的主库到一个新的主库中（以从换主），大概0.5~2秒内即可完成。
该软件由两部分组成：HMA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master—slave集群，也可以部署在一台slave节点上，当master出现故障时，他可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个Failover过程对应用程序完全透明。
MHA在生产环境下的作用
一主多从的环境下，mysql的主从复制是异步或者半同步。
master发生故障到时候，有一部分（或者全部）的slave未能获取到最新的binlog，造成slave之间的binlog转发发生偏差，假如master宕机后，id=102的binlog没发送到任何一个slave上，slave2只有101，slave3只收到了100的binlog。如果想要正确恢复，master必须发出id=102的binlog，还要消除各个slave之间的差异性。MHA可以全自动的处理这些！
最佳方案
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如：如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。
使用半同步复制，可以降低数据丢失的风险~
因为有一个slave收到了最新的binlog日志，Failover会自动转移到数据最新的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从架构，要搭建MHA，要求一个复制集群中必须至少有三台服务器，一主二从，一台master，一台备用master，一台slave。出于机器成本考虑，淘宝也在该基础上进行了改造，目前淘宝THMA已经支持一主一从了。
五、工作流程
1. 把宕机的master二进制日志保存下来。
2. 找到binlog位置点最新的slave
3. 在binlog位置点最新的slave上用relaylog（差异日志）修复其他的slave
4. 将宕机的master上保存下来的二进制日志恢复到含有最新点的slave上。
5. 将含有最新位置点binlog所在的lave提升为master。
6. 将其他slave重新指向新提升的master，并开启主从复制。
监控所有node节点MHA功能说明：
自动故障切换(failover)
前提是必须有三个节点存在，并且有两个从库
(1)选主前提，按照配置文件的顺序进行，但是如果此节点后主库100M以上relay-log 就不会选
(2)如果你设置了权重，总会切换带此节点；一般在多地多中心的情况下，一般会把权重设置在本地节点。
(3)选择s1为新主
(4)保存主库binlog日志
重新构建主从
(1)将有问题的节点剔除MHA
进行第一阶段数据补偿，S2缺失部分补全90
(2)s1切换角色为新主，将s2指向新主S1
s2 change master to s1
(3) 第二阶段数据补偿
将保存过来的新主和原有主缺失部分的binlog，应用到新主。
(4)虚拟IP漂移到新主，对应用透明无感知
(5)通知管理员故障切换
909
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
