Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario) - Amazon Aurora
Configuración de la replicación con MySQL o con otro clúster de base de datos de AuroraSincronización de contraseñas entre el origen de replicación y el destinoDetener la replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de AuroraUso de Amazon Aurora para escalar las lecturas de una base de datos de MySQLOptimización de replicación de registros binariosConfiguración del binlog mejorado

Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)

Dado que Amazon Aurora MySQL es compatible con MySQL, puede configurar la replicación entre una base de datos MySQL y un clúster de base de datos Amazon Aurora MySQL. Este tipo de replicación utiliza la replicación de registros binarios de MySQL, también conocida como replicación binlog. Si utiliza la replicación de registro binario con Aurora, le recomendamos que su base de datos MySQL ejecute MySQL versión 5.5 o posterior. Puede configurar la replicación donde el clúster de base de datos de Aurora MySQL sea el origen de replicación o la réplica. Puede replicar con una instancia de base de datos MySQL de Amazon RDS, una base de datos MySQL externa a Amazon RDS u otro clúster de base de datos de Aurora MySQL.

nota

No puede usar la replicación binlog hacia o desde ciertos tipos de clústeres de bases de datos de Aurora. En particular, la replicación de binlog no está disponible para clústeres de Aurora Serverless v1. Si las instrucciones SHOW MASTER STATUS y SHOW SLAVE STATUS (versión 2 de Aurora MySQL) o SHOW REPLICA STATUS (versión 3 de Aurora MySQL) no devuelven ningún resultado, verifique que el clúster que está utilizando sea compatible con la replicación binlog.

En la versión 3 de Aurora MySQL, la replicación del registro binario no se realiza en la base de datos del sistema de mysql. Las contraseñas y las cuentas no se replican por medio de binlog en la versión 3 de Aurora MySQL. Por lo tanto, las instrucciones del lenguaje de control de datos (DCL), como CREATE USER, GRANT y REVOKE, no se replican.

También puede reproducir con una instancia de base de datos de RDS for MySQL o con un clúster de base de datos de Aurora MySQL en otra Región de AWS. Cuando esté realizando una replicación entre Regiones de AWS, asegúrese de que los clústeres y las instancias de base de datos sean accesibles públicamente. Si los clústeres de base de datos de Aurora MySQL están en subredes privadas de la VPC, utilice la interconexión de VPC entre las Regiones de AWS. Para obtener más información, consulte Acceso a un clúster de base de datos en una VPC desde una instancia EC2 de otra VPC.

Si desea configurar una replicación entre un clúster de base de datos de Aurora MySQL y un clúster de base de datos de Aurora MySQL en otra Región de AWS, puede crear un clúster de base de datos de Aurora MySQL como réplica de lectura en una Región de AWS diferente del clúster de base de datos de origen. Para obtener más información, consulte Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS.

Con las versiones 2 y 3 de Aurora MySQL, puede replicar entre Aurora MySQL y un origen o destino externos que utilicen identificadores de transacciones globales (GTID) para la replicación. Asegúrese de que los parámetros relacionados con GTID en el clúster de base de datos de Aurora MySQL disponga de una configuración que sea compatible con el estado del GTID de la base de datos externa. Para obtener información sobre como hacer esto, consulte Uso de la replicación basada en GTID. En Aurora MySQL versión 3.01 y posterior, puede elegir cómo asignar GTID a las transacciones que se replican desde un origen que no utiliza GTID. Para obtener información sobre el procedimiento almacenado que controla ese ajuste, consulte mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versión 3).

aviso

Cuando replique entre Aurora MySQL y MySQL, asegúrese de usar únicamente tablas InnoDB. Si tiene tablas de MyISAM que desea replicar, puede convertirlas a InnoDB antes de configurar la replicación con el siguiente comando. 

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Configuración de la replicación con MySQL o con otro clúster de base de datos de Aurora

La configuración de la replicación de MySQL con Aurora MySQL incluye los siguientes pasos, que se describen en detalle:

1. Activar el registro binario en el origen de replicación

2. Retenga los registros binarios en el origen de replicación hasta que dejen de ser necesarios

3. Cree una instantánea o volcado del origen de replicación

4. Cargue la instantánea o volcado en el destino de la réplica

5. Cree un usuario de replicación en su origen de replicación

6. Active la replicación en el destino de la réplica

7. Monitoree su réplica

1. Activar el registro binario en el origen de replicación

Puede encontrar instrucciones acerca del procedimiento para activar el registro binario en el origen de replicación de su motor de base de datos a continuación.

2. Retenga los registros binarios en el origen de replicación hasta que dejen de ser necesarios

Cuando se utiliza la replicación de registro binario de MySQL, Amazon RDS no administra el proceso de replicación. Como resultado, debe asegurarse de que los archivos binlog del origen de replicación se retienen hasta que los cambios se hayan aplicado a la réplica. Este mantenimiento le ayuda a restaurar la base de datos de origen si se produce un error.

Consulte las siguientes instrucciones para conservar registros binarios para el motor de base de datos.

3. Cree una instantánea o volcado del origen de replicación

Debe usar una instantánea o volcado del origen de replicación para cargar una copia de línea de base de los datos en la réplica y comenzar después a replicar desde ese punto.

Use las siguientes instrucciones para crear una instantánea o volcado del origen de la replicación de su motor de base de datos.

4. Cargue la instantánea o volcado en el destino de la réplica

