MySQL半同步复制(Semisynchronous Replication)

标签: MySQL | 发表时间:2012-08-06 12:52 | 作者:zhang
出处:http://www.blogread.cn/it/

标签:   半同步

MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:

1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。

2. 半同步与异步复制相比,进一步提高了数据完整性(不太理解为什么这么说),保证了事务成功提交后,有两份记录被记录下来,一份在主库上,另一份至少在一个从库上。

3. 半同步复制在平衡性能与数据可靠性方面,采用了network group commit的方式来复制binlog。半同步复制为了保证在主库上的每一次更新都能可靠的复制到从库上,当每次事务结束后,都需要等待从库的确认回执,这样即便有意外发生,从库也只是少了那一个事物,但是这样会产生频繁的roundtrip time,性能可想而知;而如果能增加每一次确认前被复制的事务个数,尽可能多的以一个batch的形式完成一次复制,这样效率会提高很多,但是随之带来的负面影响,就是故障发生后,从库丢失的就是一批事务。sysbench的压测结果会发现,性能并没有想象的落差很大,我测的结果几乎没什么变化。

4. 目前实现的所谓半同步复制,其实真正意义上不能叫作semi-synchronous replication,用Baron的话说应该叫作delayed-acknowledgment commits,也仍然属于asynchronous的概念;同时Baron也阐述了同步的概念:“In truly synchronous replication, when you commit a transaction, the commit does not complete until all replicas have also committed successfully.”

5. Baron的另一个观点:“ semi-synchronous replication actually forces the client to be synchronized, not the replicas.”其实,native replication与现有实现的semi-sync replication就其复制架构本身并没有特别的变化,两种模式下,复制都是发生在主库commit操作完成之后。

6. 不建议在高延时的网络环境下使用半同步复制功能。

以下是配置和监控半同步复制:

1. 半同步复制功能以plugin的方式接入MySQL,需要在主库与从库两端同时开启半同步的支持,具体配置如下:

On the master

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;

mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

mysql> SET GLOBAL rpl_semi_sync_master_timeout = 1000;  # 1 second

On the slave

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

mysql> START SLAVE;

NOTE: SLAVE端需要先开启半同步参数,然后启动从库复制,否则, Rpl_semi_sync_slave_status 的状态始终为: OFF

2. 通过以下参数可以判断半同步是否正常:

Rpl_semi_sync_master_status -- 判断主库当前模式为半同步还是异步复制

Rpl_semi_sync_master_clients -- 当前处于半同步状态的从库个数

Rpl_semi_sync_master_yes_tx,Rpl_semi_sync_master_no_tx -- 主库收到正常确认以及超时未成功确认的事务个数

Rpl_semi_sync_slave_status -- 从库半同步复制是否正常,当io_thread为NO时,状态为OFF

查看半同步相关参数及状态参数命令:

mysql> SHOW VARIABLES LIKE ‘rpl_semi_sync%’;

mysql> SHOW STATUS LIKE ‘Rpl_semi_sync%’;

-TAKE AWAY-

半同步复制使MHA更加完美

在之前的文章中曾和大家分享过 MHA这种高可用的主从自动的failover方案,而这里说的半同步复制对于MHA是一个很有利的支持。

半同步可以最大程度的保障主库执行过的语句被成功复制到从库relay log中;而当主库发生故障时,使从库的状态更接近主库,保持最小的数据差异。基于半同步这个特点,可以将其与MHA一起使用,当主库故障,故障自动切换被触发,在这个过程中MHA需要比较主库与从库日志差异,由于半同步的特点,差异日志会尽可能的少,那么MHA在进行判断比较、差异生成、拷贝直至最后的差异应用,这一系列的时间消耗都会得到缩减,这样MHA的切换时间就相应减少,数据库故障可以快速恢复。

正常情况下,主库写入binlog日志的pos位置与从库读到的Read_Master_Log_Pos位置应该保持一致;测试中发现,当主库被意外关掉,仍存在少量的跟新语句没有被同步过去,这一点在手册里面有提及(If the master commits but a crash occurs while the master is waiting for acknowledgment from a slave, it is possible that the transaction may not have reached any slave.)

