AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

mysql.rds_set_configuration

指定要保留二进制日志的小时数或要延迟复制的秒数。

语法

CALL mysql.rds_set_configuration(name,value);

参数

使用说明

mysql.rds_set_configuration 存储过程在以下版本的 RDS for MySQL 中可用：

mysql.rds_set_configuration 过程支持以下配置参数：

binlog retention hours

binlog retention hours 参数用于指定保留二进制日志文件的小时数。Amazon RDS 通常会尽快清除一个二进制日志，但对于 Amazon RDS 外部的 MySQL 数据库的复制，该二进制日志可能仍是必需的。对于 RDS for MySQL，binlog retention hours 的默认值为 NULL（不保留二进制日志）。Aurora MySQL 的默认值为 24（二进制日志保留 1 天）。

要指定 Amazon RDS 在数据库实例上保留二进制日志的小时数，请使用 mysql.rds_set_configuration 存储过程并指定足以让复制发生的时段，如以下示例中所示。

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

对于 MySQL 数据库实例，最大 binlog retention hours 值为 168 个小时 (7 天)。

在设置保留期后，监视数据库实例的存储用量以确认保留的二进制日志不会占用太多存储空间。

target delay

可以使用 target delay 参数指定将从源数据库实例到只读副本的复制延迟的秒数。所指定的延迟时间适用于从当前数据库实例创建的新副本。Amazon RDS 通常会尽快复制更改，但某些环境可能希望延迟复制。例如，在延迟复制后，您可以将延迟只读副本向前滚动到发生灾难之前的时间。如果意外删除一个表，您可以使用延迟复制快速恢复该表。target delay 的默认值为 0（不延迟复制）。

对于灾难恢复，您可以将该配置参数与 mysql.rds_start_replication_until 或 mysql.rds_start_replication_until_gtid 存储过程一起使用。要将延迟只读副本的更改向前滚动到发生灾难之前的时间，您可以运行 mysql.rds_set_configuration 过程并设置该参数。在 mysql.rds_start_replication_until 或 mysql.rds_start_replication_until_gtid 过程停止复制后，您可以使用将只读副本提升为独立的数据库实例中的说明将只读副本提升为新的主数据库实例。

要使用 mysql.rds_rds_start_replication_until_gtid 过程，必须启用基于 GTID 的复制。要跳过已知会导致灾难的特定基于 GTID 的事务，您可以使用 mysql.rds_skip_transaction_with_gtid 存储过程。有关使用基于 GTID 的复制的更多信息，请参阅在 RDS for MySQL 中使用基于 GTID 的复制。

要指定 Amazon RDS 延迟只读副本的复制的秒数，请使用 mysql.rds_set_configuration 存储过程并指定要延迟复制的秒数。以下示例指定至少一个小时（3600 秒）内延迟复制。

call mysql.rds_set_configuration('target delay', 3600);

target delay 参数的限制为一天（86400 秒）。