Si va a cargar datos desde un volcado de una base de datos MySQL que sea externa a Amazon RDS, puede crear una instancia de EC2 para copiar en ella los archivos del volcado y cargar a continuación los datos en el clúster de base de datos o la instancia de base de datos desde esa instancia de EC2. Con este método, puede comprimir los archivos de volcado antes de copiarlos en la instancia de EC2 con el fin de reducir los costos de la red asociados con la copia de datos en Amazon RDS. También puede cifrar el archivo o los archivos de volcado para proteger los datos mientras se transfieren por la red.

Use las siguientes instrucciones para cargar la instantánea o volcado del origen de replicación en el destino de la réplica para su motor de base de datos.

5. Cree un usuario de replicación en su origen de replicación

Además, cree un ID de usuario en el origen que solo se utilice para la replicación. El siguiente ejemplo es para bases de datos de origen de RDS para MySQL o MySQL externas.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Para las bases de datos de origen de Aurora MySQL, el parámetro del clúster de base de datos skip_name_resolve está establecido en 1 (ON) y no se puede modificar, por lo que debe usar una dirección IP para el host en lugar de un nombre de dominio. Para obtener más información, consulte skip_name_resolve en la documentación de MySQL.

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

El usuario requiere los privilegios REPLICATION CLIENT y REPLICATION SLAVE. Conceda estos privilegios al usuario.

Si necesita usar la replicación cifrada, exija conexiones SSL al usuario de la replicación. Por ejemplo, puede utilizar una de estas instrucciones para exigir el uso de conexiones SSL en la cuenta de usuario repl_user.

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
nota

Si REQUIRE SSL no se incluye, la conexión de replicación podría cambiarse inadvertidamente por una conexión sin cifrar.

6. Active la replicación en el destino de la réplica

Antes de activar la replicación, se recomienda que realice una instantánea manual del clúster de base de datos de Aurora MySQL o del destino de la réplica de la instancia de base de datos de RDS for MySQL. Si surge un problema y tiene que restablecer la replicación con el clúster de base de datos o el destino de la réplica de instancia de base de datos, puede restaurar el clúster de base de datos o la instancia de base de datos desde esta instantánea en lugar de tener que volver a importar los datos en el destino de la réplica.

Utilice las siguientes instrucciones para activar la replicación para su motor de base de datos.

Si la replicación falla, puede provocar un gran aumento de la E/S no intencionada en la réplica, lo que puede degradar el rendimiento. Si la replicación falla o ya no se necesita, puede ejecutar el procedimiento almacenado mysql.rds_reset_external_master (Aurora MySQL versión 2) o mysql.rds_reset_external_source (Aurora MySQL versión 3) para eliminar la configuración de la replicación.

Establecimiento de una ubicación para detener la replicación en una réplica de lectura

En la versión 3.04 y versiones posteriores de Aurora MySQL, puede utilizar el procedimiento almacenado mysql.rds_start_replication_until (versión 3 de Aurora MySQL) para iniciar la replicación y volver a detenerla en una ubicación concreta del registro binario.

Para iniciar la replicación en una réplica de lectura y detenerla en una ubicación concreta

  1. Use un cliente de MySQL para conectarse como usuario maestro a la réplica del clúster de base de datos MySQL.

  2. Ejecute el procedimiento almacenado mysql.rds_start_replication_until (versión 3 de Aurora MySQL).

    En el ejemplo siguiente se inicia la replicación y se replican los cambios hasta que alcanza la ubicación 120 del archivo registro binario mysql-bin-changelog.000777. En una situación de recuperación de desastres, supongamos que la ubicación 120 es justo anterior al desastre.

    call mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

La replicación se detiene automáticamente cuando se alcanza el punto de detención. Se genera el siguiente evento de RDS: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Si usa una replicación basada en GTID, use el procedimiento almacenado mysql.rds_start_replication_until_gtid (versión 3 de Aurora MySQL) en lugar del procedimiento almacenado mysql.rds_start_replication_until (versión 3 de Aurora MySQL). Para obtener más información sobre la replicación basada en GTID, consulte Uso de la replicación basada en GTID.

7. Monitoree su réplica

Al configurar una replicación de MySQL con un clúster de base de datos Aurora MySQL, debe monitorizar los eventos de conmutación por error para el clúster de base de datos Aurora MySQL cuando se trate del destino de la réplica. Si se produce una conmutación por error, el clúster de base de datos que es el destino de la réplica se podrá volver a crear en un nuevo host con una dirección de red diferente. Para obtener información acerca de la monitorización de los eventos de conmutación por error, consulte Uso de notificaciones de eventos de Amazon RDS.

También puede supervisar el retardo entre el origen de replicación y el destino de la réplica conectándose al destino de la réplica y ejecutando el comando SHOW SLAVE STATUS (versión 2 de Aurora MySQL) o SHOW REPLICA STATUS (versión 3 de Aurora MySQL). En la salida del comando, el campo Seconds Behind Master indica cuánto retardo tiene el destino de la réplica con respecto al origen.

Sincronización de contraseñas entre el origen de replicación y el destino

Cuando cambia cuentas de usuario y contraseñas en el origen de replicación mediante instrucciones SQL, dichos cambios se replican automáticamente en el destino de replicación.

Si utiliza la AWS Management Console, la AWS CLI o la API de RDS para cambiar la contraseña maestra en el origen de replicación, esos cambios no se replican automáticamente en el destino de replicación. Si desea sincronizar el usuario maestro y la contraseña maestra entre los sistemas de origen y destino, debe realizar el mismo cambio en el destino de replicación usted mismo.

