Oracle 内部复制文档解读

MySQL 复制:


Replication 是MySQL的一个功能 允许servers 把数据库的改变从一个实例复制到另一个实际


1. master 记录所有的数据改变和结构改变到binary log


2.slave 向master 请求binary log 应用里面的内容。


Mysql 复制；


在Mysql 里复制是把改变从一个server（master) 到另一个或多个slaves.


master 把改变写入到binary log，slaves 请求master的binary log,应用它的内容。


binlog file 的文件格式影响了 slaves如何应用这些改变。MySQL 支持

基于语句的,基于行的,混合格式记录的

slave的数量:

对于一个master 能有多少个slave 这是没有限制的,然而, 每一个额外的
salve会使用少量master的资源,
所以，你应该仔细考虑
在生产设置每个salve的好处

对于一个master 最优的slaves的数目 依靠大量的因素: schema的大小,写的次数, master和slave相关的性能

CPU和可用内存因素。一个
总的原则是一个主的slave的数量为不超过30。


Network Outages

复制MySQL在网络中断,每个slave 跟踪已经处理了多少日志,继续处理当网络连接恢复时，


这个动作是自动的 不需要特定的配置。


复制 Masters 和slaves



master/slave 关系是一对多：

1.每个slave 从一个master 读取日志

2.一个master 可以运送日志到多个slaves


3.一个slave 可以表现为master相比其他的slave.

Relay Slave:  

一个slave 可以表现为一个master相比其它的slave，

改变发生在最顶层的master 被请求, 立即被slaves应用日志。应用改变到它们的slaves,


直到复制到链的末端。这使得更新传播通过复制的多个层次,允许拓扑变的更加复杂。

每个额外的增加了更多的传播延迟,因此一个较浅的结构设置会有更少的延迟复制相比更深的结构。

每个slave server 只能有一个master server，一个slave不能从多个master servers复制。

一个slave 可以表现为一个master 对于其它的slave servers 这个被叫做relay slave.



用黑洞存储引擎进行复制

黑洞存储引擎默默的丢失了所有的数据而没有警告。binary log 持续记录数据库的所有改变,


对特定的表使用黑洞引擎 在一个relay slave 当复制所有的改变到其他slaves，但是它本身不需要存储数据。


比如,如果你有一个relay slave 被仅用于执行频繁的长时间运行的BI报告在针对比小部分表上,

你可以配置其他所有的复制表使用黑洞引擎 那么server 就不会存储数据,当复制所有改变到它的slaves.



复杂的拓扑:

更加辅助的拓扑可能是:

1.一个双方向的拓扑有2个master server，相互slave

2.一个循环的拓扑有任意数量的servers.


-- 每个即是master 又是slave

--任何master上的改变复制到所有的master


不是每个slave 必须有一个master

注意: MySQL 复制不执行冲突解决。

Conflict Resolution(冲突的解决)


在一个典型的配置里, 客户端只写master 但是从任何的机器读取改变。在一个允许并发的更新相似的数据,


这个
在多个服务器上的数据的最终状态可能不一致。它是
防止或管理冲突的操作应用的责任.


MySQL 复制不执行冲突解决。


冲突可能发生在任何的拓扑(包括一个或者多个master)，这包括简单的
层次如在前面的幻灯片显示,

如果一个relay slave接收客户端的改变,冲突在环形拓扑中尤为普遍.


举个例子,考虑一家电子商务公司实现复制使用循环
拓扑，其中的两个servers 处理应用 "奢侈品牌"

和"特价活动" ,分别的。 假设复制不管理冲突操作,那么下面的事情会发生:

1. "奢侈品牌" 组增加奢侈品价格20%

2."特价活动" 组 降低所有超过500美元的降低50美元 因为一个即将到来的节日


3.一个产品标价520美元的同时落入这2个类别,它的值被前面的操作修改


最终的产品的价格在每个server上取决于每个server 执行操作的顺序。如果两个操作发生在相同的时间,那么下面的操作发生了:

