mysql.rds_set_configuration
指定要保留二进制日志的小时数或要延迟复制的秒数。
语法
CALL mysql.rds_set_configuration(name,value);
参数
- name
-
要设置的配置参数的名称。
- 值
-
配置参数的值。
使用说明
mysql.rds_set_configuration
存储过程在以下版本的 RDS for MySQL 中可用:
-
MySQL 5.6
-
MySQL 5.7
-
MySQL 8.0
mysql.rds_set_configuration
过程支持以下配置参数:
Binlog retention hours
binlog retention hours
参数用于指定要保留二进制日志文件的小时数。Amazon RDS 通常会尽快清除一个二进制日志,但对于 Amazon RDS 外部的 MySQL 数据库的复制,该二进制日志可能仍是必需的。binlog retention hours
的默认值为 NULL
。对此默认值的解释如下:
-
对于 RDS for MySQL,
NULL
表示不保留二进制日志(0 小时)。 -
对于 Aurora MySQL,
NULL
表示延时清理二进制日志。Aurora MySQL 二进制日志可能会在系统中保留一段时间,但通常不超过一天。
要指定 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 的复制的更多信息,请参阅将基于 GTID 的复制用于 RDS for MySQL。
要指定 Amazon RDS 延迟只读副本的复制的秒数,请使用 mysql.rds_set_configuration
存储过程并指定要延迟复制的秒数。以下示例指定至少一个小时(3600 秒)内延迟复制。
call mysql.rds_set_configuration('target delay', 3600);
target delay
参数的限制为一天(86400 秒)。
RDS for MySQL 仅支持 target delay
参数。
RDS for MySQL 版本 8.0 不支持 target delay
参数。