Detener la replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora

Para detener la replicación del registro binario con una instancia de base de datos MySQL, una base de datos de MySQL externa u otro clúster de base de datos de Aurora, siga estos pasos, que se describen en detalle en este tema.

1. Detenga la replicación del registro binario en el destino de la réplica

2. Desactivar el registro binario en el origen de replicación

1. Detenga la replicación del registro binario en el destino de la réplica

Siga estas instrucciones para detener la replicación del registro binario de su motor de base de datos.

2. Desactivar el registro binario en el origen de replicación

Siga las instrucciones de la tabla siguiente para desactivar el registro binario en el origen de replicación de su motor de base de datos.

Uso de Amazon Aurora para escalar las lecturas de una base de datos de MySQL

Puede usar Amazon Aurora con su instancia de base de datos MySQL para aprovechar las capacidades de escalado de lectura de Amazon Aurora y ampliar la carga de trabajo de lectura para su instancia de base de datos MySQL. Para usar Aurora para escalar las lecturas de su instancia de base de datos de MySQL, cree un clúster de base de datos de Amazon Aurora MySQL y haga que sea una réplica de lectura de su instancia de base de datos de MySQL. Esto es válido para una instancia de base de datos de RDS for MySQL o una base de datos de MySQL que se ejecute fuera de Amazon RDS.

Para obtener más información acerca de la creación de un clúster de base de datos Amazon Aurora, consulte Creación de un clúster de base de datos de Amazon Aurora.

Cuando configure la replicación entre su instancia de base de datos MySQL y su clúster de base de datos de Amazon Aurora, asegúrese de seguir estas directrices:

  • Use la dirección del punto de enlace del clúster de base de datos Amazon Aurora cuando haga referencia a su clúster de base de datos Amazon Aurora MySQL. Si se produce una conmutación por error, la réplica de Aurora que se asciende a instancia principal del clúster de base de datos Aurora MySQL seguirá usando la dirección del punto de enlace del clúster de base de datos.

  • Mantenga los binlogs en la instancia de escritor hasta que haya comprobado que se han aplicado a la réplica de Aurora. Este mantenimiento garantiza que puede restaurar la instancia de escritor si se produce un error.

importante

Si usa la replicación autoadministrada, será responsable de monitorizar y resolver los problemas de replicación que se pueden producir. Para obtener más información, consulte Diagnóstico y resolución de retardos entre réplicas de lectura.

nota

Los permisos requeridos para comenzar la replicación en un clúster de base de datos de Aurora MySQL están restringidos y no están disponibles para su usuario maestro de Amazon RDS. Por este motivo, debe usar los procedimientos mysql.rds_set_external_master (Aurora MySQL versión 2), mysql.rds_set_external_source (Aurora MySQL versión 3) y mysql.rds_start_replication para configurar la replicación entre su clúster de base de datos de Aurora MySQL y su instancia de base de datos de MySQL.

Comience la replicación entre una instancia de origen externa y un clúster de base de datos de Aurora MySQL

  1. Configure la instancia de base de datos MySQL de origen como de solo lectura: 

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;

  2. Ejecute el comando SHOW MASTER STATUS en la instancia de base de datos MySQL para determinar la ubicación del binlog. Se recibe un resultado similar al del siguiente ejemplo: 

    File                        Position
------------------------------------
 mysql-bin-changelog.000031      107
