17.2 Replication Implementation

复制是基于master server 跟踪所有改变到他的数据库(更新,删除等等)在它的binary log.


binary log 作为些所有事件修改数据的结构或者内容从server 开始启动

典型的,SELECT 语句是不被记录的因为它们既不修改数据库也不修改内容


每个slave 连接到master 请求一个binary log的拷贝。

也就是说,它从master 拉数据,相比master 推数据到slave.

slave也执行从binary log 执行events 。 这个重复原始的改变 就像它们在master上一样。


表时被创建或者它们的结果修改,数据被插入,删除,和更新根据改变发生在master上一样



因为每个slave 是独立的,replay master 的binary log的改变发生在每个slave (slave是连接到Master)


此外,因为每个slave 接收一份Binary log的拷贝只要通过从master 请求,

slave 是可以读取和更新数据库的拷贝以自己的步伐可以启动和停止复制进程 不影响更新最新的数据库状态在主或者从一侧


master binary log 是些到一个本地的的relay log 在slave端在它被处理前。


Vsftp:/data01/mysql# ls -ltr *relay*
-rw-rw---- 1 mysql mysql       120 Nov 14 10:27 Vsftp-relay-bin.000001
-rw-rw---- 1 mysql mysql        25 Nov 14 10:27 Vsftp-relay-bin.index
-rw-rw---- 1 mysql mysql       221 Nov 14 21:59 mysqld-relay-bin.000006
-rw-rw---- 1 mysql mysql        52 Nov 14 21:59 mysqld-relay-bin.index
-rw-rw---- 1 mysql mysql 198021585 Nov 15 09:14 mysqld-relay-bin.000007



slave 也记录信息关于当前的master binary log和local relay log的位置


17.2.1 Replication Implementation Details  复制实现细节:


MySQL 复制功能是实现使用3个进程,一个在master server和2个在slave上。


1.Binlog dump thread,master 创建一个线程来发送binary log 内容到一个slave 当slave连接时。


这个线程可以是被在SHOW PROCESSLIST 的输出在master上

zabbix:/data01/mysql# mysql -uroot -p1234567 -e "SHOW PROCESSLIST"

| 198968 | backup     | 192.168.11.187:45976 | NULL   | Binlog Dump | 46595 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
| 204759 | root       | localhost            | NULL   | Query       |     0 | init                                                                  | SHOW PROCESSLIST |




binary log dump thread 需要一个lock 在master的binary log 对于读取每个event 发送到slave.


当event 被读取,lock是被释放,甚至在event被发送到slave之前


Slave I/O thread.  当一个START SLAVE 语句是执行在一个slave server,slave 创建一个I/O thread,

连接到master 和告诉master 发送更新记录在master的binary logs.


slave I/O thread 读取更新 master的Binlog Dump thread 发送的 复制他们到本地的文件 slave的relay log


thread 的状态是显示为Slave_IO_running 在SHOW SLAVE STATUS的输出 或者SHOW STATUS. 的 Slave_running


Slave SQL thread  slave创建一个SQL thread 来读取relay log  被 slave I/O thread写入的,

执行其中包含的事件

在先前的描述,有三个线程么每个master/slave 连接。一个master 有多个slaves 创建一个binary log dump thread 对于米格连接的slave,


每个slave 有它自己的I/O和SQL threads.


一个slave 使用2个threads 来分别的读取更新从master 和执行它们到单独的任务。

因此,读取任务的语句是不会减慢如果语句执行是慢的,


例如,如果slave server 没有运行一段时间,它的I/O thread 可以快速的获取binary log 内容从master 当slave 开始后,


即使SQL thread 远远落后,如果slave 停止 在SQL thread 已经执行所有取得的SQL之前,

I/O thread 已经至少获取了一切这样一个安全的语句的拷贝是存储在本地的slave的relay logs里，


准备用于执行 等下次slave 启动的时候



SHOW PROCESSLIST  语句提供了信息高速你 Master上发生了什么,slave上关于复制

slave:
mysql> SHOW PROCESSLIST ;
+----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time  | State                                                                       | Info             |
+----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+
| 11 | system user |           | NULL | Connect | 51213 | Waiting for master to send event                                            | NULL             |
| 12 | system user |           | NULL | Connect |  -140 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 14 | root        | localhost | NULL | Query   |     0 | init                                                                        | SHOW PROCESSLIST |
+----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)


下面的例子阐述3个线程在SHOW PROCESSLIST的输出


在master server上,SHOW PROCESSLIST 输出像这样:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 2
   User: root
   Host: localhost:32931
     db: NULL
Command: Binlog Dump
   Time: 94
  State: Has sent all binlog to slave; waiting for binlog to
         be updated
   Info: NULL


在这里, 线程2 是一个 Binlog Dump replication thread 服务一个连接的slave.


状态信息表明所有的更新已经发送到slave ，master是等待更多的更新发生。


如果你看到 no Binlog Dump threads 在master server上, 这意味着复制是没有被运行,没有slave 是当前连接的。


On a slave server, the output from SHOW PROCESSLIST looks like this: 

在slave server上,SHOW PROCESSLIST 输出像这样:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O
         thread to update it
   Info: NULL


状态信息表明 thread 10 是I/O thread 和master server通讯,

线程11是SQL thread 处理更新存储在relay logs.