MySQL：Binlog保留多长时间？

Question

我有一个mysql从属服务器，正在尝试复制一个主mysql实例。

我一周左右从生产主实例迁移数据。当时我SHOW MASTER STATUS在master上调用，并获得了binlog的名称和位置。现在，当我运行时，SHOW MASTER STATUS我得到：

mysql> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.039446 |      120 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.05 sec)

那个二进制日志不同于一周前的二进制日志。

我可以不再开始复制b / c我要定位的binlog了吗？我可以签出一个变量来查看自己“拥有”多长时间后才能开始复制吗？

编辑：

还通过mysql文档进行了更多阅读，我发现了应该列出所有二进制日志的命令：

mysql> SHOW BINARY LOGS;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.039456 |       479 |
| mysql-bin-changelog.039457 |       120 |
+----------------------------+-----------+
2 rows in set (0.07 sec)

同样，我上周写下的二进制日志未在此处列出，因此我的问题仍然存在...

编辑2：

这是特定于AWS RDS的，但是我发现了一个存储过程，其中列出了保留时间：

mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                          |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL  | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)

Query OK, 0 rows affected (0.06 sec)

在这里它说binglog被保留24小时。我要复制的数据库需要24个小时以上的时间才能迁移，这意味着在准备复制时，其需要访问的复制日志已被删除...

编辑3：

在这里找到：

日志文件大小

MySQL慢查询日志，错误日志和常规日志文件的大小限制为不超过数据库实例分配的存储空间的2％。为了保持此阈值，日志将每小时自动轮换一次，并删除24小时之前的日志文件。如果在删除旧的日志文件后合并的日志文件大小超过阈值，则将删除最大的日志文件，直到日志文件大小不再超过阈值。

Answer 1

对于特定于AWS RDS的实例，您可以使用以下存储过程找到二进制日志的保留长度：

mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                          |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL  | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)

Query OK, 0 rows affected (0.06 sec)

在尝试将当前的MySQL RDS实例迁移到Amazon Aurora时，我必须首先迁移数据库，然后开始复制迁移窗口期间发生的任何更新。因为迁移需要24个小时，所以我需要设置一个比Amazon提供的默认24窗口更长的窗口，显然我可以使用以下存储过程：

Amazon RDS通常会尽快清除二进制日志，但是该二进制日志必须在实例上仍然可用，以便mysqlbinlog访问。要指定RDS保留二进制日志的小时数，请使用mysql.rds_set_configuration存储过程，并指定一个有足够时间供您下载日志的时间段。设置保留期限后，请监视数据库实例的存储使用情况，以确保保留的二进制日志不会占用过多的存储空间。

本示例将保留期设置为1天：

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

看起来我需要增加主服务器上的保留时间并进行另一次迁移，因此我的当前迁移无法再正确地进行复制。