engine=innodb, algorithm=copy;
```
En las siguientes secciones, configure la replicación, detenga la replicación, escale las lecturas de su base de datos, optimice la replicación binlog y configure el binlog mejorado.
**Topics**
+ [Configuración de la replicación de registros binarios para Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Detención de la replicación de registros binarios para Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Escalado de lecturas para su base de datos MySQL con Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md)
+ [Optimización de la replicación de registros binarios para Aurora MySQL](binlog-optimization.md)
+ [Configuración del binlog mejorado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md)
# Configuración de la replicación de registros binarios para Aurora MySQL
La configuración de la replicación de MySQL con Aurora MySQL incluye los siguientes pasos, que se describen en detalle:
**Contents**
+ [1. Activar el registro binario en el origen de replicación](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. Retenga los registros binarios en el origen de replicación hasta que dejen de ser necesarios](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. Creación de una copia o un volcado del origen de replicación](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. Carga del volcado en el destino de la réplica (si fuera necesario)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. Cree un usuario de replicación en su origen de replicación](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. Active la replicación en el destino de la réplica](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [Establecimiento de una ubicación para detener la replicación en una réplica de lectura](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. Monitoree su réplica](#AuroraMySQL.Replication.MySQL.Monitor)
+ [Sincronización de contraseñas entre el origen de replicación y el destino](#AuroraMySQL.Replication.passwords)
## 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.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para activar el registro binario en un clúster de base de datos Aurora MySQL** Establezca el parámetro del clúster de base de datos `binlog_format` en `ROW`, `STATEMENT` o `MIXED`. Se recomienda usar `MIXED` a menos que se requiera un formato de binlog específico. (El valor predeterminado es `OFF`). Para cambiar el parámetro `binlog_format`, cree un grupo de parámetros de clúster de base de datos personalizado y asócielo a su clúster de base de datos. No puede cambiar los parámetros de un grupo de parámetros de clúster de base de datos predeterminado. Si va a cambiar el parámetro `binlog_format` de `OFF` a otro valor, reinicie el clúster de base de datos de Aurora para que el cambio se aplique. Para obtener más información, consulte [Parámetros del clúster de base de datos de Amazon Aurora y de instancia de base de datos](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) y [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). |
| RDS for MySQL | **Para activar el registro binario en una instancia de base de datos de Amazon RDS** No puede activar el registro binario directamente para una instancia de base de datos de Amazon RDS, pero puede activarlo por medio de uno de los siguientes procedimientos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externo) | **Para configurar la replicación cifrada** Para replicar los datos de forma segura con la versión 2 de Aurora MySQL, puede usar la replicación cifrada. Si no necesita usar la replicación cifrada, puede omitir estos pasos. A continuación, se indican los requisitos previos para utilizar la replicación cifrada: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Durante la replicación cifrada, el clúster de base de datos Aurora MySQL actúa como un cliente en el servidor de base de datos MySQL. Los certificados y las claves del cliente de Aurora MySQL son archivos con formato .pem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Para activar el registro binario en una base de datos MySQL externa** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para conservar registros binarios en un clúster de base de datos Aurora MySQL** No tiene acceso a los archivos binlog de un clúster de base de datos de Aurora MySQL. Como resultado, debe elegir un plazo para retener los archivos binlog en el origen de replicación que sea lo suficientemente largo para garantizar que los cambios se han aplicado a la réplica antes de que Amazon RDS elimine el archivo binlog. Puede conservar los archivos binlog en un clúster de base de datos Aurora MySQL durante un máximo de 90 días. Si desea configurar una replicación con una base de datos MySQL o una instancia de base de datos de RDS para MySQL como réplica y la base de datos para la que va a crear una réplica es muy grande, elija un periodo más largo para retener los archivos binlog hasta que la copia inicial de la base de datos en la réplica se haya completado y el retardo de la réplica haya llegado a 0. Para definir el periodo de retención del registro binario, use el procedimiento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) y especifique un parámetro de configuración de `'binlog retention hours'` junto con el número de horas para retener los archivos binlog en el clúster de base de datos. El valor máximo para las versiones 2.11.0 y superiores y 3 de Aurora MySQL es 2160 (90 días). El ejemplo siguiente establece el periodo de retención de los archivos binlog a 6 días: CALL mysql.rds_set_configuration('binlog retention hours', 144); Una vez que haya comenzado la replicación, puede verificar que los cambios se hayan aplicado a la réplica ejecutando el comando `SHOW SLAVE STATUS` (versión 2 de Aurora MySQL) o `SHOW REPLICA STATUS` (versión 3 de Aurora MySQL) en la réplica y verificando el campo `Seconds behind master`. Si el campo `Seconds behind master` es 0, entonces no hay retardo de réplica. Cuando no haya retardo de réplica, reduzca el periodo de tiempo durante el que se deben retener los archivos binlog definiendo el parámetro de configuración `binlog retention hours` en un periodo más corto. Si no se especifica esta configuración, el valor predeterminado para Aurora MySQL es 24 (1 día). Si especifica un valor para `'binlog retention hours'` que sea mayor que el máximo, Aurora MySQL utiliza el máximo. |
| RDS for MySQL | **Para conservar los registros binarios en una instancia de base de datos de Amazon RDS** Puede retener los archivos de registro binario en una instancia de base de datos de Amazon RDS mediante el establecimiento de las horas de retención de archivos binlog, como en el caso de un clúster de base de datos Aurora MySQL, tal como se ha descrito en la fila anterior. También puede retener los archivos binlog en una instancia de base de datos de Amazon RDS creando una réplica de lectura para la instancia de base de datos. Esta réplica de lectura es temporal y solo se usa para conservar los archivos binlog. Una vez creada la réplica de lectura, llame al procedimiento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) en la réplica de lectura. Mientras la replicación está detenida, Amazon RDS no elimina ninguno de los archivos binlog del origen de replicación. Una vez que haya configurado la reproducción con la réplica permanente, puede eliminar la réplica de lectura cuando el retardo de la réplica (campo `Seconds behind master`) entre el origen de reproducción y la réplica permanente llegue a 0. |
| MySQL (externo) | **Para conservar los registros binarios en una base de datos MySQL externa** Como los archivos binlog de una base de datos de MySQL externa no se administran con Amazon RDS, se conservan hasta que se eliminan. Una vez que haya comenzado la replicación, puede verificar que los cambios se hayan aplicado a la réplica ejecutando el comando `SHOW SLAVE STATUS` (versión 2 de Aurora MySQL) o `SHOW REPLICA STATUS` (versión 3 de Aurora MySQL) en la réplica y verificando el campo `Seconds behind master`. Si el campo `Seconds behind master` es 0, entonces no hay retardo de réplica. Cuando no haya retardo de réplica, podrá eliminar los archivos binlog antiguos. |
## 3. Creación de una copia o un volcado del origen de replicación
Debe usar una instantánea, un clon o un volcado del origen de replicación para cargar una copia de línea de base de los datos en la réplica. A continuación, debe empezar a replicar desde ese punto.
Use las siguientes instrucciones para crear una copia o un volcado del origen de la replicación de su motor de base de datos.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para crear una copia de un clúster de base de datos de Aurora MySQL** Utilice uno de los siguientes métodos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Para obtener el nombre y la posición del archivo binlog** Utilice uno de los siguientes métodos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Para crear un volcado de un clúster de base de datos de Aurora MySQL** Si el destino de la réplica es una base de datos de MySQL o una instancia de base de datos de RDS para MySQL, debe crear un archivo de volcado desde un clúster de base de datos de Aurora. Recuerde ejecutar el comando `mysqldump` en la copia del clúster de base de datos de origen que ha creado. Esto es para evitar tener en cuenta los bloqueos a la hora de realizar el volcado. Si el volcado se realizó directamente en el clúster de base de datos de origen, sería necesario bloquear las tablas de origen para evitar escrituras simultáneas en ellas mientras el volcado está en curso. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Para crear una instantánea de una instancia de la base de datos de Amazon RDS** Cree una réplica de lectura para la instancia de base de datos de Amazon RDS. Para obtener más información, consulte [Creación de una réplica de lectura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) en la *Guía del usuario de Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externo) | **Para crear un volcado de una base de datos MySQL externa** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. Carga del volcado en el destino de la réplica (si fuera necesario)
Si va a cargar datos desde un volcado de una base de datos de MySQL que sea externa a Amazon RDS, puede crear una instancia de EC2 para copiar en ella los archivos del volcado. A continuación, puede cargar 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.
**nota**
Si crea un nuevo clúster de base de datos de Aurora MySQL como destino de la réplica, no necesita cargar un archivo de volcado:
Puede restaurar desde una instantánea de clúster de base de datos para crear un nuevo clúster de base de datos. Para obtener más información, consulte [Restauración de una instantánea de clúster de base de datos](aurora-restore-snapshot.md).
Puede clonar el clúster de base de datos de origen para crear un nuevo clúster de base de datos. Para obtener más información, consulte [Clonación de un volumen de clúster de base de datos de Amazon Aurora](Aurora.Managing.Clone.md).
Puede migrar los datos de una instantánea de instancia de base de datos a un nuevo clúster de base de datos. Para obtener más información, consulte [Migración de datos a un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Migrating.md).
Use las siguientes instrucciones para cargar el volcado del origen de replicación en el destino de la réplica para su motor de base de datos.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para cargar un volcado en un clúster de base de datos de Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Para cargar un volcado en una instancia de base de datos Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externo) | **Para cargar un volcado en una base de datos MySQL externa** No puede cargar una instantánea de base de datos o una instantánea de clúster de base de datos en una base de datos MySQL externa. En su lugar, debe usar la salida del comando `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para activar la replicación desde un clúster de base de datos Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Para utilizar el cifrado SSL, establezca el valor final a `1` en vez de `0`. |
| RDS for MySQL | **Para activar la replicación desde una instancia de base de datos de Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Para utilizar el cifrado SSL, establezca el valor final a `1` en vez de `0`. |
| MySQL (externo) | **Para activar la replicación desde una base de datos MySQL externa** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
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\$1reset\$1external\$1master (Aurora MySQL versión 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) o [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 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\$1start\$1replication\$1until(Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 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.
1. Ejecute el procedimiento almacenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
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\$1start\$1replication\$1until\$1gtid(Aurora MySQL versión 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) en lugar del procedimiento almacenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Para obtener más información sobre la replicación basada en GTID, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
## 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](USER_Events.md).
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.
**importante**
Si actualiza el clúster de base de datos y especifica un grupo de parámetros personalizado, asegúrese de reiniciar manualmente el clúster una vez finalizada la actualización. De este modo, el clúster utilizará la nueva configuración de parámetros personalizada y reiniciará la replicación de binlog.
## 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 Consola de administración de AWS, 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.
# Detención de la replicación de registros binarios para Aurora MySQL
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](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. Desactivar el registro binario en el origen de replicación](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 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.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para detener la replicación del registro binario en el destino de la réplica de un clúster de base de datos Aurora MySQL** Conéctese al clúster de base de datos de Aurora que es el destino de la réplica y llame al procedimiento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| RDS for MySQL | **Para detener la replicación de binlog en una instancia de base de datos de Amazon RDS** Conéctese a la instancia de base de datos de RDS que es el destino de la réplica y llame al procedimiento [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| MySQL (externo) | **Para detener la replicación del registro binario en una base de datos MySQL externa** Conéctese a la base de datos MySQL y ejecute el comando `STOP SLAVE` (versión 5.7) o `STOP REPLICA` (versión 8.0). |
## 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.
| Motor de base de datos | Instrucciones |
| --- | --- |
| Aurora MySQL | **Para desactivar el registro binario en un clúster de base de datos Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Para desactivar el registro binario en una instancia de base de datos de Amazon RDS** No puede desactivar el registro binario directamente para una instancia de base de datos de Amazon RDS, pero puede desactivarlo por medio de los siguientes procedimientos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (externo) | **Para desactivar el registro binario en una base de datos MySQL externa** Conéctese a la base de datos de MySQL y llame al comando `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Escalado de lecturas para su base de datos MySQL con Amazon Aurora
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](Aurora.CreateInstance.md).
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](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
**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\$1set\$1external\$1master (Aurora MySQL versión 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master), [mysql.rds\$1set\$1external\$1source (Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) y [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#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;
```
1. 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
------------------------------------
```
1. 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, es posible que quiera usar el procedimiento de [Importación de datos a una base de datos de Amazon RDS para MySQL con tiempo de inactividad reducido](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) en la *Guía del usuario de Amazon Relational Database Service*.
Para Linux, macOS o Unix:
```
mysqldump \
--databases \
--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
```
Para Windows:
```
mysqldump ^
--databases ^
--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.
1. 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 [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) en la documentación de MySQL.
1. 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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 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.
1. 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'@'example.com' IDENTIFIED BY 'password';
```
1. 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'@'example.com'
IDENTIFIED BY 'password';
```
1. 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.
1. 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 origen de replicación usando los procedimientos [mysql.rds\$1set\$1external\$1master (Aurora MySQL versión 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (Aurora MySQL versión 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) y [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication).
Use la posición y el nombre del archivo binlog 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.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. En el clúster de base de datos de Amazon Aurora, ejecute el procedimiento [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#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](aurora-replicas-adding.md).
# Optimización de la replicación de registros binarios para Aurora MySQL
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](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) 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 el subproceso coordinador. Los eventos de registros binarios se aplican en paralelo cuando es posible. El nivel de paralelismo depende de factores como la versión, los parámetros, el diseño del esquema y las características de la carga de trabajo.
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. Para que una réplica multiproceso procese de forma eficiente los eventos binlog en paralelo, debe configurar el origen para la replicación de registro binario multiproceso y el origen debe utilizar una versión que incluya la información de paralelismo en los archivos de registro binarios.
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 `1` en el grupo de parámetros personalizados.
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.
Para aumentar la resiliencia de la base de datos frente a paradas inesperadas, le recomendamos que habilite la replicación de GTID en el origen y permita GTID en la réplica. Para permitir la replicación de GTID, establezca `gtid_mode` en `ON_PERMISSIVE` tanto en el origen como en la réplica. Para obtener más información sobre la replicación basada en GTID, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
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](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) en el *Manual de referencia de MySQL*. Para obtener más información sobre la replicación multiproceso, consulte el blog de MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/).
Los valores óptimos de los parámetros dependen 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_format recommended value` – se establece como `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking`: el valor recomendado es `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type`: el valor recomendado es `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction`: el valor recomendado es `XXHASH64`
El esquema y las características de la carga de trabajo son factores que afectan la replicación en paralelo. Los factores más comunes son los siguientes.
+ Ausencia de claves principales: RDS no puede establecer la dependencia de conjunto de escrituras para tablas sin claves principales. Con el formato `ROW`, se puede lograr una sola instrucción de varias filas con un solo escaneo completo de la tabla en el origen, pero da como resultado un análisis completo de la tabla por cada fila modificada en la réplica. La ausencia de claves principales disminuye significativamente el rendimiento de la replicación.
+ Presencia de claves externas: si hay claves externas, Amazon RDS no puede utilizar la dependencia de conjunto de escrituras para el paralelismo de las tablas con la relación FK.
+ Tamaño de las transacciones: si una sola transacción abarca decenas o cientos de megabytes o gigabytes, el subproceso coordinador y uno de los subprocesos de trabajo podrían tardar mucho tiempo en procesar solo esa transacción. Durante ese tiempo, todos los demás hilos de los trabajadores pueden permanecer inactivos después de que concluyan el procesamiento de las transacciones anteriores.
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.
## Optimización de replicación binlog
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 las versiones disponibles actualmente.
Las variables de estado `aurora_binlog_io_cache_reads` y `aurora_binlog_io_cache_read_requests` lo ayudan a supervisar 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.
## Registro de transmisiones en memoria
En Aurora MySQL versión 3.10 y versiones posteriores, Aurora presenta una optimización conocida como registro de transmisiones en memoria para mejorar el rendimiento de la replicación. Esta optimización mejora el rendimiento de E/S de los registros de transmisiones al almacenar en caché todo el contenido de los registros de transmisiones intermedios en la memoria. Como resultado, reduce la latencia de confirmación al minimizar las operaciones de E/S del almacenamiento, ya que el contenido del registro de transmisiones permanece fácilmente accesible en la memoria.
De forma predeterminada, la característica de registro de transmisiones en memoria se habilita automáticamente para los escenarios de replicación administrados por Aurora (incluidas las implementaciones azul/verde, la replicación de Aurora-Aurora y las réplicas entre regiones) cuando la réplica cumple alguna de estas configuraciones:
+ Modo de replicación de un solo subproceso (replica\$1parallel\$1workers = 0)
+ Replicación multiproceso con el modo GTID activado:
+ Posicionamiento automático habilitado
+ El modo GTID está activado en la réplica
+ Replicación basada en archivos con replica\$1preserve\$1commit\$1order = ON
La característica de registro de transmisión en memoria se admite en clases de instancias superiores a t3.large, pero no está disponible en las instancias de Aurora Serverless. El búfer circular del registro de transmisión tiene un tamaño fijo de 128 MB. Para supervisar el consumo de memoria de esta característica, puede ejecutar la siguiente consulta:
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
La característica de registro de transmisión en memoria se controla mediante el parámetro aurora\$1in\$1memory\$1relaylog, que se puede configurar en el clúster o instancia de base de datos. Puede habilitar o desactivar esta característica de forma dinámica sin reiniciar la instancia:
1. Detención de la replicación en curso
1. Establecimiento de aurora\$1in\$1memory\$1relaylog en ON (para habilitar) u OFF (para desactivar) en el grupo de parámetros
1. Reinicio de la replicación
Ejemplo:
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
Incluso cuando aurora\$1in\$1memory\$1relaylog esté ON, es posible que la característica de registro de transmisión en memoria siga desactivada en determinadas condiciones. Para comprobar el estado actual de la característica, puede usar el siguiente comando:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
Si la característica se desactiva de forma inesperada, puede identificar el motivo ejecutando lo siguiente:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
Este comando devuelve un mensaje que explica por qué la característica está desactivada actualmente.
# Configuración del binlog mejorado para Aurora MySQL
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.
**Topics**
+ [Configuración de los parámetros del binlog mejorado](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [Otros parámetros relacionados](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [Diferencias entre el binlog mejorado y el binlog comunitario de MySQL](#AuroraMySQL.Enhanced.binlog.differences)
+ [Métricas de Amazon CloudWatch para un binlog mejorado](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [Limitaciones del binlog mejorado](#AuroraMySQL.Enhanced.binlog.limitations)
## 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, defina los siguientes parámetros:
| Parámetro | Predeterminado/a | Descripción |
| --- | --- | --- |
| binlog\$1format | – | Establezca el parámetro binlog\$1format en el formato de registro binario de su elección para activar el registro mejorado. Asegúrese de que binlog\$1format parameter no esté desactivado. Para obtener más información, consulte [Configuración del registro binario de Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). |
| aurora\$1enhanced\$1binlog | 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\$1backup | 1 | Desactive este parámetro para activar el binlog mejorado. Para ello, establezca el valor de este parámetro en 0. |
| binlog\$1replication\$1globaldb | 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, defina los siguientes parámetros:
| Parámetro | Descripción |
| --- | --- |
| aurora\$1enhanced\$1binlog | 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\$1backup | Desactive este parámetro cuando desactive el binlog mejorado. Para ello, establezca el valor de este parámetro en 1. |
| binlog\$1replication\$1globaldb | 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](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Ejemplo: operación de clonación o restauración 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)
```
**Example Ejemplo: operación de clonación o restauración 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)
```
El binlog mejorado se desactiva después de `mysql-bin-changelog.000003`. 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](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Ejemplo: la operación de conmutación por error de 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)
```
**Example Ejemplo: la operación de conmutación por error de base de datos global 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)
```
**Clúster de base de datos restaurado o clonado:**
El binlog mejorado se desactiva después de `mysql-bin-changelog.000003`. 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 Soporte.
+ 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 la replicación de registros binarios para Aurora MySQL](binlog-optimization.md).
**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.