Mysql复制原理-[主从模式]--[主主模式]

####MySql 主从模式原理####

主从复制原理如下：slave（从服务器）master（主服务器）

【mysql主从是异步复制过程】

master开启bin-log功能，日志文件用于记录数据库的读写增删;

主从复制过程存在三个线程:[Master端的I/O线程]、[Slave的I/O线程]与[SQL线程].
Master端需要开启binlog日志，Slave端需要开启relaylog

【主从复制过程】

1、Slave端的I/O读取master.info文件，获取binlog文件名和位置点，然后向Master端的I/O线程请求，该binlog文件名和位置点的binlog信息。（master.info文件在配置主从复制时使用change master命令来指定生成）

2、Master端的I/O线程会根据Slave端的I/O线程请求的信息来读取Master的binlog日志信息与及读取到最新的binlog文件名和位置点一同返回给Slave的I/O线程。

3、Slave端的I/O线程会把获取到的binlog日志写入relaylog（中继日志）文件中，并且更新master.info文件信息。（把读取到Master最新的binlog日志文件名和位置点更新到master.info文件中，下一次当前位置去读取Master的binlog日志）

4、Slave端的SQL线程会定期读取relaylog，把二进制的日志解析成SQL语句，并执行这些SQL语句，同步数据到从库中。

注意：mysql主从复制要求主从两个数据库版本相同，或者从机比主机版本高；
准备两个mysql,一个做主,一个做从.防火墙,selinux都要关闭,保证可以ping通对方

【复制模式】

1.异步模式（mysql async-mode）

主节点不会主动push binlog到从节点，这样有可能导致fail over的情况下，也许从节点没有即时地将最新的binlog同步到本地。

2.半同步模式(mysql semi-sync)

主节点只需要接收到其中一台从节点的返回信息,就会commit；
否则需要等待直到超时时间然后切换成异步模式再提交；
这样做的目的可以使主从数据库的数据延迟缩小,可以提高数据安全性,确保了事务提交后,binlog至少传输到了一个从节点上,不能保证从节点将此事务更新到db中。
性能上会有一定的降低，响应时间会变长。

3.全同步模式

主节点和从节点全部执行了commit并确认才会向客户端返回成功。

4.  GTID复制模式

在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。
在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。
多线程复制（基于库），在MySQL 5.6以前的版本，slave的复制是单线程的。
一个事件一个事件的读取应用。而master是并发写入的，所以延时是避免不了的。
唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。
在MySQL 5.6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制。

###基于GTID复制实现的工作原理###

主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
从节点的I/O线程将变更的binlog，写入到本地的relay log中。
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。
如果有记录，说明该GTID的事务已经执行，从节点会忽略。
如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。
###复制方式
1、基于语句的复制在Master上执行的SQL语句，在Slave上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。一旦发现没法精确复制时，会自动选着基于行的复制
2、基于行的复制把改变的内容复制到Slave，而不是把命令在Slave上执行一遍。从MySQL5.0开始支持
3、混合类型的复制默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制
相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。

####MySql 主主模式原理####

主主复制的原理实际上是主从复制的原理，让两台服务器互为主从，就实现了主主复制
要实现主主复制，则需要两个数据库版本相同。