关于mysql主从复制的概述与分类

一、概述：

按照MySQL的同步复制特点，大体上可以分为三种类别：

1、异步复制；

2、半同步复制；

3、完全同步的复制；

--------------------------------------------------------------------------------------------------

（一）、异步复制：

1、概念

mysql的异步复制在业界中的叫法有很多，比如：AB复制、主从同步、mysql replication等等。说白了就是master和slave结构。在mysql5.6版本以后又进一步的细分成：传统的复制方法和全新的复制方法。

2、5.6以后的mysql主从复制的分类：

2.1、传统复制方法是按照binlog的三种日志格式进行划分的：

基于语句的复制，即statement模式。

基于行的复制，即row模式。

基于混合的复制，即mixed

2.2、全新的复制方法：基于GTID的复制。

3、关于master和slave的关系：

不是主备模式，而是数据镜像。

特别在GTID环境下，不能在slave上做dml操作。

slave拿到master上的日志，在slave上以串行的方式进行重放。

I/O现成是一个（串行），sql线程和DB一样多。

结构可以分为：一主一从、一主多从、双主多从。

4、master和slave的作用：

实现读写分离。

从库可以用作故障转移。(master挂了，vip切换到slave端)

用从库做备份，或者特殊统计。（一条大sql跑一下需要很久，可以单独找个slave单独来跑）

用于主库升级.（M端5.5，S端5.6，S端转换成M，将原M端升级成5.6然后挂载到5.6的M端）

5、master和slave的工作原理：

如图1：

master更新数据，写binlog；

slave在master端注册一个i/o thread进程，截取binlog日志的变更。

i/o thread接入日志变更之后写入到本地的relay log里。

然后通过sql thread到relay log里进行解析复制到slave端。

在解析过程中会判断是否有主键，如果没有在判断是否有二级索引，如果没有就进行全表扫描。

6、判断主从同步的地址段参数：

判断日志参数：

master_log_file:

relay_master_log_file:

判断地址参数：

read_master_log_pos:

exec_master_log_pos:

-------------------------------------------------------------------------------

（二）、半同步复制：

1、概念与作用

在默认情况下，mysql复制功能是异步的，异步复制可以提供最佳性能。当主库把binlog日志发送给从库，这一动作就结束了，并不会验证从库是否接收到，或者接受完毕。这不仅带来了很高的风险，同时也意味着当master或者slave发证故障时，有可能slave端没有接收到主机发送过来的binlog日志，最终导致master/slave的数据不一致，甚至在恢复时造成数据丢失。

为了解决上述问题，mysql5.5引入了一种半同步复制模式，该模式可以确保slave端接收完master端发送的binlog日志文件写入自己的中继日志relay log里，然后会给master端一个ack。告诉对方已经接收完毕。这时master的线程才返回给当前session告知操作完成。

2、注意事项：

a、当出现超时的情况时，源主服务器会暂时切换到异步复制模式，直到至少有一台设置为半同步复制模式的slave端及时收到信息为止。

b、半同步复制模式必须在主服务器和从服务器端同时启用，否则主服务器默认使用异步复制模式。

c、slave在接收到二进制日志后会通过i/o_thread给master端一个ack。但是他并不会管relay-log中的sql_thread进程是否执行完。

3、特点：

半同步复制的目的是保证主从数据的一致性，等待返回的时间长短决定了数据库的更新速度。

优点：保证主从数据一致性。

缺点：更新、插入、删除的速度要比传统的异步复制稍慢一些，因为多了一个ACK的步骤。

　　  尤其是在网络受到波动的情况下，如丢包、ping延时，半同步复制和异步复制就会切来切去，也会导致主库的更新、插入、删除操作受到影响。

4、原理图：

-------------------------------------------------------------------------------

（三）、完全同步复制：

由于半同步的这种弊端，在生产环境里一般用到的很少，但是为了保证节点之间的数据一致性。可以采用完全同步的方式-----PXC架构。

1、概念：

PXC在数据commit的时候需像其他主机成全进行确认，当有多个主机成员返回ACK时才可以commit数据。一般主句数量与返回ACK的数量如下：

5个节点，有三个节点回复。

3个节点，有一个节点回复。

2、特点：

对于数据库的数据一致性很高的场景。

PXC解决的是数据一致性的问题，而不是存储结构的问题。

几个节点可以跑同一个业务结构。同时下面也可以挂在slave端。

有些类似于oracle的rac功能，实现并发负载。只是没有共享存储，一般oracle转mysql用途比较多些。

3、工作原理：

a、在PXC集群中第一个节点会以mysql --wsrep_cluster_address=gcomm://192.168.100.200这种方式启动。其他节点会以/etc/init.d/mysql start的方式启动。

b、当第二个节点加入PXC集群后，会连接到node1上去请求数据，并查看GTID的节点。如果所有GTID的节点与新加入的节点不一致，就会通过全量（SST）的方式去同步所有节点的数据。此时提供node1数据提供住就被称为donor。

c、donor角色在同步数据前的时候会做一次SST的备份，此时备份过程中donor节点性能会变得非常差。因此，在跑PXC的服务器不要使用多实例。如果集群是能够在控制范围内的化，可以指定一个donor的主机进行数据同步，当节点传输完后直接删除参数即可。

参数如下：

vi /etc/my.cnf

wsrep_sst_donor=节点名