1.在"奢侈品牌" 组的server 增加了产品价格的20%,从520到624美元。


2.在"特价活动" 组 里的server 调低了价格从,520到470美元


3.改变复制到其他的server，导致在"奢侈品牌"  server 假设最终的价格为574美元,在"特价活动" 组 的最终价格为$564


4. 其他服务器在复制环境下,假设最终的价格依赖执行操作的顺序。



类似的,冲突如果发生在 “奢侈品牌” 组增加了一个新的产品,具有不可复制的完全由 "特价活动" 组做出改变



复制使用的例子:


通用的使用用于复制:

1.横向扩展  分散查询负载到多个slave

2.BI 和分析: 运行昂贵的报表和分析在slave上,

让master 处理生产应用

3.地理数据的分布:


Common Use Cases

1.横向扩展： 最流行的原因是实现复制来分散查询负载通过一个或者多个slave servers 来改善读的性能。


让写在master 上。 


2.BI 和分析: 商业智能报告和分析
处理可以是资源密集型的，可能需要相当长的时间来执行。

在一个复制环境,你可以运行这些查询在一个slave上,master 可以持续的服务生产不被长时间运行的报表影响。


3.地理数据的分布:  公司分布式地理的存在可以从复制中收益,通过在每个区域处理本地数据和复制整个组织的数据。


整个提供了性能和班底管理的好处



复制用于高可用


复制允许各种高可用使用例子:


1.控制切换:使用一个副本来代替生产server 在硬件或者系统升级的时候

2.server 冗余: 执行一个failover 到一个副本server 由于系统failure

3.在线的schema 改变：执行一个滚动的更新在一个有多个server的环境来避免一个整体的系统断供

复制允许你fail over 到slave server 如果你的master 脱机由于硬件和软件故障,或者执行定期维护。


配置复制:



1.配置每台server 一个唯一的server-id

2.配置每个master：

 -- 启用binary log ，启用TCP/IP 网络

 --创建一个新的用户具有复制权限

-- 备份master 数据库和日志的coordinates


配置每个slave



1.从master 恢复备份

2. 执行CHANGE MASTER TO 语句在每个slave上:

 master的地址

 复制的用户和密码

开始复制的log 的位置

启动 START SLAVE



每个server 在复制环境必须有一个唯一的server-id


Master 配置:

每个master 必须有一个地址和端口,因为复制不能使用UNIX socket 文件,每个master 必须启用binnary log，


因为在复制过程中,每个slave 发送它的日志内容到每个slave.



每个slave 必须登录到master进行复制,你需要在master上创建一个账号用于复制:


如果你创建一个复制使用一个已经包含了有数据的数据库,你需要创建一个数据库的备份作为slave复制的起点

(比如,通过在master上执行一个备份在slave上进行恢复) 


Slave 配置:

每个slave连接到一个master，为了告诉slave 关于master，使用CHANGE MASTER TO 语句


CHANGE MASTER TO 

执行CHANGE MASTER TO 语句在slave上来改变连接到master的复制连接信息:


CHANGE MASTER 随后的调用保留每个没有指定选项的值


改变master的host或者port 会重置log coordinates

下面的语句改变密码,但是仍旧保持其他所有的设置:

CHANGE MASTER TO MASTER_PASSWORD='newpass';

MASTER_HOST 和MASTER_PORT 值指定了hostname和TCP 端口号。 MASTER_USER和MASTER_PASSWORD 值

指定了master 上的账户具有复制 SLAVE的权限。 为了改善安全,你也可以使用MASTER_SSL和相关选型



MASTER_LOG_FILE 和MASTER_LOG_POS 值包含了 binary log的 log coordicate (slave 开始复制的起点)

你可以得到日志和位置 在master 上执行SHOW MASTER STATUS statement:
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000014 | 51467 | | | |
+------------------+----------+--------------+------------------+-------------------+




如果你使用mysqldump 来执行备份master的数据库作为复制的起点,你可以使用--master-data选型

