MySQL Replication 线程
- - CSDN博客推荐文章Replication 线程. Mysql 的Replication 是一个异步的复制过程，从一个Mysql instace（我们称之为Master）复制到另一个Mysql instance（我们称之Slave）. 在Master 与Slave 之间的实现整个复制过程主. 要由三个线程来完成，其中两个线程（Sql 线程和IO 线程）在Slave 端，另外一个线程（IO 线程）在Master 端.
MySQL Replication 线程
标签：
mysql
replication
线程
| 发表时间：2012-08-10 19:07 | 作者：bengda
出处：http://blog.csdn.net
Replication 线程
Mysql 的Replication 是一个异步的复制过程，从一个Mysql instace（我们称之为Master）复制到另一个Mysql instance（我们称之Slave）。在Master 与Slave 之间的实现整个复制过程主
要由三个线程来完成，其中两个线程（Sql 线程和IO 线程）在Slave 端，另外一个线程（IO 线程）在Master 端。
要实现MySQL 的Replication ，首先必须打开Master 端的Binary Log（mysqlbin.xxxxxx）功能，否则无法实现。因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作
MySQL 复制的基本过程如下：
1. Slave 上面的IO 线程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2. Master 接收到来自Slave 的IO 线程的请求后，通过负责复制的IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave 端的IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在Master 端的Binary Log文件的名称以及在Binary Log 中的位置；
3. Slave 的IO 线程接收到信息后，将接收到的日志内容依次写入到Slave 端的Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master 端的binlog的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”
4. Slave 的SQL 线程检测到Relay Log 中新增加了内容后，会马上解析该Log 文件中的内容成为在Master 端真实执行时候的那些可执行的Query 语句，并在自身执行这些Query。这样，实际上就是在Master 端和Slave 端执行了同样的Query，所以两端的数据是完全一样的。
.png)
.png)
.png)
.png)
MySQL Replication 环境的搭建实现比较简单，总的来说其实就是四步，
Mysql 的Replication 是一个异步的复制过程，从一个Mysql instace（我们称之为Master）复制到另一个Mysql instance（我们称之Slave）。在Master 与Slave 之间的实现整个复制过程主
要由三个线程来完成，其中两个线程（Sql 线程和IO 线程）在Slave 端，另外一个线程（IO 线程）在Master 端。
要实现MySQL 的Replication ，首先必须打开Master 端的Binary Log（mysqlbin.xxxxxx）功能，否则无法实现。因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作
MySQL 复制的基本过程如下：
1. Slave 上面的IO 线程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2. Master 接收到来自Slave 的IO 线程的请求后，通过负责复制的IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave 端的IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在Master 端的Binary Log文件的名称以及在Binary Log 中的位置；
3. Slave 的IO 线程接收到信息后，将接收到的日志内容依次写入到Slave 端的Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master 端的binlog的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”
4. Slave 的SQL 线程检测到Relay Log 中新增加了内容后，会马上解析该Log 文件中的内容成为在Master 端真实执行时候的那些可执行的Query 语句，并在自身执行这些Query。这样，实际上就是在Master 端和Slave 端执行了同样的Query，所以两端的数据是完全一样的。
复制实现级别
Row Level
Statement Level
Row Level
Statement Level
1.常规复制架构(Master - Slaves)
2.Dual Master 复制架构(Master - Master)
可能有些读者朋友会有一个担心，这样搭建复制环境之后，难道不会造成两台MySQL 之间的循环复制么？实际上MySQL 自己早就想到了这一点，所以在MySQL 的Binary Log 中记录了当前MySQL 的server-id，而且这个参数也是我们搭建MySQL Replication 的时候必须明确指定，而且Master
和Slave 的server-id 参数值比需要不一致才能使MySQLReplication 搭建成功。一旦有了server-id 的值之后，MySQL 就很容易判断某个变更是从哪一个MySQL Server 最初产生的，所以就很容易避免出现循环复制的情况。而且，如果我们不打开记录Slave 的Binary Log 的选项（--log-slave-update）的时候，MySQL 根本就不会记录复制过程中的变更到Binary Log 中，就更不用担心可能会出现循环复制的情形了。
3.级联复制架构(Master - Slaves - Slaves ...)
4.Dual Master 与级联复制结合架构(Master - Master - Slaves)
MySQL Replication 环境的搭建实现比较简单，总的来说其实就是四步，
第一步是做好Master 端的准备工作。
1.MySQL 记录Binary Log 的选项打开；
2.GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.2'；
2.GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.2'；
第二步是取得Master 端数据的“快照”备份。
测试dump example 数据库下的group_message 表：
mysqldump --master-data -usky -p example group_message > group_message.sql
mysqldump --master-data -usky -p example group_message > group_message.sql
第三步则是在Slave 端恢复Master 的备份“快照”。
第四步就是在Slave 端设置Master 相关配置，然后启动复制
CHANGE MASTER TO 命令总共需要设置5 项内容，分别为：
MASTER_HOST：Master 的主机名（或者IP 地址）；
MASTER_USER：Slave 连接Master 的用户名，实际上就是之前所创建的repl 用户；
MASTER_PASSWORD：Slave 连接Master 的用户的密码；
MASTER_LOG_FILE：开始复制的日志文件名称；
MASTER_LOG_POS：开始复制的日志文件的位置，也就是在之前介绍备份集过程中一致提到的Log Position。
MASTER_HOST：Master 的主机名（或者IP 地址）；
MASTER_USER：Slave 连接Master 的用户名，实际上就是之前所创建的repl 用户；
MASTER_PASSWORD：Slave 连接Master 的用户的密码；
MASTER_LOG_FILE：开始复制的日志文件名称；
MASTER_LOG_POS：开始复制的日志文件的位置，也就是在之前介绍备份集过程中一致提到的Log Position。
作者：bengda 发表于2012-8-10 19:07:05 原文链接
阅读：0 评论：0 查看评论
相关 [mysql replication 线程] 推荐：
MySQL 平行執行的 Replication…
- - Gea-Suan Lin's BLOG「 MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication. 在文章裡提到，在 5.6.3 之前的版本，MySQL replication 都是 single-threaded，所以當 master 可以充分發揮多 CPU 能力時，slave 仍然要一個更新跑完才會跑下一個更新.
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 有薪火相传之效用.
relay fetch 解决mysql replication 主从延迟
- - CSDN博客推荐文章 mysql replication 中主从延迟是一个比较常见的问题，请看前期一篇博文： 怎样解决MySQL数据库主从复制延迟的问题. 根据目前有些公司使用的方案，最近测试了两个，其中之一是阿里的relay fetch ，业绩说法数据预热，当然也有其他开源类似开源工具，目前诸如 mk-slave-prefetch及 replication-prefetch等，感兴趣可以去看看.
MySQL Replication 常用SQL、应用、文件、流程、模式
- - CSDN博客数据库推荐文章无聊时写的，算科普吧，毕竟内置的Replication是MySQL的骄傲. 列出当前主库二进制日志状态. 列出连接到主库的备库信息. 列出二进制日志中的事件. 置空二进制日志索引文件，并创建一个新的二进制日志. 删除主库的二进制日志. ① 目标日志确认如下：.
MySQL Master-Slaver Replication 讓資料庫資料有備援
- - SSORC.tw重新複習一下 資料庫同步 – MySQL + replication. Master / Slaver 架構就是要讓 MySQL 資料庫系統有著備援的保障. 基本運作方式就是，MySQL Master 這台上只要有新增刪除修改，就會記錄在 binlog 檔裡，這時 Slaver 就可以透過 Master 授權的帳號去同步資料 ( Replication )，這是單向的.
fred: MongoDB Replication 簡記
- - Planet DebianTW就在幾天前，MongoDB 邁入了 2.2.0 的穩定版本. 我們若回頭來看，MongoDB 一直到了 2.0 前後，比起早期版本，已經有長足的進步，並且支援了相當多的功能，也對規模化和資料庫系統管理下了很多功夫. 對於大多數的資料庫應用，已經非常適合. 若你對資料庫相關技術有些了解，就會知道，當資料庫的資料發展一定規模程度，或是要確保系統不當機時，我們就需要用到 Master/Slave 的方式去備份和備援，當主要(Master)伺服器出了問題，次要(Slave)伺服器便即時補上，保持系統運作.
自己动手实现Multi-Master Replication
- - P.Linux Laboratory本文内容遵从 CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/database/diy_multi_master_replication.html. 首发： http://www.mysqlops.com/2012/02/14/diy_multi_master_replication.html.