MySQL：binlogs保留了多长时间？

Question

我有一个mysql slave，我试图复制一个主mysql实例。

我从生产主实例迁移了一周左右的数据。 当时我在master上调用了SHOW MASTER STATUS并获得了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)

那个binlog与一周前的那个不同。

我可以不再启动复制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)

在这里它说binglogs保留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小时，所以我需要设置一个比亚马逊提供的默认24窗口更长的窗口，显然我可以使用以下存储过程 ：

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

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

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

看起来我需要延长主服务器上的保留时间并进行另一次迁移，我的当前服务器无法再正常复制。