来包括log coordinates 在备份文件里:

mysqldump -uroot -p --master-data -B world_innodb > backup.sql


Failover with Log Coordinates

为了找到一个新的master 和正确的log coordinates 用于每个slave，你必须检查binary log


1.找到最近应用的event

2.选择一个最新的slave 作为新的master

3. 确定log coordinates 在新的master 上


4.执行CHANGE MASTER TO 在每个slave上。


在循环拓扑中,找到源event 在每个binary log 变的困难。

fail over 当master 变 的不可用时, 停止所有的slaves，选择一个slave作为新的master 

通过执行CHANGE MASTER TO 语句(带上新的master 的log cooedinates) 在余下的slave上执行

如果在你failover的时候 slave并不都是最新的,你
有一个不一致的复制拓扑的风险：

1.如果新的master 是在一个特定的slave后面(也就是说,如果slave 已经应用了新的master 的结束的event)，

slave 重复那些events


2.如果新的master 在特定的slave 前面(也就是说,也就是说新的master的binary log 包含的events


slave 还没有应用)，slvae跳过这些事件



为了避免这些不一致性, 你必须祖安泽一个最新的slave 作为master，然后找出新的master上的

log coordinates 来匹配最新的event在每个slave上, 如果有些slaves 相比其他落后很多,


log coordinates 你提供了 在CHANGE MASTER TO 语句中slave 之间不相同,


因此你不能简单的执行SHOW MASTER STATUS 在新的master 上,代替的是,你必须检查binary logs 来找到正确的

coordinates.

在循环拓扑有多个master接收客户端的更新,找到最新的slave 和定义正确的log coordinates是非常困难的,


因为每个slave 应用操作在不同的顺序。为了避免这个困难,使用Global Transaction Identifiers(GTIDs)


复制过滤规则:

过滤是server 选项 应用在master 或者slave上:

1. master 应用binlog-* 过滤当写binary log的时候 

2.slave 应用 replicate-* 过滤当读取relay log的时候

基于数据库的:

Database:

-replicate-do-db,binlog-do-db

-replicate-ignore-db,binlog-ignore-db


使用过滤规则 当不同的slave 在一个环境里用于不同的目的。比如,


一个server 专用于显示web内容不需要复制重新存储的信息 或者从总工资记录,

当server 专用于生成销售的管理报告不需要存储web内容或者市场数据

过滤规则复杂的优先级规则:

1. 数据库过滤应用优先于表过滤

2.表的通配符过滤 *-wild-* 应用在不使用通配符后面

3.*-do-* 过滤应用在各自的"*-ignore-* 过滤前

在使用多个过滤的时候需要小心,很容易犯错误,由于复杂的关系 哪个过滤条件被应用。


因为过滤控制了哪些数据被复制,这类错误没法被克服。 由于这个原因,不要使用不同类型的过滤。

比如,如果你使用了replicate-wild-*,就不要使用任何通配的replicate-*过滤。

MySQL 实用

MySQL 功能是命令行工具提供大量的用户功能,它们是:


1. MySQL Wokbench 描述

2.用于维护和管理MySQL server


MySQL 功能用于复制

几个功能是特别有用的用于复制:

1.mysqldbcopy ：复制数据库从源server 到一个目的server 通过复制配置


2.mysqldbcompres:比较2个数据库找到不同,创建一个脚本来同步它们


3.mysqlrpladmin: 管理复制拓扑:

1. Failover 到最好的slave 在master失败后

2.切换提升一个指定的slave

3.启动,充值和停止所有的slave


4.mysqlfailover：持续的监控一个master



mysqldbcopy 功能接收--rpl 选项来运行CHANGE MASTER TO 语句在目的server上,它接收下面的值:

1.master： 目的server 变为一个源的slave

2.slave 源已经是另一个master的slave


异步复制

1.slave 请求binary log 然后应用它的内容

---slave 对比master 有滞后

2.master 不关心 slave 何时应用binary log