------------------------------------

  3. Copie la base de datos la instancia de base de datos MySQL externa en el clúster de base de datos Amazon Aurora MySQL usando mysqldump. Para bases de datos muy grandes, recomendamos usar el procedimiento de Importación de datos a una instancia de base de datos de MySQL o MariaDB con tiempo de inactividad reducido en la Guía del usuario de Amazon Relational Database Service.

    Para Linux, macOS o Unix:

    mysqldump \
    --databases <database_name> \
    --single-transaction \
    --compress \
    --order-by-primary \
    -u local_user \
    -p local_password | mysql \
        --host aurora_cluster_endpoint_address \
        --port 3306 \
        -u RDS_user_name \
        -p RDS_password

    En Windows:

    mysqldump ^
    --databases <database_name> ^
    --single-transaction ^
    --compress ^
    --order-by-primary ^
    -u local_user ^
    -p local_password | mysql ^
        --host aurora_cluster_endpoint_address ^
        --port 3306 ^
        -u RDS_user_name ^
        -p RDS_password
    nota

    Asegúrese de que no haya ningún espacio entre la opción -p y la contraseña que haya escrito.

    Use las opciones --host, --user (-u), --port y -p del comando mysql para especificar el nombre de host, el nombre de usuario, el puerto y la contraseña para conectarse a su clúster de base de datos Aurora. El nombre de host es el nombre DNS del punto de enlace del clúster de base de datos Amazon Aurora, por ejemplo, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com. Puede encontrar el valor del punto de enlace en los detalles del clúster en la Management Console de Amazon RDS.

  4. Haga que la instancia de base de datos MySQL de origen vuelva a admitir la escritura:

    mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;

    A fin de obtener más información sobre cómo realizar copias de seguridad para su uso con la reproducción, consulte Backing up a source or replica by making it read only en la documentación de MySQL.

  5. En la Management Console de Amazon RDS, añada la dirección IP del servidor que aloja la base de datos MySQL de origen al grupo de seguridad de VPC para el clúster de base de datos Amazon Aurora. Para obtener más información acerca de la modificación de un grupo de seguridad de VPC, consulte Grupos de seguridad de su VPC en la Guía del usuario de Amazon Virtual Private Cloud.

    Es posible que también necesite configurar su red local para permitir las conexiones desde la dirección IP de su clúster de base de datos de Amazon Aurora con el fin de que se pueda comunicar con la instancia de MySQL de origen. Para encontrar la dirección IP del clúster de base de datos Amazon Aurora, use el comando host.

    host aurora_endpoint_address

    El nombre de host es el nombre DNS del punto de enlace del clúster de base de datos Amazon Aurora.

  6. Utilice el cliente que prefiera para conectarse a la instancia de MySQL externa y cree un usuario de MySQL que se usará para la replicación. Esta cuenta se usa únicamente para la replicación y debe estar limitada a su dominio para mejorar la seguridad. A continuación se muestra un ejemplo.

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';

  7. Para la instancia de MySQL externa, conceda a REPLICATION CLIENT y a REPLICATION SLAVE privilegios para el usuario de replicación. Por ejemplo, para conceder los privilegios REPLICATION CLIENT y REPLICATION SLAVE en todas las bases de datos al usuario "repl_user" del dominio, ejecute el siguiente comando.

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
    IDENTIFIED BY 'password';

  8. Tome una instantánea manual del clúster de base de datos de Aurora MySQL para que sea la réplica de lectura antes de configurar la replicación. Si tiene que restablecer la replicación con el clúster de base de datos como réplica de lectura, puede restaurar el clúster de base de datos de Aurora MySQL desde esta instantánea en lugar de tener que importar los datos desde su instancia de base de datos de MySQL en un nuevo clúster de base de datos de Aurora MySQL.

  9. Convierta el clúster de base de datos de Amazon Aurora DB en la réplica. Conéctese al clúster de base de datos de Amazon Aurora como usuario maestro e identifique la base de datos origen de MySQL como maestro de replicación usando los procedimientos mysql.rds_set_external_master (Aurora MySQL versión 2) o mysql.rds_set_external_source (Aurora MySQL versión 3) y mysql.rds_start_replication.

    Use el nombre del archivo de registro maestro y la posición del registro maestro que determinó en el paso 2. A continuación, se muestra un ejemplo.

    For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

  10. En el clúster de base de datos de Amazon Aurora, ejecute el procedimiento mysql.rds_start_replication para comenzar la replicación.

    CALL mysql.rds_start_replication;

Una vez que haya establecido la replicación entre su instancia de base de datos MySQL de origen y su clúster de base de datos Amazon Aurora, podrá añadir réplicas de Aurora a su clúster de base de datos Amazon Aurora. A continuación, puede conectarse a las réplicas de Aurora para escalar la lectura de sus datos. Para obtener más información acerca de la creación de una réplica de Aurora, consulte Adición de réplicas de Aurora a un clúster de base de datos.

Optimización de replicación de registros binarios

A continuación, puede aprender a optimizar el rendimiento de replicación de registros binarios y solucionar problemas relacionados en Aurora MySQL.

sugerencia

Esta discusión supone que está familiarizado con el mecanismo de replicación del registro binario de MySQL y cómo funciona. Para obtener información de fondo, consulte Implementación de replicación en la documentación de MySQL.

Replicación de registros binarios de varios subprocesos

Con la replicación de registros binarios de múltiples procesos, un subproceso SQL lee los eventos del registro de retransmisión y los pone en cola para que se apliquen los subprocesos de trabajo de SQL. Los subprocesos de trabajo SQL se administran mediante un subproceso coordinador. Los eventos de registros binarios se aplican en paralelo cuando es posible.

La replicación de registros binarios de varios subprocesos se admite en la versión 3 de Aurora MySQL y la versión 2.12.1 de Aurora MySQL y versiones posteriores.

Cuando se configura una instancia de base de datos de Aurora MySQL para utilizar la replicación de registros binarios, la instancia de réplica utiliza de forma predeterminada la replicación de un solo subproceso para las versiones de Aurora MySQL anteriores a la 3.04. Para habilitar la replicación de múltiples procesos, actualice el parámetro replica_parallel_workers con un valor superior a cero en el grupo de parámetros personalizado.

En la versión 3.04 y las versiones posteriores de Aurora MySQL, la replicación es multiproceso de forma predeterminada y replica_parallel_workers está establecido en 4. Puede modificar este parámetro en su grupo de parámetros personalizado.

Las siguientes opciones de configuración le ayudan a ajustar la replicación de múltiples procesos. Para obtener más información, consulte Opciones y variables de replicación y registro binario en el Manual de referencia de MySQL.

La configuración óptima depende de varios factores. Por ejemplo, el rendimiento de la replicación de registros binarios se ve afectado por las características de la carga de trabajo de la base de datos y la clase de instancia de base de datos en la que se ejecuta la réplica. Por lo tanto, le recomendamos que pruebe detenidamente todos los cambios en estos parámetros de configuración antes de aplicar la nueva configuración de parámetros a una instancia de producción.

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

En Aurora MySQL versión 3.06 y versiones posteriores, puede mejorar el rendimiento de las réplicas de registros binarios al replicar transacciones para tablas grandes con más de un índice secundario. Esta característica introduce un grupo de subprocesos para aplicar cambios de índice secundarios en paralelo en una réplica de binlog. La característica se controla mediante el parámetro del clúster de base de datos aurora_binlog_replication_sec_index_parallel_workers, que controla el número total de subprocesos paralelos disponibles para aplicar los cambios de índice secundarios. El parámetro está establecido en 0 (deshabilitado) de forma predeterminada. Para habilitar esta característica, no es necesario reiniciar la instancia. Para habilitar esta característica, detenga la replicación en curso, establezca el número deseado de subprocesos de trabajo paralelos y, a continuación, vuelva a iniciar la replicación.

