问Amazon和二进制日志旋转

EN

这似乎并不是MySQL服务器的固有特性，所以我不能给您一个正确的引文，说明是什么“导致”了这种情况--但我强烈怀疑这是RDS设计的一个要素。

RDS似乎是在服务器之外管理这个进程，而不是让MySQL自己根据全局变量expire_logs_days来绑定日志，而且这个过程很可能是负责将日志归档，从而使它们可以用于本机的RDS 实时恢复特性。

如果您查看SHOW FULL PROCESSLIST;，您会发现始终有一个名为“rdsadmin”的用户连接。如果您查看mysql模式，您将发现一个名为rds_heartbeat2的表，最近的时代时间x1000存储在它的单行中。这种情况每隔几分钟就会改变一次，我的推测是，"rdsadmin“用户(由RDS创建)正在这样做。

我随机选择了一个二进制日志来测试这个理论，下面是第一个事件：

use `mysql`; INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1393029075007) 
ON DUPLICATE KEY UPDATE value = 1393029075007

然后，我将推测"rdsadmin“用户定期刷新binlog，然后立即向该表写入一个新值。在副本上读取此表中的值将为RDS监控系统提供一种确定/监视副本行为的机制，允许RDS清除它知道已经完全处理的绑定日志，或者允许它们在主服务器上徘徊，如果它们还没有完成，那么就不会捕获托管副本而不需要必要的日志。

虽然这不是最初问题的一部分.正如注释中所指出的，读者可能在试图找出如何防止RDS如此仓促地清除二进制日志时得出了这个答案。mysql模式中有一个特殊存储过程，可用于将绑定日志的保留时间设置为1到168之间的值。当您不设置日志时，默认的行为是几乎立即清除日志，只要没有托管副本需要它们。

mysql> CALL mysql.rds_set_configuration('binlog retention hours', 24);

从线程上有两个线程: IO线程和SQL线程。IO线程从主进程中提取二进制日志(确切地说，二进制日志中的事件)，SQL线程执行它们。

当人们说从线程落后时，意味着SQL线程落后，而不是IO线程。IO线程速度快(比SQL线程更快)，因为它所要做的就是从主线程读取一个事件，然后按顺序将其写入一个文件(中继日志)。

默认情况下，主程序无限期地保存它的所有二进制日志。有一个在N天(expire_logs_days)之后过期日志的设置，但有时这可能有点不切实际，因为在我看来，您确实希望根据存储容量(GB；而不是时间)分配。

听起来就像这样，亚马逊已经编写了自己的保留机制，作为expire_logs_days的替代方案，但它并不总是那么聪明。我不确定你能否得到正式的书面答复。这更多的是在RDS内部管理领域。