MYSQL的主从复制之旅(一)——戏说MySQL Statement-based 主从复制

标签: 专项测试 mysql | 发表时间:2013-01-11 12:52 | 作者:百度质量部
出处:http://qa.baidu.com/blog

我是一条数据更改操作,来自SQL家族。今天呀,我要来描述一段旅程,通过这段旅程,我才发现原来从主库(master)走到从库(slave)这么的不简单。
今天早上我从主库(master)确定要出发后,首先被要求到一个叫做二进制日志(binary log)的小册子中进行了登记,接着就和其他兄弟姐妹一起等待着被送往今天的目的地——从库(slave)。
在这里得要说明一下,并不是所有人都有资格到binary log登记,只有即将执行完毕并且改变了master数据的SQL语句,也就是说只有那些已经准备好出发前往slave的人才会被记录在binary log中。
在我登记完以后,master的业务人员(dump线程)就从binlog中读取我的信息,并发送给了slave的接送人员(I/O线程),通知他把我安全的接到slave上。I/O线程带我来到slave,让我在slave的登记手册——中继日志(relay log)再次登记,并且告诉我,他还需要去接我的同伴,让我等待配送人员(SQL线程)的进一步安排。到目前为止,我还只是从master的binary log中被复制到了slave 的relay log。
SQL线程姗姗来迟,“抱歉让你久等了,刚处理完你朋友的需求。我们这儿只有两位工作人员,一个负责配送,一个负责接待,只能一个一个串行处理,速度怎么也快不起来。”就这样,我由SQL线程带领着,在slave上重新执行了一遍,将对master的数据改变复制到了slave上,我的旅程也就此告一段落。

你一定很好奇,每天有那么多的SQL被写入到master上,master和slave的配送和接待人员是怎么在茫茫人海之中找到我的呢?
这得从我到binary log登记那里说起。Binary log并不是一个单独的文件,它更像一个图书馆,保存了一组登记了我们SQL信息的二进制日志文件(binary log file)和一个用来查找跟踪binary log file的索引,大家叫它binary log index。而我到slave上登记的中继日志(relay log)中除了包含二进制日志中的内容文件(relay log file)和索引文件(relay log index)以外,还有两个非常重要的文件:中继日志信息文件(relay-log.info)和master日志信息文件(master.info)。去master接谁,带领谁到slave上执行,就全靠他们提供的跟踪信息啦!
master.info文件其实就是slave和master沟通的纽带,它记录着slave和master建立主从复制时所有必需的信息,并且细心的把我们在master上的位置给记录下来。这样哪怕master和slave短时间失去联系了,slave的接送人员也知道下一个要到达slave的是谁。
relay-log.info文件应该算作是slave上接待人员SQL线程的工作笔记。每次带领一条SQL完成在slave的执行以后,SQL线程就会在这里记上一笔。这样当他休息后再恢复工作时就能准确的找到下一个要派送执行的SQL。

我曾经很担心会在去往slave的路上走丢,但是看了slave工作人员的工作制度以后就一点儿也不担心了。Slave上的I/O线程每接送一条SQL都需要做两件事情:第一件事情是把我们在relay log中记录的信息刷新到磁盘;另一件事情就是更新他的工作日志——master.info,并且确保更新在磁盘上保存下来。如果我在到达slave前走丢了,那master.info的最新记录会是排在我前面的一位兄弟,这样I/O线程在下一次接送的时候会重新接我到slave。但是特殊情况下,我可能会被复制两遍:假设我已经顺利到达slave,并且已经在relay log中登记,I/O线程正要更新master.info笔记时突然断电了,我的这次到访就没有被记录到master.info中。停电恢复后,I/O线程按照master.info中的记录获取接送信息,I/O线程会重复的把我从master带到slave上,从而导致relay log中有两条我的记录。但是不管怎样,重复总比走丢好,是吧?
出于这个考虑,SQL线程也采用同样的工作方式:在带领我执行完毕以后,再更新relay-log.info中的记录。在出现故障或是稍作休息后SQL线程会从relay-log.info的最后一个记录位置恢复执行。
这就是我从master到slave的全部见闻啦,如果你还有更多想要知道的细节,请回复本文,我会给你回信的O(∩_∩)O

相关 [mysql 复制 mysql] 推荐:

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主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.

MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践

- - CSDN博客推荐文章
接触php已快有3年了,一直想有所突破,最近看了下分布和数据库读写分离. 总算也小有成果.....前段时间发布了,用ngix实现分流. nginx 配置轮询分流-实现负载均衡【测试通过】. 今天就来分享一下,数据库读写分离并且同步. 我目前,介绍的是1台写入服务器,n台读取服务器..... 写这个的同时,我在思考一个问题,如果写入压力过大的时候,1台服务器写入不够用,那么写入该怎么办.

[MySQL FAQ]系列 — MySQL复制中slave延迟监控

- - MySQL中文网
在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟. 这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态:. 可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒.

异地多活:MySQL实时双向(多向)复制实践 - MySQL

- -
携程内部MySQL部署采用多机房部署,机房A部署一主一从,机房B部署一从,作为DR(Disaster Recovery)切换使用. 当前部署下,机房B部署的应用需要跨机房进行写操作;当机房A出现故障时,DBA需要手动对数据库进行DR切换. 为了做到真正的数据异地多活,实现MySQL同机房就近读写,机房故障时无需进行数据库DR操作,只进行流量切换,就需要引入数据实时双向(多向)复制组件.

MySQL 5.6 测试之 Replication(主从复制)

- - MySQL 中文网 -
MySQL 5.6测试之Replication. MySQL 5.6版本相比以前新增了很多令人激动的特性,简要介绍见: 转:MySQL 5.6新特性. 性能方面已经做过测试了,详细请见: MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试.

MySQL半同步复制(Semisynchronous Replication)

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

[玩转MySQL Replication] 复制拓扑

- - CSDN博客数据库推荐文章
     朴实简单的才是真、那些高端洋气的复制拓扑纯属自虐.      实施复制大概会有 4 个原则:.      ① 一个主库可以有多个备库.      ② 一个备库只能有一个主库.      ③ 每个备库 Server ID全局唯一.      ④ log_slave_updates 有薪火相传之效用.

MySQL主从复制与读写分离

- - 数据库 - ITeye博客
MySQL主从复制与读写分离. MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践. Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过. 但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面.