También puede utilizar este parámetro como variable global, donde n es el número de subprocesos de trabajo paralelos:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Optimización de la reproducción binlog (Aurora MySQL 2.10 y versiones posteriores)

En Aurora MySQL versión 2.10 y versiones posteriores, Aurora aplica automáticamente una optimización conocida como caché de E/S de binlog a la reproducción de registros binarios. Al almacenar en caché los eventos de binlog confirmados más recientemente, esta optimización se ha diseñado para mejorar el rendimiento del subproceso de copia de datos de binlog y, a la vez, limitar el impacto de las transacciones en primer plano en la instancia de origen de binlog.

nota

La memoria utilizada para esta característica es independiente de la configuración binlog_cache de MySQL.

Esta característica no se aplica a las instancias de base de datos de Aurora que utilizan las clases de instancias db.t2 y db.t3.

No es necesario ajustar ningún parámetro de configuración para activar esta optimización. En particular, si ajusta el parámetro de configuración aurora_binlog_replication_max_yield_seconds a un valor distinto de cero en versiones anteriores de Aurora MySQL, vuelva a establecerlo en cero para Aurora MySQL 2.10 o versiones posteriores.

Las variables de estado aurora_binlog_io_cache_reads y aurora_binlog_io_cache_read_requests se encuentran disponibles en Aurora MySQL 2.10 y versiones posteriores. Estas variables de estado lo ayudan a monitorear la frecuencia con que se leen los datos de la caché de E/S de binlog.

  • aurora_binlog_io_cache_read_requests muestra el número de solicitudes de lectura de E/S de binlog de la caché.

  • aurora_binlog_io_cache_reads muestra el número de lecturas de E/S de binlog que recuperan información de la caché.

La siguiente consulta SQL calcula el porcentaje de solicitudes de lectura de binlog que aprovechan la información almacenada en caché. En este caso, cuanto más cerca esté la proporción de 100, mejor será. 

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

La característica de caché de E/S de binlog también incluye métricas nuevas relacionadas con los subprocesos de copia de datos de binlog. Los subprocesos de volcado son los subprocesos que se crean cuando se conectan réplicas de binlog nuevas a la instancia de origen de binlog.

Las métricas de subprocesos de copia de datos se imprimen en el registro de la base de datos cada 60 segundos con el prefijo [Dump thread metrics]. Las métricas incluyen información para cada réplica de binlog como Secondary_id, Secondary_uuid, el nombre del archivo de binlog y la posición que lee cada réplica. Las métricas también incluyen Bytes_behind_primary, que representan la distancia en bytes entre el origen de la reproducción y la réplica. Esta métrica mide el retraso del subproceso de E/S de réplica. Esta cifra es diferente del retraso del subproceso del aplicador SQL de la réplica, que se representa mediante la métrica seconds_behind_master de la réplica de binlog. Puede determinar si las réplicas de binlog alcanzan al origen o se quedan atrás al comprobar si la distancia disminuye o aumenta.

Optimización de la replicación de binlog (Aurora MySQL versión 2 a 2.09)

Para optimizar la replicación de registros binarios para Aurora MySQL, ajuste los siguientes parámetros de optimización a nivel de clúster. Estos parámetros le ayudan a especificar el equilibrio correcto entre la latencia en la instancia de origen binlog y el retraso de replicación.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

nota

Para clústeres compatibles con MySQL 5.7, puede usar estos parámetros en las versiones 2 a 2.09.* de Aurora MySQL. En Aurora MySQL 2.10.0 y versiones posteriores, estos parámetros se sustituyen por la optimización de la caché de E/S de binlog y no es necesario usarlos.

Descripción general del búfer de lectura grande y optimizaciones de rendimiento máximo

Es posible que experimente un rendimiento reducido de replicación de registros binarios cuando el subproceso de volcado de registros binarios accede al volumen del clúster Aurora mientras el clúster procesa un gran número de transacciones. Puede utilizar los parámetros aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds y aurora_binlog_read_buffer_size para ayudar a minimizar este tipo de contención.

Supongamos que tiene una situación en la que aurora_binlog_replication_max_yield_seconds está establecido en mayor que 0 y el archivo binlog actual del subproceso de volcado está activo. En este caso, el subproceso de volcado de registro binario espera un número especificado de segundos para llenar el archivo binlog actual con transacciones. Este período de espera evita la contención que puede surgir al replicar cada evento binlog individualmente. Sin embargo, al hacerlo aumenta el retraso de réplica para las réplicas de registros binarios. Esas réplicas pueden quedarse atrás de la fuente en el mismo número de segundos que la configuración aurora_binlog_replication_max_yield_seconds.

El archivo binlog actual significa el archivo binlog que el subproceso de volcado está leyendo actualmente para realizar la replicación. Consideramos que un archivo binlog está activo cuando el archivo binlog se está actualizando o abierto para ser actualizado por transacciones entrantes. Después de que Aurora MySQL llena el archivo binlog activo, MySQL crea y cambia a un nuevo archivo binlog. El antiguo archivo binlog se vuelve inactivo. Ya no se actualiza mediante transacciones entrantes.

