MySQL · 源码分析 · MySQL BINLOG半同步复制数据安全性分析

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 半同步复制(semisynchronous replication)MySQL使用广泛的数据复制方案,相比于MySQL内置的异步复制它保证了数据的安 全,本文从主机在Server层提交事务开始一直到主机确认收到备机回复进行一步步解析,来看MySQL的半同步复制是怎么保证数 据安全的。本文基于MySQL 5.6源码,为了简化本文只分析DML的核心的事务处理过程,并假定事务只涉及innodb存储引擎。

半同步复制(semisynchronous replication)MySQL使用广泛的数据复制方案,相比于MySQL内置的异步复制它保证了数据的安 全,本文从主机在Server层提交事务开始一直到主机确认收到备机回复进行一步步解析,来看MySQL的半同步复制是怎么保证数 据安全的。本文基于MySQL 5.6源码,为了简化本文只分析DML的核心的事务处理过程,并假定事务只涉及innodb存储引擎。

MySQL的事务提交流程

在MySQL中事务的提交Server层最后会调用函数ha_commit_trans(),该函数负责处理binlog层和存储引擎层的提交,它先调用 tc_log->prepare()在引擎层生成一个XA事务,然后再调用tc_log->commit()来提交事务,这里的tc_log是在mysqld启动时就生 成的一个MYSQL_BIN_LOG类的对象。简化后代码片断类似:

int ha_commit_trans(THD *thd, bool all, bool ignore_global_read_lock)
{
  //...
  error= tc_log->prepare(thd, all);

  if (error || (error= tc_log->commit(thd, all)))
  {
    ha_rollback_trans(thd, all);
    error= 1;
    goto end;
  }
  //...
}

MYSQL_BIN_LOG::prepare()函数调用ha_prepare_low(),该函数再调用存储引擎层(这里指innodb)的prepare在存储层生成XA 事务。MYSQL_BIN_LOG::commit()先在binlog层加入一个Xid_log_event类型的日志作为XA事务在binlog层提交的标志,注意这 里并没有调用操作系统的fsync。该函数最后调用会调用MYSQL_BIN_LOG::ordered_commit(),做binlog文件的磁盘fsync和提交 到存储引擎。

MYSQL_BIN_LOG::ordered_commit()是比较重要的函数,该函数的处理步骤如下:

  1. 将binlog数据刷写到文件中
  2. 将当前的binlog文件名和位点注册到semisync模块中,以便后面等待备机的回复
  3. 调用函数MYSQL_BIN_LOG::sync_binlog_file()将binlog文件sync到磁盘,到这里事务将不能回滚,即使mysqld崩溃了事务 也会最终提交。
  4. 调用MYSQL_BIN_LOG::update_binlog_end_pos()更新binlog最后sync的位点信息,这时为备库复制服务的binlog dump线程 才可以读到这个事务,可参考Log_event::read_log_event()
  5. 如果semisync模块配置了rpl_semi_sync_master_wait_point为 after_sync,那么当前Session将在这里等待备机回复再继 续。
  6. ordered_commit()接下来会最终调用到 ha_commit_low()在存储引擎层提交
  7. 如果rpl_semi_sync_master_wait_point参数为after_commit,当前Session就会在ordered_commit()接下来调用的 MYSQL_BIN_LOG::finish_commit()函数里等待备机的回复,

以上可以看出after_sync和after_commit的主要区别是,当备机确认收到日志时,主机上的该事务是否对其他session可见, after_sync是不可见(因为在存储引擎层还没有提交),after_commit是可见。after_commit可能导致在主机上被其他事务看 见了的事务在切换到备机后又消失了,所以MySQL 5.7默认使用after_sync。

MySQL的事务恢复流程

mysqld崩溃之后的事务恢复最终是通过MYSQL_BIN_LOG::recover()进行的,调用栈: mysqld_main() -> init_server_components() -> MYSQL_BIN_LOG::open() -> MYSQL_BIN_LOG::open_binlog() -> MYSQL_BIN_LOG::recover()。open_binlog()函数通过binlog文件头上的标志可以知道该文件在mysqld退出时没有正常关闭,然 后就调用recover()函数进行恢复。

MYSQL_BIN_LOG::recover()首先扫描binlog日志扫出在binlog里已经提交的事务加到一个commitlist里,然后调用 ha_recover()函数,该函数先调用innodb层的相关函数扫描出在innodb层已经prepare的事务,然后将在commitlist里的事务全 部提交。

