MySQL 英文原文：How does MySQL Replication really work?

虽然在我们的博客上曾经有了非常多篇关于复制的博文，比方《单线程复制》，《半同步复制》或许《预算复制容量》，但我感到我们依然没有一篇讲述MySQL的复制在高条理上任务道理的根底的博文。或许有过如许一篇，可是宣布工夫过于长远，致使于我找不到了。所以，我决议本人写一篇。

固然，MySQL的复制有很多方面，但本文首要讲述其逻辑——复制事情如何写入主机，如何传送至复制语句和他们随后如何使用。留意，本文其实不讲述如何履行复制，而是引见复制的任务道理。

复制事情

我在这篇文章中说“复制事情”是由于我不想防止会商与分歧的复制格局有关的工具。 这些都曾经十分好地在 in the MySQL manual here谈到了。容易地说，这些事情可所以以下的两种：

• 基于语句 – 在这类状况下编写查询语句
• 基于行 – 假如你真要为其归类的话，相似于行变更的差别信息

除些以外，我不会回忆用分歧的复制格局来复制， 首要是由于它们在传输数据时差别性很小。

关于master

让我们先来看看master是怎么任务的. 关于复制的任务, 起首一切的master需求向一个特殊的称之为二进制日记的文件中写入复制事情. 这是个十分轻量的举措(假定事情不会同步到磁盘), 由于写操作是次序的而且是缓冲的方式. 二进制日记文件存储了以后slave将要读取的数据信息.（master/slave个人感到仍是英文更能表现其深入意义,故未翻译,译者注）

当slave恳求衔接到一个master的时分, master会创立一个新的线程 (这个进程和其他的Server客户真个方法根本一样) 来处置客户端 – slave 的恳求. 大部分的操作给slave供给二进制日记中的事情而且告诉slave有新的写入事情到二进制日记中.

Slaves最Start的时分极可能会去读取仍存储在master操作系统缓存中的事情, 因而这时候在master上还没有任何物理磁盘的读操作. 可是, 当你几小时后乃至几天后衔接到一台slave机械上, slave会起首Start读取几小时或几天之前写入的二进制日记 – 此时master极可能不会再有这些数据的缓存, 那末读磁盘操作就不成防止的发作了. 假如master没有任何的闲暇的IO资本, 这时候你可能会感触感染到服务震动.

关于复制

让我们看看slave都干了些甚么东东. 当你启动使用的时分, slave会开启二个线程:

1. IO 线程

这个进程会挪用IO 线程衔接到一台master上, 读取master到来的二进制日记事情然后仅仅是将它们复制到当地的一个叫 中继日记的文件中. 仅仅是这些.

虽然只要一个线程从master上读binlog，同时只要一个线程在slave上去写relay log，可是这类 replication event 被复制的方法，简直不会被当作招致 replication变得更慢的要素

假如你想了解以后IO线程所处那边, 运用“show slave statusG”来检查详细信息:

• Master_Log_File – 从master上复制过去的比来的文件 (大多数状况下它和master比来写入的二进制日记文件一样)
• Read_Master_Log_Pos – master上二进制日记复制到slave上中继日记的地位.

并且你也能够比较它们与master上“show master statusG”后果的差别 .

2. SQL 线程

第二个进程 – SQL 线程 – 从slave当地的中继日记中读取事情 (就是被IO线程写入的文件) 而且尽快的运用它们.

这个线程因为是单线程化的所以饱受人们的批评. 回到 “show slave statusG”, 你可以从下面的变量中获得以后SQL线程的形态信息:

• Relay_Master_Log_File – 来自master的二进制日记, 供SQL线程处置 (实践上SQL线程是任务在中继日记上的, 这仅仅是为了展现信息的便利性)
• Exec_Master_Log_Pos – SQL线程履行的二进制日记的地位.

复制延迟

在这里，如今我大要上引见一下复制延迟这个问题。当你碰到复制延迟时，起首你要晓得两个复制线程中，是哪个出问题。大大多数状况下是因为SQL线程呈现了问题，不外你依然需求二次反省一下。你可使用上面提到的（本机）复制形态（show slave statusG）和主机二进制日记形态（运用show master statusG取得）实行比较。

我上面曾经提过非常多次了，因为IO线程惹起的复制延迟是很少见的，假如是IO线程惹起的，有一个你可以测验考试处理的办法是，运用enabling slave compressed protocol（备机数据紧缩协议）。  

别的，假如你确认是SQL线程的问题，想搞清楚问题的缘由，你可使用vmstat号令了解详细缘由。运用这个号令对Server形态监控一段工夫后，察看输出列表中是“r”列仍是“b”列占用了大部分工夫。假如是“r”列数值较高，那末复制进程首要是CPU麋集型操作，不然是IO麋集型操作。假如还不长短常断定，可使用CPU监控号令mpstat，失掉更直观的了解。

留意，上面监控的后果是假定你没有其他顺序运转在Server上。假如有一些其他的顺序运转在Server上，你可以了解一下 diskstats，运用这个Tools查询SQL线程可以生成一个更好的监控图。

假如你断定复制是CPU麋集型操作， 这个可能也会对你有效。

假如是IO麋集型操作，处理这个问题可能其实不轻易（或许可能很容易）。让我说明一下吧。假如是IO麋集型，这意味着大大多数工夫，由于读操作是单线程实行的，所以SQL线程不克不及够疾速读到数据。是的，这就是问题地点，读操作限制了复制的功能，而不是写操作。让我更具体地说明一下。

假定你有一个RAID10，带写缓存的硬盘。如今Start写操作，即便写操作是串行操作，由于写数据可以缓冲在缓存把持器，而且RAID卡外部可以并行写数据到多个硬盘。因而具有类似硬件的备机，写速度简直可以和主机同步。

然后如今Start 读操作。当你的Task聚集（workset）不合适在内存中时，曾经变更的数据将必需起首从硬盘读出，这时候候单线程读操作限制了复制的速度，由于单线程读操作时，某一时辰一个线程仅仅只能从一个硬盘读取数据。

正如方才所说的，处理IO麋集型复制操作功能的问题，可以增加内存容量，使更多的Task聚集（workset）可以合适在内存中。另外一种办法是改换IO装备，以使单线程每秒钟可以读取更多的数据 - 如今传统最快的硬盘可以到达250个IO操作/每秒，SSDs（固态硬盘）可以到达1000个IO操作/每秒。
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务