nota

Antes de ajustar estos parámetros, mida la latencia y el rendimiento de la transacción a lo largo del tiempo. Es posible que descubra que el rendimiento de la replicación de registros binarios es estable y tiene baja latencia incluso si hay contención ocasional.

aurora_binlog_use_large_read_buffer

Si este parámetro se establece en 1, Aurora MySQL optimiza la replicación del registro binario en función de la configuración de los parámetros aurora_binlog_read_buffer_size y aurora_binlog_replication_max_yield_seconds. Si aurora_binlog_use_large_read_buffer es 0, Aurora MySQL ignora los valores de los parámetros aurora_binlog_read_buffer_size y aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Los subprocesos de volcado de registros binarios con un búfer de lectura más grande minimizan la cantidad de operaciones de E/S de lectura al leer más eventos para cada E/S. El parámetro aurora_binlog_read_buffer_size establece el tamaño del búfer de lectura. El búfer de lectura grande puede reducir la contención de logs binarios para cargas de trabajo que generan una gran cantidad de datos de binlog.

nota

Este parámetro solo tiene un efecto cuando el clúster también tiene la configuración aurora_binlog_use_large_read_buffer=1.

Aumentar el tamaño del búfer de lectura no afecta al rendimiento de la replicación de registros binarios. Los subprocesos de volcado de registro binario no esperan a que las transacciones de actualización llenen el búfer de lectura.

aurora_binlog_replication_max_yield_seconds

Si la carga de trabajo requiere una latencia de transacción baja y puede tolerar algún retraso de replicación, puede aumentar el parámetro aurora_binlog_replication_max_yield_seconds. Este parámetro controla la propiedad de rendimiento máximo de la replicación de registros binarios en el clúster.

nota

Este parámetro solo tiene un efecto cuando el clúster también tiene la configuración aurora_binlog_use_large_read_buffer=1.

Aurora MySQL reconoce inmediatamente cualquier cambio en el valor del aurora_binlog_replication_max_yield_seconds parámetro. No necesita reiniciar la instancia de base de datos. Sin embargo, cuando activa esta configuración, el subproceso de volcado solo comienza a rendir cuando el archivo binlog actual alcanza su tamaño máximo de 128 MB y se gira a un nuevo archivo.

Parámetros relacionados

Utilice los siguientes parámetros de clúster de base de datos para activar la optimización de binlog.

Parámetro Valor predeterminado Valores válidos Descripción
aurora_binlog_use_large_read_buffer 1 0, 1 Conmutador para activar la característica de mejora de replicación. Cuando es 1, el subproceso de volcado de registro binario utiliza aurora_binlog_read_buffer_size para la replicación del registro binario; de lo contrario, se utiliza el tamaño de búfer predeterminado (8K). No se utiliza en la versión 3 de Aurora MySQL.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Tamaño del búfer de lectura utilizado por el subproceso de volcado de registro binario cuando el parámetro aurora_binlog_use_large_read_buffer se establece en 1. No se utiliza en la versión 3 de Aurora MySQL.
aurora_binlog_replication_max_yield_seconds 0 0-36000

El valor máximo aceptado para las versiones 2.07.* de Aurora MySQL es 45. Puede ajustarlo a un valor más alto en las versiones 2.09 y posteriores.

Para la versión 2, este parámetro solo funciona cuando el parámetro aurora_binlog_use_large_read_buffer está establecido en 1.

Activación del mecanismo de rendimiento máximo de replicación de registros binarios

Puede activar la optimización de rendimiento máximo de replicación de registros binarios de la siguiente manera. Al hacerlo, se minimiza la latencia de las transacciones en la instancia de origen binlog. Sin embargo, es posible que experimente un mayor retraso en la replicación.

Para activar la optimización de binlog de rendimiento máximo para un clúster de Aurora MySQL

  1. Cree o edite un grupo de parámetros del clúster de base de datos con la siguiente configuración de parámetros:

    • aurora_binlog_use_large_read_buffer: activar con un valor de ON o 1.

    • aurora_binlog_replication_max_yield_seconds: especifique un valor mayor que 0.

  2. Asocie el grupo de parámetros de clúster de base de datos con el clúster Aurora MySQL que funciona como origen binlog. Para ello, siga los procedimientos en Working with parameter groups (Trabajar con grupos de parámetros).

  3. Confirme que el cambio de parámetro surte efecto. Para ello, ejecute la siguiente consulta en la instancia de origen binlog. 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    El resultado debería ser similar al siguiente. 

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

Desactivación de la optimización de rendimiento máximo de replicación de registros binarios

Puede desactivar la optimización de rendimiento máximo de replicación de registro binario de la siguiente manera. Al hacerlo, se minimiza el retraso de replicación. Sin embargo, es posible que experimente una latencia mayor para las transacciones en la instancia de origen binlog.

Para desactivar la optimización de rendimiento máximo para un clúster Aurora MySQL

  1. Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de Aurora MySQL disponga de aurora_binlog_replication_max_yield_seconds establecido en 0. Para obtener más información sobre el establecimiento de parámetros de configuración con grupos de consultas, consulte Working with parameter groups (Trabajar con grupos de parámetros).

  2. Confirme que el cambio de parámetro surte efecto. Para ello, ejecute la siguiente consulta en la instancia de origen binlog. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    El resultado debería ser similar al siguiente. 

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

Desactivación del búfer de lectura grande

Puede desactivar toda la característica de búfer de lectura grande de la siguiente manera.