---master 不等待slave 继续操作

在MySQL 复制在它的默认配置, master server 接收从客户端的改变的event，提交这些events 把它们写入到binary log.


在一个单独的thread，master 把binary log 流动到连接的slaves,因为master 提交改变不等待任何slave的响应,

这个叫做异步复制。

更重要的是,这意味着slave还没有应用事物的同时 master已经返回给应用成功了。通常,这没有问题。

然而,如果master crashes 数据丢失了在提交事务后,在事务复制到任何的slave前,

事务会丢失尽管应用已经返回给用户成功了。


如果master 等待所有的slaves 来应用改变在提交事务前,这个叫做同步。


尽管MySQL 复制不是同步的,MySQL Cluster 使用同步复制内部的 确保数据一致在整个cluster 内,


MySQL 客户端请求是同步 


半同步复制:

1. 需要master 上有一个插件和至少一个slave

2.阻塞每个master 上的evnet 直到至少一个slave 接收到master的binary log

3.切换回异步模式 如果超时发生

为了启用半同步复制,在master 上安装插件和至少一个slave.使用下面的插件:

1.rpl_semi_sync_master 在master上

2.rpl_semi_sync_slave 在slave上

你必须启用下面的选项:

1.rpl_semi_sync_master_enabled 在master上

2.rpl_semi_sync_slave_enabled 在slave上

如果你在masyer 上启用半同步复制,它表现为异步直到至少一个半同步的slave连接。


在半同步复制,master 阻塞当一个事务提交后 直到至少一个半同步的slave 确认它已经收到了事务。



也就是说 至少一个slave 已经接到了事务同时master 返回给应用成功。


如果master crashed 数据丢失了在提交之后,事务的信息至少在一个slave上被写入。





回顾Binary log



1.包含了数据和schema的改变,和它们的时间戳
---基于语句的或者基于行的

2.用于基于时间的备份,从备份恢复和复制

交替时间:

1.MySQL 重启

2.它到达了max_binlog_size 设置的最大值

3.你执行flush logs 语句


在这张幻灯片的材料是一个总结的内容包括本课题为“服务器
配置“


FLUSH LOGS 在一个复制环境

默认的,MYSQL server 写FLUSH 命令到Binary log ，这样语句可以被复制到slaves.

为了避免这个发生,使用选项 NO_WRITE_TO_BINLOG.


Replication logs

slave server 保持信息关于复制的events

1.Relay log 设置:

 --包括relay logs和relay log index 文件

 --包含master的binary log 的一份拷贝


Slave 状态日志:

--包含了执行复制需要的信息

--master的连接信息和log coordinates

--Relay log coordinates

Relay logs: MySQL 自动管理 relay log 文件集,删除文件当它已经replay 所有的events

