我正在使用RDS的只读副本机制来对非常大的Mysql表进行架构更新。
我运行了一个Alter命令，可以将表锁定很长一段时间（超过24小时）。
在那段时间里，我的阅读副本没有得到更新，我注意到Replica lag值正在缓慢增加。
当表格更新完成后，我看到Replica lag正在缓慢下降，直到读取副本最终赶上原始数据库。
当我的Alter命令运行时，我做了一个小实验，偶尔会更新一个特定的行，所以我可以在我的只读副本上关注它。我的实验表明，对这一特定行的更新确实最终也发生在只读副本中（在表解锁后）。
根据上面的实验结果，我假设在我的只读副本更新时被阻止的所有更新最终也在表修改后在我的复制数据库上执行但是很难为这样一个大表证明类似的东西这么长的一段时间。
我无法找到有关此机制如何工作的任何官方文档，我想知道所有这些更新的缓冲区域以及缓冲区的限制（例如，何时开始丢失我的更改）掌握DB）？
答案 0 :(得分：3)
文档中对此进行了介绍。具体来说，副本（＆＃34; slave＆＃34;）服务器的中继日志是更改通常等待它们实际在副本上执行的位置。
http://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
但是，复制品的落后范围限制 - 但最终，数据与主数据相同 - 是多种因素的组合。它不应该悄悄地＆＃34;错位＆＃34;任何缓冲的更改，只要它被监控。
每次master数据库上的数据发生变化时，master都会将复制事件写入其二进制日志，并且这些日志通常以近实时的形式传递到副本，并存储它们，几乎就像 - 在中继日志中发送，作为两步过程的第一步。
第二步是根据主服务器发送的内容，使副本按顺序读取这些日志，并修改其本地数据集。这些陈述通常是按顺序执行的。
决定副本可以安全地落后多远的两个最大因素是副本上的中继日志可用的存储量以及主服务器上的存储量和日志保留时间。 RDS在＆＃34; stock＆＃34;之上有额外的逻辑。 MySQL服务器，以防止主服务器清除其日志副本，直到副本已收到它们。