Para desactivar el búfer de lectura de registro binario grande para un clúster Aurora MySQL

  1. Restablezca aurora_binlog_use_large_read_buffer en OFF o 0.

    Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de Aurora MySQL disponga de aurora_binlog_use_large_read_buffer establecido en 0. Para obtener más información sobre el establecimiento de parámetros de configuración con grupos de consultas, consulte Working with parameter groups (Trabajar con grupos de parámetros).

  2. En la instancia de origen binlog, ejecute la siguiente consulta. 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    El resultado debería ser similar al siguiente. 

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+

Configuración del binlog mejorado

El binlog mejorado reduce la sobrecarga de rendimiento de computación provocada por la activación del binlog, que puede alcanzar hasta un 50 % en algunos casos. Con el binlog mejorado, esta sobrecarga se puede reducir a aproximadamente un 13 %. Para reducir la sobrecarga, el binlog mejorado escribe los registros binarios y de transacciones en el almacenamiento en paralelo, lo que minimiza los datos escritos en el momento de la confirmación de la transacción.

El uso del binlog mejorado también mejora el tiempo de recuperación de la base de datos después de los reinicios y las conmutaciones por error hasta en un 99 % en comparación con el binlog comunitario de MySQL. El binlog mejorado es compatible con las cargas de trabajo basadas en binlogs existentes y usted interactúa con él de la misma manera que interactúa con el binlog de MySQL de la comunidad.

El binlog mejorado está disponible en la versión 3.03.1 de Aurora MySQL y versiones posteriores.

Configuración de los parámetros del binlog mejorado

Puede cambiar entre el binlog comunitario de MySQL y el binlog mejorado activando o desactivando los parámetros del binlog mejorado. Los usuarios actuales del binlog pueden seguir leyendo y consumiendo los archivos binlog sin lagunas en la secuencia de archivos binlog.

Para activar el binlog mejorado
Parámetro Predeterminado Descripción
binlog_format – Establezca el parámetro binlog_format en el formato de registro binario de su elección para activar el registro mejorado. Asegúrese de que binlog_format parameter no esté desactivado. Para obtener más información, consulte Configuración del registro binario de Aurora MySQL.
aurora_enhanced_binlog 0 Establezca el valor de este parámetro en 1 en el grupo de parámetros del clúster de base de datos asociado al clúster de Aurora MySQL. Al cambiar el valor de este parámetro, debe reiniciar la instancia del escritor cuando el valor DBClusterParameterGroupStatus aparezca como pending-reboot.
binlog_backup 1 Desactive este parámetro para activar el binlog mejorado. Para ello, establezca el valor de este parámetro en 0.
binlog_replication_globaldb 1 Desactive este parámetro para activar el binlog mejorado. Para ello, establezca el valor de este parámetro en 0.
importante

Puede desactivar los parámetros binlog_backup y binlog_replication_globaldb solo si usa el binlog mejorado.

Para desactivar el binlog mejorado
Parámetro Descripción
aurora_enhanced_binlog Establezca el valor de este parámetro en 0 en el grupo de parámetros del clúster de base de datos asociado al clúster de Aurora MySQL. Al cambiar el valor de este parámetro, debe reiniciar la instancia del escritor cuando el valor DBClusterParameterGroupStatus aparezca como pending-reboot.
binlog_backup Desactive este parámetro cuando desactive el binlog mejorado. Para ello, establezca el valor de este parámetro en 1.
binlog_replication_globaldb Desactive este parámetro cuando desactive el binlog mejorado. Para ello, establezca el valor de este parámetro en 1.

Para comprobar si el binlog mejorado está activado, utilice el siguiente comando en el cliente MySQL:

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)

Cuando el binlog mejorado está activado, el resultado muestra ACTIVE para aurora_enhanced_binlog.

Otros parámetros relacionados

Al activar el binlog mejorado, se ven afectados los siguientes parámetros:

  • El parámetro max_binlog_size está visible pero no se puede modificar. El valor predeterminado 134217728 se ajusta automáticamente a 268435456 cuando se activa el binlog mejorado.

  • A diferencia del binlog comunitario de MySQL, binlog_checksum no actúa como parámetro dinámico cuando el binlog mejorado está activado. Para que el cambio en este parámetro surta efecto, debe reiniciar manualmente el clúster de base de datos incluso cuando ApplyMethod esté en immediate.

  • El valor que establezca en el parámetro binlog_order_commits no afecta al orden de las confirmaciones cuando el binlog mejorado está activado. Las confirmaciones siempre se ordenan sin afectar al rendimiento.

Diferencias entre el binlog mejorado y el binlog comunitario de MySQL

El binlog mejorado interactúa de manera diferente con los clones, las copias de seguridad y la base de datos global de Aurora en comparación con el binlog comunitario de MySQL. Recomendamos que entienda las siguientes diferencias antes de usar el binlog mejorado.

  • Los archivos binlog mejorados del clúster de base de datos de origen no están disponibles en un clúster de base de datos clonado.

  • Los archivos binlog mejorados no se incluyen en las copias de seguridad de Aurora. Por lo tanto, los archivos binlog mejorados del clúster de base de datos de origen no están disponibles después de restaurar un clúster de base de datos, a pesar del período de retención establecido en él.

  • Cuando se usan con una base de datos global de Aurora, los archivos binlog mejorados del clúster de base de datos principal no se replican en el clúster de base de datos de las regiones secundarias.

Ejemplos

