mysql主从复制原理

在master与slave之间的实现整个复制过程主要有三个线程完成，其中两个线程（sql线程和IO线程）在slave端，另外一个线程（IO线程）在master端。

要实现，必须打开master的bin-log功能，否则无法实现

mysql复制过程：
1.slave上面的IO线程连接上master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
2.master接收到来自slave的IO线程的请求后，通过负责复制的IO线程根据请求信息读取指定日志指定位置之后的日志信息，返回给slave段的IO线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在master段的bin-log文件的名称以及bin-log的位置
3.slave的IO线程接收到信息后，将接收到的日志内容一次写入到slave端的relay log文件的最末端，并将读取到master端的bin-log的文件名和位置记录到master-info文件中，以便下一次读取的时候能够清楚的告诉master我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我。
4.slave的sql线程检测到的relay log中新增加了内容后，会马上解析该log文件中的内容成为在master端真实执行时候的那些可执行的query语句，并在自身执行这些query，这样，实际上就是master端和slave端执行了同样的query，所以两端的数据是完全一样的
	实际上，在老版本中，mysql的复制实现在slave端并不是由sql线程和IO线程这2个线程共同协作而完成的，而是单独的一个线程来完成所有的工作。这种方式使master端的，bin-log日志，以及解析这些日志，然后再自身执行的这个过程成为一个串行的过程，性能自然会受到较大的限制。

mmm简介 master-master replication manager for mysql
mysql主主复制管理器，故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入）。还能配置任意数量的从服务器进行读负载均衡。还能实现数据备份，节点之间重新同步功能的脚本。

Mmm主要功能由下面三个脚本提供
mmm_mond  负责所有的监控工作的监控守护进程，决定节点的移除等等
mmm_agentd  运行在mysql服务器上的代理守护进程，通过简单远程服务集提供给监控节点
mmm_control  通过命令行管理mmm_mond进程

mmm的优点
1.稳定和成熟的开源产品，经过时间考验
2.核心技术是mysql自己的技术，只是使用脚本程序来完成，所以在原理上比较容易理解，而且管理更智能化
3.安装简单，配置简单，使用简单
4.功能强大  HA 故障转移  tools套件  cluster模式可以一个monitor管理多个mmm组

缺点：
1.由于架构只有一个写入点，所以扩展性是有限的，但是对一般企业够用了。对于大应用可以多个mmm架构，使用mmm cluster来管理
2.对于读写分离和读负载均衡还是要程序开发或者使用其他工具完成
3.需要大量的perl库支持，安装比较耗时

monitor user       一个可以在mmm  monitor 机器上使用并且拥有replication client权限的mysql用户
agent user        一个可以在mmm agent机器上使用的并且拥有super ，replication client ， process权限的mysql用户
replication user 一个slaves主机上可以使用的并且有用replication slave权限的用户 
tools user   一个mmm tools主机可以使用的，并且有用super ， replication client ， reload 权限的mysql用户。
mysql-mmm是由perl编写的 所以对perl有依赖性  在监控机上 如果非root用户运行mmm-mond进程 需要安装Fping模块

在安装DBD：：mysql前，如果是自己编译的mysql  需要在/etc/ld。so。conf文件中加上mysql库所在的位置，然后运行ldconfig

mmm-tools介绍mysql-mmm附带的工具箱
mmm―clone  用来克隆一个mysql数据库到另外的机器，并且自动完成master-master或者master-slave架构
mmm-backup  用来备份数据库，备份使用了lvm的快照技术，所以支持热备，并且锁表时候时间相当短，支持3种拷贝scp，ssh-gz，rdiff（支持增量备份）
mmm-restore   还原数据到一个mysql数据库  并完成master-master或者master-slave 的环境搭建

mysql-mmm 的6种状态
1.online   正常状态 可以充当各种角色
2.admin―offline   手动下线状态
3.hard-offline  ping不通并且 mysql中断 会导致hard-offline状态
4.awaiting―recovery  如果能ping通 并且mysql连接状态正常则会变成为awaiting-recovery状态
5.replication―delay  复制延迟会导致 replication-delay
6.replication-fail    复制中断（sql-thread，io-thread）会导致replication-fail状态

从replication-delay或者replication-fail状态可以直接恢复到online状态，除非主机被设置为抖动
有两种情况可以从awaiting-recovery状态转变为online状态
1.故障时间少于60秒并且没有重启过
2.设置了auto-set-online 〉 0 （抖动状态除外）

MMM切换原理
1.获取同步的binlog和position
先获取new master的show slave status中的master-log-file和read-master-log-Pos
wait-log=master-log-file，wait-pos=read-master-log-pos 如果old master可以连接，在获取old master的show master status中的file和position。wait-log=file，wait-pos=Position 覆盖new master的slave信息，以old master为准
2.slave追赶old master的同步位置 select master_pos_wait('wait_log',wait_pos);
停止同步 stop slave；
3.设置new master信息 此时new master 已经对外提供写操作。
在main线程里new master 先接收到激活的消息，new master 转换（包含vip操作）完成后，然后由_distribute_roles将master 变动同步到slave上
在new master转换完成后 如果不能执行flush logs 更方便管理。
获取new master的binlog数据 show master status；
从配置文件/etc/mysql-mmm/mmm_common.conf读取同步账户，密码  replication_user，replication_password
设置新的同步位置，开启同步

注意问题：双主的binlog必须完全一致，否则切换会出问题，如果new master比slave的同步位置晚，会导致重复执行，只有row模式下才能保证数据一致性。

HA 三种工作方式   主从方式    双机双工方式   集群工作方式  
LB  有lvs  haproxy  nginx  varnish  dns