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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

developerguy 2016-03-22 20:51:00 浏览1818
展开阅读全文

一、概述:

按照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=节点名

http://www.cnblogs.com/abobo/p/4239220.html

 

网友评论

登录后评论
0/500
评论
developerguy
+ 关注