创建一个信息的文件 当当前的文件达到最大relay log file size (或者max_binlog_size 如果max_relay_log_size 是0）
max_relay_log_size：标记relay log 允许的最大值，如果该值为0，则默认值为max_binlog_size；如果不为0，则

max_relay_log_size则为最大的relay_log文件大小；




mysql> show variables like '%max_relay_log_size%';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| max_relay_log_size | 0     |
+--------------------+-------+
1 row in set (0.06 sec)

relay logs 存储的格式和binary logs 格式相同,你可以使用mysqlbinlog命令查看。 slave维护一个index 文件

来记录relay log 文件的轨迹。


relay log 文件是以<host_name>-relay-bin.<nnnnnn>默认的格式命名,索引文件是 <host_name>-relay-bin.index命名。

使服务器的配置
免疫未来的主机名的变化，改变这些主机名称前缀通过设置选项 --relay-log 和--relay-log-index.


Slave 状态文件: slave 存储信息关于如何连接到master，和最近复制的master的binary log 的log coordinates 


和slave的relay log 信息

有2类这样的日志:

1.Master information： 这个日志包含了关于master的信息,包括主机名和端口,连接认证等信息,


和最新从mster 下载的binary log 和log 的coordinates


2.Relay log information: 这个日志抱恨最近被执行的relay log的coordinates




Crash-Safe 复制

Binary logging 是crash-safe

--MySQL 只记录完整的evnets或者事务

--使用sync-binlog 来改善安全

--默认的,值是0,说明操作系统写文件根据它的内部规则



mysql>  show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |
+---------------+-------+
1 row in set (0.00 sec)


--设置sync_binlog 为1 来强制操作系统每次事务都写文件,


或者设置一个任何的较大的值来写在那个数量的事务数后


2.存储slave status 文件在table里用于crash-safe 复制


Crash-Safe 复制

 slave 状态日志默认是存储在文件里的, 使用master-info-file 和relay-log-info-file 选项来设置文件名字

默认,文件名是master.info和relay-log.info ，都存储在数据目录下。


如果你存储slave 状态日志在文件里,一个crash 可能发生在记录一个event和激励event的log coordinates 到状态文件之间。

当server 在这样的event后启动,状态文件和Binary log 会不一致,恢复会变得困难。


当复制数据使用的是事务型引擎 比如InnoDB，存储状态日志在事务表里来改善性能和确保crash-safe 复制

通过设置master-info-repository 和relay-log-info-repository .


复制线程:


当slave 连接到一个master：

1.master 创建一个Binlog dump thread

-- 从Binary log 读取events 发送到slave I/O thread


2.slave 创建至少2个threads：

-- Slave I/O thread

  --从master的binary log dump thread 读取events ,把它们写入到slave的relay log


--SLAVE SQL thread

--应用relay log events 在一个single-threaded slave

--描述relay log evnts 在woker threads 和multithreaded slave


MySQL 创建threads 在master和slave上来执行复制:


当一个slave 成功连接到Master，master server 发起一个复制master的thread，叫做Binlog dump thread，


显示为Binlog Dump GTID 如果slave 被配置为使用了 auto-positioning protocol(CHANGE MASTER TO MASTER_AUTO_POSITION).



这个thread 发送binary log的events 到slave，当slave连接的时候。master 创建一个Binlog dump thread 用于每个连接的

slave.


默认,每个slave 发起两个threads，被叫做Slave I/O thread 和slave SQL thread ，


1.Slave I/O thread 连接到master，读取master的binlog dump thread 的更新到本地的relay log

2.Slave SQL thread 执行relay log里的events


默认的配置,叫做single-threaded 由于单个SQL thread 处理relay log，到导致slave 滞后,


当slave 落后于 master的时候,master 应用改变使用并行模式,如果它有多个客户端连接,但是它序列化所有的events 在它的

binary log里。

slave 顺序的执行events 在单独的一个single thread，
会成为高容量环境里的瓶颈,


或者 slave的硬件不足够强大来处理繁忙的容量在single thread


mysql> show processlist;
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time   | State                                                   

                    | Info             |
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+
|   2 | system user |           | NULL | Connect | 663752 | Waiting for master to send event                        

                    | NULL             |
|   3 | system user |           | NULL | Connect |    -34 | Slave has read all relay log; waiting for the slave I/O 

thread to update it | NULL             |
| 110 | root        | localhost | NULL | Query   |      0 | init                                                    

                    | show processlist |
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+
3 rows in set (0.03 sec)


Multithreaded Slaves：

MySQL 支持多个slaves 来避免迟滞 由于单个的singel-threaded slaves.


如果你设置slave_parallel_workers变量在slave上设置大于0

mysql>  show variables like '%slave_parallel_workers%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

它会创建更多的worker threads.在那种情况下, Slave SQL thread 不直接执行events.


代替的是,它将描述events 对于work threads 在每个数据库的基础上，这个使multithread slaves 特别有用 

在复制数据在多个数据库的环境。



这个选项能导致不一致的情况在数据库之间,如果worker threads 执行并行操作按一个次序 不同于master上,


因此你必须确保 不同数据库的数据是独立的, 一个数据库的数据, 被单个的single thread 复制,是强制保持一致的。




控制slave threads

1.控制 slave threads:

start slave;

stop slave;

2. 控制单个的threads:

start slave IO_THREAD;

stop   slave SQL_THREAD;



你可以启动和停止slave的 SQL和I/O threads 用START SLAVE 和STOP SLAVE 语句。


不需要带参数, 那些语句控制所有的threads. 控制单个的threads 通过使用IO_THREAD 或者SQL_THREAD 作为参数。

比如,你可以临时的停止slave 从master 查询通过执行下面的语句在slave上:

STOP SLAVE TO_THREAD;

监控复制:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 120.26.56.85
                  Master_User: backup
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000011
          Read_Master_Log_Pos: 406856217
               Relay_Log_File: mysqld-relay-bin.000011
                Relay_Log_Pos: 306855629
        Relay_Master_Log_File: mysql-bin.000011
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: mysql,information_schema
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 406856217
              Relay_Log_Space: 306855803
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 135
                  Master_UUID: 5b4aff83-cf9c-11e4-91fd-00163e002c0d
             Master_Info_File: /data01/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)


