FAQ系列 | 如何保证主从复制数据一致性

导读

MySQL主从复制环境中,如何才能保证主从数据的一致性呢?

关于主从复制

现在常用的MySQL高可用方案,十有八九是基于 MySQL的主从复制(replication)来设计的,包括常规的一主一从、双主模式,或者半同步复制(semi-sync replication)。

我们常常把MySQL replication说成是MySQL同步(sync),但事实上这个过程是异步(async)的。大概过程是这样的:

  1. 在master上提交事务后,并且写入binlog,返回事务成功标记;
  2. 将binlog发送到slave,转储成relay log;
  3. 在slave上再将relay log读取出来应用。

步骤1和步骤3之间是异步进行的,无需等待确认各自的状态,所以说MySQL replication是异步的。

MySQL semi-sync replication在之前的基础上做了加强完善,整个流程变成了下面这样:

  1. 首先,master和至少一个slave都要启用semi-sync replication模式;
  2. 某个slave连接到master时,会主动告知当前自己是否处于semi-sync模式;
  3. 在master上提交事务后,写入binlog后,还需要通知至少一个slave收到该事务,等待写入relay log并成功刷新到磁盘后,向master发送“slave节点已完成该事务”确认通知;
  4. master收到上述通知后,才可以真正完成该事务提交,返回事务成功标记;
  5. 在上述步骤中,当slave向master发送通知时间超过rpl_semi_sync_master_timeout设定值时,主从关系会从semi-sync模式自动调整成为传统的异步复制模式。

半同步复制看起来很美好有木有呢,但如果网络质量不高,是不是出现抖动,触发上述第5条的情况,会从半同步复制降级为普通复制;此外,采用半同步复制,会导致master上的tps性能下降非常严重,最严重的情况下可能会损失50%以上。

这样来看,除非需要非常严格保证数据一致性等迫不得已的场景,就不太建议使用半同步复制了。当然了,事实上我们也可以通过加强程序端的逻辑控制,来避免主从数据不一致时发生逻辑错误,比如说如果在从上读取到的数据和主不一致的话,那么就触发主从间的一次数据修复工作。或者,我们也可以用 pt-table-checksum & pt-table-sync 两个工具来校验并修复数据,只要运行频率适当,是可行的。

真想要提高多节点间的数据一致性,可以考虑采用PXC方案。现在已知用PXC规模较大的有qunar、sohu,如果团队里初期没有人能比较专注PXC的话,还是要谨慎些,毕竟和传统的主从复制差异很大,出现问题时需要花费更多精力去排查解决。

如何保证主从复制数据一致性

上面说完了异步复制、半同步复制、PXC,我们回到主题:在常规的主从复制场景里,如何能保证主从数据的一致性,不要出现数据丢失等问题呢?

在MySQL中,一次事务提交后,需要写undo、写redo、写binlog,写数据文件等等。在这个过程中,可能在某个步骤发生crash,就有可能导致主从数据的不一致。为了避免这种情况,我们需要调整主从上面相关选项配置,确保即便发生crash了,也不能发生主从复制的数据丢失。

1. 在master上修改配置

innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

上述两个选项的作用是:保证每次事务提交后,都能实时刷新到磁盘中,尤其是确保每次事务对应的binlog都能及时刷新到磁盘中,只要有了binlog,InnoDB就有办法做数据恢复,不至于导致主从复制的数据丢失。

2. 在slave上修改配置

master_info_repository = "TABLE"
relay_log_info_repository = "TABLE"
relay_log_recovery = 1

上述前两个选项的作用是:确保在slave上和复制相关的元数据表也采用InnoDB引擎,受到InnoDB事务安全的保护,而后一个选项的作用是开启relay log自动修复机制,发生crash时,会自动判断哪些relay log需要重新从master上抓取回来再次应用,以此避免部分数据丢失的可能性。

通过上面几个选项的调整,就可以确保主从复制数据不会发生丢失了。但是,这并不能保证主从数据的绝对一致性,因为,有可能设置了ignore\do\rewrite等replication规则,或者某些SQL本身存在不确定因素,或者人为在slave上修改数据,最终导致主从数据不一致。这种情况下,可以采用pt-table-checksum 和 pt-table-sync 工具来进行数据的校验和修复。

文章转自老叶茶馆公众号,原文链接:https://mp.weixin.qq.com/s/0LkpKDbosYZ3gWPp4AZFqg

时间: 2024-08-31 22:35:28

FAQ系列 | 如何保证主从复制数据一致性的相关文章

FAQ系列 | 列类型被自动修改导致复制失败

