我正在使用RDS的读取副本机制对一个非常大的Mysql表进行架构更新。我运行了一个Alter命令，它将表锁定很长一段时间（超过24小时）。在那段时间里，我的读取副本没有得到更新，我注意到Replica lag值正在缓慢增加。
当表更新完成时，我看到Replica lag正在慢慢减少，直到读取的副本最终赶上了原始DB。
当我的Alter命令运行时，我做了一个小实验，偶尔会更新一个特定的行，这样我就可以在我的读取副本上遵循它。我的实验表明，对这一特定行的更新最终也发生在读取副本中（在表解锁后）。
根据上面的实验结果，我假设在我的读取副本更新时被阻止的所有更新最终也在表修改后在我的复制数据库上执行，但对于如此大的表和如此长的时间段来说，很难证明这一点。
我找不到任何关于这种机制如何工作的官方文档，我想知道所有这些更新究竟缓冲在哪里，这个缓冲区的限制是什么（例如，我什么时候开始丢失主数据库上发生的更改）？
这在文档中有介绍。具体来说，复制副本（"从属"）服务器的中继日志是更改通常等待的地方，直到它们在复制副本上实际执行为止。
http://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
但是，复制副本的落后程度的限制——但最终数据仍然与主副本相同——是多种因素的结合。只要受到监控，它就不应该悄悄地"错位"任何缓冲的更改。
每次master数据库上的数据发生变化时，master都会向其二进制日志中写入一个复制事件，这些日志通常以接近实时的方式传递到复制副本，在那里它们被存储在中继日志中，就像发送一样，这是两步过程的第一步。
第二步是复制副本依次读取这些日志，并根据主服务器发送的内容修改其本地数据集。这些语句通常是按顺序执行的。
决定复制副本可以安全地落后多远的两个最大因素是复制副本上可用于中继日志的存储量和主机上的存储量加上日志保留时间。RDS在"库存"MySQL Server之上有额外的逻辑，以防止主机清除其日志副本，直到副本收到为止。