# Configuración de la replicación de registros binarios para Aurora MySQL
<a name="AuroraMySQL.Replication.MySQL.SettingUp"></a>

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
<a name="AuroraMySQL.Replication.MySQL.EnableBinlog"></a>

 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
<a name="AuroraMySQL.Replication.MySQL.RetainBinlogs"></a>

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: <pre>CALL mysql.rds_set_configuration('binlog retention hours', 144);</pre> 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
<a name="AuroraMySQL.Replication.MySQL.CreateSnapshot"></a>

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)
<a name="AuroraMySQL.Replication.MySQL.LoadSnapshot"></a>

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
<a name="AuroraMySQL.Replication.MySQL.CreateReplUser"></a>

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
<a name="AuroraMySQL.Replication.MySQL.EnableReplication"></a>

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
<a name="AuroraMySQL.Replication.StartReplicationUntil"></a>

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
<a name="AuroraMySQL.Replication.MySQL.Monitor"></a>

 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
<a name="AuroraMySQL.Replication.passwords"></a>

 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.