0.导读 在复制环境中,有个表的列类型总是被修改,导致复制进程报错停止 1.问题描述 问题发生在朋友的数据库上,做了主从复制,其中某表有一列类型是INT,但是该表上的INSERT事件在BINLOG中却总被记录为MEDIUMINT类型,导致这个事件在SLAVE上执行失败. 相关现场信息见下: MySQL版本:官方5.5.版本. 表DDL定义: CREATE TABLE `t` (   `userid` int(10) unsigned NOT NULL DEFAULT 0, 这个表上的INSERT

FAQ系列 | 写新数据时某列值总是被自动修改

0.导读 往表里写入新数据时,却一直报告主键冲突,某列值一直被重置为一个固定值,疑似被黑,啥情况? 1.问题描述 某朋友的线上数据库,怀疑被侵入了.具体表象是:INSERT的时候,某列值总被自动改成一个固定值. 他们先自查了 TRIGGER 和 EVENT,都是空的,确定不是因为这两种原因引起,实在想不出是哪里被动了手脚. 问题的现象: MariaDB [information_schema]> use bbs9; Reading table information for completion

FAQ系列 | MySQL索引之主键索引

导读 在MySQL里,主键索引和辅助索引分别是什么意思,有什么区别? 上次的分享我们介绍了聚集索引和非聚集索引的区别,本次我们继续介绍主键索引和辅助索引的区别. 1.主键索引 主键索引,简称主键,原文是PRIMARY KEY,由一个或多个列组成,用于唯一性标识数据表中的某一条记录.一个表可以没有主键,但最多只能有一个主键,并且主键值不能包含NULL. 在MySQL中,InnoDB数据表的主键设计我们通常遵循几个原则: 采用一个没有业务用途的自增属性列作为主键: 主键字段值总是不更新,只有新增或者

FAQ系列 | EXPLAIN执行计划中要重点关注哪些要素

导读 EXPLAIN的结果中,有哪些关键信息值得注意呢? MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息. 总的来说,我们只需要关注结果中的几列: 列名 备注 type 本次查询表联接类型,从这里可以看到本次查询大概的效率 key 最终选择的索引,如果没有索引的话,本次查询效率通常很差 key_len 本次查询用于结果过滤的索引实际长度,参见另一篇分享(FAQ系列-解读EXPLAIN执行计划中的key_len) rows 预计需要扫描的记

【转】保证分布式系统数据一致性的6种方案

问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A.B.C,需要满足要么同时成功:要么同时失败.A.B.C 可能是多个不同部门开发.部署在不同服务器上的远程服务. 在分布式系统来说,如果不想牺牲一致性,CAP 理论告诉我们只能放弃可用性,这显然不能接受.为了便于讨论问题,先简单介绍下数据一致性的基础理论. 强一致   当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值.这

分布式之《保证分布式系统数据一致性的6种解决方案》

原文:http://weibo.com/ttarticle/p/show?id=2309403965965003062676   编者按:本文由「高可用架构后花园」群讨论整理而成. 有人的地方,就有江湖 有江湖的地方,就有纷争 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性?  具体业务场景如下,比如一个业务操作,如果同时调用服务 A.B.C,需要满足要么同时成功:要么同时失败.A.B.C 可能是多个不同部门开发.部署在不同服务器上的远程服务. 在分

MySQL架构优化实战系列2:主从复制同步与查询性能调优

一.主从复制同步部署   1.概念 主从复制:2台以上mysql服务器, 做负载均衡, 主服务器负责增删改 , 从服务器负责查询 同步原理:mysql开启bin-log日志,主服务器所有的增删改操作会记录到bin-log日志:然后主服务器把bin-log日志发送 给 从服务器 , 从服务器重放bin-log日志 确保数据同步 2.开启bin-log日志 配置 my.cnf 文件 并重启 mysql [root@localhost etc]# vim /etc/my.cnf     [root@l

FAQ系列 | lower_case_table_names迷思

导读 关于 lower_case_table_names 选项的设置的建议是怎样的呢? 问题由来 我个人认为,纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来,在这两个数据库系统中,都无需关心数据表的大小写.而在MySQL中,默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的),除非在windows系统下(windows系统是不区分大小写的). 老叶的建议 我在公司制定的规范是要求默认设置 lower_case_table_names=0 的,

FAQ系列 | MySQL索引之聚集索引

导读 在MySQL里,聚集索引和非聚集索引分别是什么意思,有什么区别? 在MySQL中,InnoDB引擎表是(聚集)索引组织表(clustered index organize table),而MyISAM引擎表则是堆组织表(heap organize table). 也有人把聚集索引称为聚簇索引. 当然了,聚集索引的概念不是MySQL里特有的,其他数据库系统也同样有. 简言之,聚集索引是一种索引组织形式,索引的键值逻辑顺序决定了表数据行的物理存储顺序,而非聚集索引则就是普通索引了,仅仅只是对数