use*_*622 5 mysql mysql-5.6 amazon-rds
RDS 新手（习惯于在自己的数据中心拥有自己的服务器）。
我们在 RDS 上使用 MySQL 5.6。
当从服务器在复制滞后时落后，主服务器将停止轮换其二进制日志。显然，在轮换二进制注销之前，等待每个从站提交每个事务。我在概念上没有问题（只要您在主服务器的磁盘空间上有监视器，这是一件好事）。
我的问题是学术性的——是什么导致这种情况发生？
** 我知道异步复制，主节点不知道从节点的状态
这是同步复制的功能吗？半同步复制？
我想要一些洞察力，也许是指向某处白皮书的指针（我找不到解决二进制日志未被轮换的特定问题的人）
这似乎不是 MySQL 服务器固有的任何内容，因此我无法正确引用“导致”这种情况发生的原因——但我强烈怀疑这是 RDS 设计的一个元素。
如果您查看一下，SHOW FULL PROCESSLIST;您会注意到始终有一个名为“rdsadmin”的用户连接。如果查看mysql架构，您会发现一个名为 的表rds_heartbeat2，最近的纪元时间 x 1000 存储在其单行中。这每隔几分钟就会改变一次，我的合理猜测是“rdsadmin”正在这样做。
我随机选择了一个 binlog 来检查这个理论，这是第一个事件：
use `mysql`; INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1393029075007)
ON DUPLICATE KEY UPDATE value = 1393029075007
然后，我将推测“rdsadmin”用户正在刷新二进制日志，然后立即向该表写入一个新值。从该表中读取从节点上的值将为 RDS 监控系统提供一种机制来确定/监视从节点的行为，允许它清除它知道已完全处理的二进制日志，或者让它们在主节点上逗留，如果它们还没有，以便在没有可用日志的情况下不会捕获奴隶。
expire_logs_daysRDS 似乎在外部管理这个过程，而不是让 MySQL 根据全局变量自行老化它的 binlog ，而且这个过程很可能负责将日志归档在视线之外，以便它们可以用于本机 RDS时间点恢复功能。
Slave上有两个线程：IO线程和SQL线程。IO 线程从 master 拉取二进制日志（准确地说是二进制日志中的事件），SQL 线程执行它们。
当人们说从属设备落后时，他们隐含的意思是 SQL 线程落后，而不是 IO 线程。IO 线程速度很快（比 SQL 线程更快），因为它所要做的就是从主服务器读取事件并将其顺序写入文件（中继日志）。