您可能还对下面的文章感兴趣:

  1. MySQL半同步存在的问题 [2010-03-03 23:57:38]


相关 [mysql 同步 复制] 推荐:

MySQL半同步复制(Semisynchronous Replication)

- - IT技术博客大学习
MySQL5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:. 半同步启动需要主从两端都需要加载安装各自对应的semi模块,从库端支持半同步功能的数量至少一台;主库端当一个事务成功提交后,并不及时反馈给前端用户,该线程会被临时block,等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认),这时主库线程才返回给当前session告知操作完成,半同步复制并不关心在从库一端该事务是否都被执行并被提交完成.

MySQL中的半同步复制

- - 学习日志
MySQL当前存在的三种复制模式有:异步模式、半同步模式和组复制模式. 注意:MySQL复制模式没有“同步复制”这一项的,文章中只是为了读者方便理解半同步复制的概念才介绍了同步复制概念 https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html.

MySQL的主从复制、半同步复制、主主复制详解

- - 学习笔记
复制其最终目的是让一台服务器的数据和另外的服务器的数据保持同步,已达到数据冗余或者服务的负载均衡. 一台主服务器可以连接多台从服务器,并且从服务器也可以反过来作为主服务器. 主从服务器可以位于不同的网络拓扑中,由于mysql的强大复制功能,其复制目标可以是所有的数据库,也可以是某些数据库,甚至是某个数据库中的某些表进行复制.

MySQL 同步复制及高可用方案总结

- - SegmentFault 最新的文章
mysql作为应用程序的数据存储服务,要实现mysql数据库的高可用. 必然要使用的技术就是数据库的复制,如果主节点出现故障可以手动的切换应用到从节点,这点相信运维同学都是知道,并且可以实现的. 但是这种情况只是手动的切换,对可用性有要求的业务需要分别实现主库和从库的高可用,保障在数据库出现down机的情况下,可以自动实现数据库的故障转移,保障应用的可用性和用户体验.

MySQL 数据库双向同步复制 - mindwind - 博客园

- -
MySQL 复制问题的最后一篇,关于双向同步复制架构设计的一些设计要点与制约. 数据库的双主双写并双向同步场景,主要考虑数据完整性、一致性和避免冲突. 对于同一个库,同一张表,同一个记录中的同一字段的两地变更,会引发数据一致性判断冲突,尽可能通过业务场景设计规避. 双主双写并同步复制可能引发主键冲突,需避免使用数据库自增类主键方案.

JAVA通过Gearman实现MySQL到Redis的数据同步(异步复制)

- - 企业架构 - ITeye博客
MySQL到Redis数据复制方案. 无论MySQL还是Redis,自身都带有数据同步的机制,像比较常用的 MySQL的Master/Slave模式 ,就是由Slave端分析Master的binlog来实现的,这样的数据复制其实还是一个异步过程,只不过当服务器都在同一内网时,异步的延迟几乎可以忽略.

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

MySQL 双活同步复制的四种方案_咸鱼的梦想专栏-CSDN博客_mysql双机同步复制

- -
对于数据实时同步,其核心是需要基于日志来实现,是可以实现准实时的数据同步,基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束. 基于MySQL原生复制主主同步方案  . 这是常见的方案,一般来说,中小型规模的时候,采用这种架构是最省事的. 两个节点可以采用简单的双主模式,并且使用专线连接,在master_A节点发生故障后,应用连接快速切换到master_B节点,反之也亦然.

同步mysql数据到hive

- - ITeye博客
地址为:http://archive.cloudera.com/cdh/3/下载相应版本,如sqoop-1.2.0-CDH3B4.tar.gz. 地址为:http://archive.cloudera.com/cdh/3/,版本可以为hadoop-0.20.2-CDH3B4.tar.gz. 3.解压 sqoop-1.2.0-CDH3B4.tar.gz ,hadoop-0.20.2-CDH3B4.tar.gz 到某目录如/home/hadoop/,解压后的目录为.