从以上MySQL事务提交和恢复流程可以看出,在最终备机提交事务,必然在主机上是提交的,也就是主机的事务必然比备机更全。

主机和备机同步的处理流程

前文已经提到在MYSQL_BIN_LOG::ordered_commit()函数中,用户session会将要等待备机回复的事务对应的binlog文件名和位 点注册到semisync模块中,然后在向备机发送binlog的主函数里mysql_binlog_send()中,将这些事务对应的binlog event数据 包加上要求备机回复的标志,见函数ReplSemiSyncMaster::updateSyncHeader()。主机在mysqld启动时就启动了一个 ack_receiver线程,每次有新的备机连接上来,就把对应的服务线程注册到ack_receiver中,见函数 ReplSemiSyncMaster::dump_start(),ack_receiver负责接收所有备机的回复。备机在handle_slave_io()函数中读到一个 event的数据包就会检查是否有要求回复的标志,如果有则在将binlog刷到本地磁盘后向主机发送回复报文,回复的报文的内容 包含收到的binlog文件名和位点。流程大致如下:

while (!io_slave_killed(thd,mi))
{
  // ...
  event_len= read_event(mysql, mi, &suppress_warnings);
  mi->repl_semisync_slave.slaveReadSyncHeader((const char*)mysql->net.read_pos + 1,
					      event_len, &(mi->semi_ack), &event_buf,
					      &event_len);
  // ...
  if (queue_event(mi, event_buf, event_len))
    {
      mi->report(ERROR_LEVEL, ER_SLAVE_RELAY_LOG_WRITE_FAILURE,
		 ER(ER_SLAVE_RELAY_LOG_WRITE_FAILURE),
		 "could not queue event from master");
      goto err;
    }
  // ...
  if((mi->semi_ack & SEMI_SYNC_NEED_ACK) &&
     mi->repl_semisync_slave.slaveReply(mi))
    {
      mi->report(ERROR_LEVEL, ER_SLAVE_FATAL_ERROR,
		 ER(ER_SLAVE_FATAL_ERROR),
		 "Failed to call 'slaveReply'");
      goto err;
    }
  // ...
 }

ack_receiver线程的主线程函数是Ack_receiver::run(),该函数调用poll()监听在所有已注册的slave服务线程的socket上, 接听slave的回复报文,当接收到一个回复报文后,ack_receiver会记下当前的回复报文中的binlog文件名和位点,并在自己的 注册列表中删除在这个位点之前的事务,然后通过cond_broadcast()唤醒等待备机回复的用户session线程,这些线程通过比较 自己的等待位点和ack_receiver记下的回复报文位点决定是否结束等待。

总结

通过以上分析可以看出在同步复制的模式上,MySQL通过非常严格的流程保证了用户Session执行完事务返回给客户端后,该事 务也必然已同步到了备机的磁盘上。同时保证了出现在备机的事务必然在主机上已经是安全提交了的,也就是在任何时刻主机 上的事务一定是大于等于备机的。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
9天前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
6天前
|
SQL 监控 关系型数据库
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法:异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构,但存在数据丢失风险;半同步复制确保日志复制到从库后再提交事务,提高了数据安全性;GTID复制简化了配置过程,增强了复制的可靠性和管理性;并行复制通过多线程技术降低主从同步延迟,保证数据一致性。此外,还讨论了如何使用工具监控主从延迟及应对策略,如强制读主库以确保即时读取最新数据。
MySQL原理简介—12.MySQL主从同步
|
2月前
|
监控 关系型数据库 MySQL
Flink CDC MySQL同步MySQL错误记录
在使用Flink CDC同步MySQL数据时,常见的错误包括连接错误、权限错误、表结构变化、数据类型不匹配、主键冲突和
181 17
|
2月前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
115 2
|
2月前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
2月前
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
|
5月前
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
997 4
|
6月前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
738 2
|
6月前
|
SQL 关系型数据库 MySQL
【MySQL】根据binlog日志获取回滚sql的一个开发思路
【MySQL】根据binlog日志获取回滚sql的一个开发思路
|
3月前
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的binlog日志文件
MySQL的binlog日志记录了所有对数据库的更改操作(不包括SELECT和SHOW),主要用于主从复制和数据恢复。binlog有三种模式,可通过设置binlog_format参数选择。示例展示了如何启用binlog、设置格式、查看日志文件及记录的信息。
356 6

相关产品

  • 云数据库 RDS MySQL 版