Slave_*_Running:


   Slave_IO_Running: Yes
   Slave_SQL_Running: Yes


Slave_IO_Running 和 Slave_SQL_Running 列 说明了 是否slave的I/O和SQL thread 当前是否运行,


可能的值为 Yes,No或者connecting

Master Log Coordinates: Master_Log_File和Read_Master_Log_Pos 列 说明了 最近的master的binary log 的coordinate

   Master_Log_File: mysql-bin.000011
   
   Read_Master_Log_Pos: 406856217




如果Master_Log_File和Read_Master_Log_Pos 是在master（show master status)后面,


这个说明网络传输有延迟 在Master和slave之间。

mysql> show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000011
         Position: 407656639
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 
1 row in set (0.00 sec)


Relay Log Coordinates: Relay_Log_File 和Relay_Log_Pos 列说明了 Slave的

SQL thread 已经执行的relay log 的coordinates.


复制 Slave I/O thread 状态:


最通用的查看I/O thread 状态是:

1. 正在连接的master

2. 等待master 发送event

3.排队master 的event 到relay log

4.等待重新连接在连接binlog dump 失败后

在这张表和下一张幻灯片显示的状态是最常见的状态  SHOW PROCESSLIST 输出的 slave server I/O thread 的列,


那些状态也出现在SHOW SLAVE STATUS 的Slave_IO_Staue 列

mysql> show processlist;
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time   | State                                                   

                    | Info             |
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+
|   2 | system user |           | NULL | Connect | 680528 | Waiting for master to send event                        

                    | NULL             |
|   3 | system user |           | NULL | Connect |    -36 | Slave has read all relay log; waiting for the slave I/O 

thread to update it | NULL             |
| 110 | root        | localhost | NULL | Query   |      0 | init                                                    

                    | show processlist |
+-----+-------------+-----------+------+---------+--------

+-----------------------------------------------------------------------------+------------------+


1. Connecting to master:表示thread 是尝试连接到master

2.Waiting for master to send event: thread 已经连接到了master 等待binary log events 到达。


这个会持续很久 如果master 是空闲的, 如果等外持续了slave_read_timeout秒,超时发生。



3.Queueing master event to the relay log:

thread 读取了一个event(从master)  copy 内容到relay log 里,因此 SQL thread 可以处理它。


4.Waiting to reconnect after a failed binlog dump request:

如果binary log dump 请求failed, 然后试图重新定期进行连接。

Replication Slave I/O Thread States

1.重新连接当请求binlog dump失败后

|  964415 | backup     | dr-mysql01.zjcap.com:48254        | NULL   | Binlog Dump | 683207 | Master has sent all 

binlog to slave; waiting for binlog to be updated | NULL             |



2.等待 重新连接 在一个master event read 失败后


3.重新连接在master event 读取失败后




Replication Slave SQL Thread States