Establecimiento y muestra de la configuración del registro binario - Amazon Relational Database Service

Establecimiento y muestra de la configuración del registro binario

Los siguientes procedimientos almacenados establecen y muestran los parámetros de configuración, por ejemplo, para la retención de archivos de registro binario.

mysql.rds_set_configuration

Especifica el número de horas que se deben conservar los registros binarios o el número de segundos que se retrasará la replicación.

Sintaxis

CALL mysql.rds_set_configuration(name,value);

Parámetros

name

El nombre del parámetro de configuración que se va a definir.

value

El valor del parámetro de configuración.

Notas de uso

El procedimiento mysql.rds_set_configuration admite los parámetros de configuración siguientes:

Los parámetros de configuración se almacenan de forma permanente y sobreviven a cualquier reinicio o conmutación por error de una instancia de base de datos.

binlog retention hours

El parámetro binlog retention hours se usa para especificar la cantidad de horas que se deben retener los archivos de registro binario. Por lo general, Amazon RDS limpia un registro binario lo antes posible, pero el registro binario podría seguir siendo necesario para la replicación con una base de datos MySQL externa a RDS.

El valor predeterminado de binlog retention hours es NULL. En RDS para MySQL, NULL significa que los registros binarios no se retienen (0 horas).

Para especificar el número de horas que se deben retener los registros binarios en una instancia de base de datos, utilice el procedimiento almacenado mysql.rds_set_configuration y especifique un periodo lo bastante largo como para realizar la replicación, como se muestra en el siguiente ejemplo.

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

nota

No puede utilizar el valor 0 para binlog retention hours.

Para la mayoría de las instancias de base de datos de MySQL, el valor máximo de binlog retention hours es 168 (7 días).

Una vez que haya definido el periodo de retención, monitorice el uso del almacenamiento para la instancia de base de datos con el fin de asegurarse de que los logs binarios conservados no consuman demasiado almacenamiento.

Para las implementaciones de clústeres de base de datos multi-AZ, solo puede configurar la retención de registros binarios desde la instancia de base de datos del escritor y la configuración se propaga a todas las instancias de base de datos del lector de forma asíncrona. Si los registros binarios del clúster de base de datos superan la mitad del espacio total de almacenamiento local, Amazon RDS mueve automáticamente los registros obsoletos al volumen de EBS. Sin embargo, los registros más recientes permanecen en el almacenamiento local, por lo que podrían perderse si se produce un fallo que requiera la sustitución del host o si se escala la base de datos vertical u horizontalmente.

Retardo del origen

Utilice el parámetro source delay en una réplica de lectura para especificar el número de segundos que se debe retrasar la replicación desde la réplica de lectura a su instancia de base de datos de origen. Amazon RDS suele replicar los cambios lo antes posible, pero podría ser conveniente retrasar la replicación en algunos entornos. Por ejemplo, cuando la replicación se ha retrasado, puede restaurar los cambios en una réplica de lectura retrasada al momento justo anterior de un desastre. Si una tabla se elimina por accidente, puede usar la replicación retardada para recuperarla rápidamente. El valor predeterminado de target delay es 0 (no retrasar la replicación).

Al utilizar este parámetro, se ejecuta mysql.rds_set_source_delay y aplica CHANGE primary TO MASTER_DELAY = valor de entrada. Si el procedimiento se realiza correctamente, guarda el parámetro source delay en la tabla mysql.rds_configuration.

Para especificar el número de segundos que Amazon RDS debe retrasar la replicación en una instancia de base de datos de origen, utilice el procedimiento almacenado mysql.rds_set_configuration y especifique el número de segundos que deberá retrasarse la replicación. En el ejemplo siguiente, se especifica que la replicación se retrasa al menos una hora (3600 segundos).

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

A continuación, se ejecuta el procedimiento mysql.rds_set_source_delay(3600).

El límite del parámetro source delay es de un día (86400 segundos).

nota

El parámetro source delay no es compatible con la versión 8.0 de RDS para MySQL las versiones inferiores a la 10.2 de MariaDB.

target delay

Utilice el parámetro target delay para especificar el número de segundos que se retrasará la replicación entre una instancia de base de datos y cualquier réplica de lectura futura administrada por RDS creada a partir de esta instancia. Este parámetro se omite para las réplicas de lectura no administradas por RDS. Amazon RDS suele replicar los cambios lo antes posible, pero podría ser conveniente retrasar la replicación en algunos entornos. Por ejemplo, cuando la replicación se ha retrasado, puede restaurar los cambios en una réplica de lectura retrasada al momento justo anterior de un desastre. Si una tabla se elimina por accidente, puede usar la replicación retrasada para recuperarla rápidamente. El valor predeterminado de target delay es 0 (no retrasar la replicación).

Para la recuperación de desastres, puede utilizar este parámetro de configuración con el procedimiento almacenado mysql.rds_start_replication_until o el procedimiento almacenado mysql.rds_start_replication_until_gtid. Para restaurar los cambios en una réplica de lectura retrasada al momento justo anterior de un desastre puede ejecutar el procedimiento mysql.rds_set_configuration con este parámetro establecido. Después de que el procedimiento mysql.rds_start_replication_until o mysql.rds_start_replication_until_gtid detenga la replicación, puede promocionar la réplica de lectura para que sea la nueva instancia de base de datos primaria utilizando las instrucciones de Promoción de una réplica de lectura para convertirla en una instancia de base de datos independiente.

Para utiliza el procedimiento mysql.rds_rds_start_replication_until_gtid, debe habilitarse la replicación basada en GTID. Para omitir una transacción específica basada en GTID que se sabe que causa un desastre, puede usar el procedimiento almacenado mysql.rds_skip_transaction_with_gtid. Para obtener más información sobre el uso de la replicación basada en GTID, consulte Uso de la replicación basada en GTID.

Para especificar el número de segundos que Amazon RDS debe retrasar la replicación en una réplica de lectura, utilice el procedimiento almacenado mysql.rds_set_configuration y especifique el número de segundos que deberá retrasarse la replicación. En el ejemplo siguiente se especifica que la replicación se retrasa al menos una hora (3600 segundos).

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

El límite del parámetro target delay es de un día (86400 segundos).

nota

El parámetro target delay no es compatible con la versión 8.0 de RDS para MySQL o las versiones anteriores a la 10.2 de MariaDB.

mysql.rds_show_configuration

El número de horas que se conservan los registros binarios.

Sintaxis

CALL mysql.rds_show_configuration;

Notas de uso

Para verificar el número de horas que Amazon RDS conserva los registros binarios, use el procedimiento almacenado mysql.rds_show_configuration.

Ejemplos

El ejemplo siguiente muestra el periodo de retención:

call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.