En los siguientes ejemplos, se muestra la diferencia entre el binlog mejorado y el binlog comunitario de MySQL.

En un clúster de base de datos restaurado o clonado

Cuando el binlog mejorado está activado, los archivos binlog históricos no están disponibles en el clúster de base de datos restaurado o clonado. Tras una operación de restauración o clonación, si el binlog está activado, el nuevo clúster de base de datos comienza a escribir su propia secuencia de archivos binlog, empezando por 1 (mysql-bin-changelog.000001).

Para activar el binlog mejorado después de una operación de restauración o clonación, defina los parámetros del clúster de base de datos requeridos en el clúster de base de datos restaurado o clonado. Para obtener más información, consulte Configuración de los parámetros del binlog mejorado.

ejemplo Operación de clonación o restauración que se realiza cuando el binlog mejorado está activado

Clúster de base de datos de origen:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

En un clúster de base de datos restaurado o clonado, no se realizan copias de seguridad de los archivos binlog cuando se activa el binlog mejorado. Para evitar la discontinuidad en los datos del binlog, tampoco están disponibles los archivos binlog escritos antes de activar el binlog mejorado. 

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
ejemplo Operación de clonación o restauración que se realiza cuando el binlog mejorado está desactivado

Clúster de base de datos de origen:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

En un clúster de base de datos restaurado o clonado, los archivos binlog escritos están disponibles después de desactivar el binlog mejorado.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)

En una base de datos global de Amazon Aurora

En una base de datos global de Amazon Aurora, los datos binlog del clúster de base de datos principal no se replican en los clústeres de base de datos secundarios. Tras un proceso de conmutación por error entre regiones, los datos del binlog no están disponibles en el clúster de base de datos principal promocionado recientemente. Si el binlog está activado, el clúster de base de datos promocionado recientemente comienza a escribir su propia secuencia de archivos binlog, empezando por 1 (mysql-bin-changelog.000001).

Para activar el binlog mejorado después de la conmutación por error, debe configurar los parámetros del clúster de base de datos requeridos en el clúster de base de datos secundario. Para obtener más información, consulte Configuración de los parámetros del binlog mejorado.

ejemplo La operación de conmutación por error de la base de datos global se realiza cuando el binlog mejorado está activado

Clúster de base de datos principal antiguo (antes de la conmutación por error):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Nuevo clúster de base de datos principal (después de la conmutación por error):

Los archivos binlog no se replican en regiones secundarias cuando se activa el binlog mejorado. Para evitar la discontinuidad en los datos del binlog, los archivos binlog escritos antes de activar el binlog mejorado no estarán disponibles.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
ejemplo La operación de conmutación por error de la base de datos global se realiza cuando el binlog mejorado está activado

Clúster de base de datos de origen:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Clúster de base de datos restaurado o clonado:

Los archivos binlog que se escriben después de desactivar el binlog mejorado se replican y están disponibles en el clúster de base de datos promocionado recientemente.

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)

Métricas de Amazon CloudWatch para un binlog mejorado

Las siguientes métricas de Amazon CloudWatch solo se publican cuando el binlog mejorado está activado.

Métrica de CloudWatch Descripción Unidades
ChangeLogBytesUsed Es la cantidad de almacenamiento utilizada por el binlog mejorado. Bytes
ChangeLogReadIOPs Es el número de operaciones de E/S de lectura realizadas en el binlog mejorado en un intervalo de 5 minutos. Recuento cada 5 minutos
ChangeLogWriteIOPs Es el número de operaciones de E/S de escritura en disco realizadas en el binlog mejorado en un intervalo de 5 minutos. Recuento cada 5 minutos

Limitaciones del binlog mejorado

Las siguientes limitaciones se aplican a los clústeres de base de datos de Amazon Aurora cuando se activa el binlog mejorado.

  • El binlog mejorado solo es compatible en la versión 3.03.1 de Aurora MySQL y versiones posteriores.

  • Los archivos binlog mejorados escritos en el clúster de base de datos principal no se copian en los clústeres de base de datos clonados o restaurados.

  • Cuando se usan con una base de datos global de Amazon Aurora, los archivos binlog mejorados del clúster de base de datos principal no se replican en los clústeres de base de datos secundarios. Por lo tanto, tras el proceso de conmutación por error, los datos históricos del binlog no estarán disponibles en el nuevo clúster de base de datos principal.

  • Se ignoran los siguientes parámetros de configuración del binlog:

    • binlog_group_commit_sync_delay

    • binlog_group_commit_sync_no_delay_count

    • binlog_max_flush_queue_time

  • No puede eliminar ni cambiar el nombre de una tabla dañada de una base de datos. Para eliminar estas tablas, puede ponerse en contacto con AWS Support.

  • La caché de E/S del binlog se deshabilita cuando se activa el binlog mejorado. Para obtener más información, consulte Optimización de replicación de registros binarios.

    nota

    El binlog mejorado proporciona mejoras en el rendimiento de lectura similares a las de la caché de E/S del binlog y aún más mejoras en el rendimiento de escritura.

  • No se admite la característica Backtrack. El binlog mejorado no se puede activar en un clúster de base de datos bajo las siguientes condiciones:

    • Clúster de base de datos con la característica Backtrack activada actualmente.

    • Clúster de base de datos con la característica Backtrack activada previamente, pero ahora deshabilitada.

    • Clúster de base de datos restaurado desde un clúster de base de datos de origen o una instantánea con la característica Backtrack habilitada.