# Replicación con Amazon Aurora MySQL Las características de reproducción de Aurora MySQL son claves para la alta disponibilidad y el rendimiento de su clúster. Aurora facilita la creación o el cambio de tamaño de clústeres con hasta 15 réplicas de Aurora. Todas las réplicas funcionan desde los mismos datos subyacentes. Si algunas instancias de base de datos se quedan sin conexión, otras permanecen disponibles para continuar procesando consultas o para hacerse cargo como escritor si es necesario. Aurora extiende automáticamente las conexiones de solo lectura en varias instancias de base de datos, lo que ayuda a un clúster de Aurora a admitir cargas de trabajo con uso intensivo de consultas. En los siguientes temas, puede encontrar información sobre cómo funciona la replicación de Aurora MySQL y como ajustar la configuración de replicación para lograr una disponibilidad y un rendimiento óptimos. **Topics** + [Uso de réplicas de Aurora](#AuroraMySQL.Replication.Replicas) + [Opciones de replicación para Amazon Aurora MySQL](#AuroraMySQL.Replication.Options) + [Consideraciones sobre el rendimiento de la replicación de Amazon Aurora MySQL](#AuroraMySQL.Replication.Performance) + [Reinicio sin tiempo de inactividad (ZDR) para Amazon Aurora MySQL](AuroraMySQL.Replication.Availability.md) + [Configuración de filtros de replicación con Aurora MySQL](AuroraMySQL.Replication.Filters.md) + [Monitoreo de replicación de Amazon Aurora MySQL](#AuroraMySQL.Replication.Monitoring) + [Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS](AuroraMySQL.Replication.CrossRegion.md) + [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md) + [Uso de la replicación basada en GTID](mysql-replication-gtid.md) ## Uso de réplicas de Aurora Las réplicas de Aurora son puntos de enlace independientes de un clúster de base de datos Aurora que se utilizan preferentemente para ajustar la escala de las operaciones de lectura e incrementar la disponibilidad. Se puede distribuir un máximo de 15 réplicas de Aurora entre las distintas zonas de disponibilidad que abarca un clúster de bases de datos dentro de una Región de AWS. Aunque el volumen del clúster de base de datos se compone de varias copias de los datos del clúster de base de datos, los datos del volumen de clúster se representan como un único volumen lógico para la instancia principal y para las réplicas de Aurora del clúster de base de datos. Para obtener más información acerca de las réplicas de Aurora, consulte [Réplicas de Aurora](Aurora.Replication.md#Aurora.Replication.Replicas). Las réplicas de Aurora funcionan bien para el escalado de lectura porque están totalmente dedicadas a las operaciones de lectura en el volumen del clúster. Las operaciones de escritura se administran en la instancia principal. Como el volumen del clúster se comparte entre todas las instancias del clúster de base de datos Aurora MySQL, no se requiere trabajo adicional para replicar una copia de los datos para cada réplica de Aurora. En cambio, las réplicas de lectura de MySQL deben volver a reproducir, en un solo subproceso, todas las operaciones de escritura de la instancia de base de datos de origen en su almacén de datos local. Esta limitación puede afectar a la capacidad de las réplicas de lectura de MySQL de admitir grandes volúmenes de tráfico de lectura. Con Aurora MySQL, cuando se elimina una réplica de Aurora, su punto de enlace de instancia se quita inmediatamente y la réplica de Aurora se quita del punto de enlace del lector. Si hay instrucciones que se ejecutan en la réplica de Aurora que se van a eliminar, hay un periodo de gracia de tres minutos. Las instrucciones existentes pueden finalizar correctamente durante el periodo de gracia. Cuando termina dicho periodo, se apaga la réplica de Aurora y se elimina. **importante** Las réplicas de Aurora en Aurora MySQL siempre usan el nivel de aislamiento de transacción predeterminado `REPEATABLE READ` para las operaciones en las tablas de InnoDB. Puede usar el comando `SET TRANSACTION ISOLATION LEVEL` para cambiar el nivel de transacción solo para la instancia principal de un clúster de base de datos Aurora MySQL. Esta restricción evita los bloqueos de nivel de usuario en las réplicas de Aurora y permite escalar las réplicas de Aurora para dar cabida a miles de conexiones de usuario activas manteniendo el retardo de las réplicas en un valor mínimo. **nota** Las instrucciones DDL que se ejecutan en la instancia primaria podrían interrumpir las conexiones de la base de datos en las réplicas de Aurora asociadas. Si una conexión de réplica de Aurora está utilizando activamente un objeto de base de datos, como por ejemplo una tabla, y ese objeto se modifica en la instancia primaria con una declaración DDL, se interrumpe la conexión con la réplica de Aurora. **nota** La región China (Ningxia) no es compatible con réplicas de lectura entre regiones. ## Opciones de replicación para Amazon Aurora MySQL Puede configurar la replicación entre cualquiera de las opciones siguientes: + Dos clústeres de base de datos de Aurora MySQL de diferentes Regiones de AWS mediante la creación de una réplica de lectura entre regiones de un clúster de base de datos de Aurora MySQL. Para obtener más información, consulte [Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS](AuroraMySQL.Replication.CrossRegion.md). + Dos clústeres de base de datos de Aurora MySQL en la misma Región de AWS mediante la utilización de la reproducción del registro binario (binlog) de MySQL. Para obtener más información, consulte [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md). + Una instancia de base de datos de RDS for MySQL como el origen y un clúster de base de datos de Aurora MySQL mediante la creación de una réplica de lectura de Aurora de una instancia de base de datos de RDS for MySQL. Puede utilizar este enfoque para introducir cambios de datos actuales y continuos Aurora MySQL durante la migración a Aurora. Para obtener más información, consulte [Migración de datos desde una instancia de base de datos de RDS para MySQL a un clúster de base de datos de Amazon Aurora MySQL con una réplica de lectura de Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). También puede utilizar este enfoque para aumentar la escalabilidad de las consultas de lectura de sus datos. Para ello, consulta los datos utilizando una o más instancias de base de datos dentro de un clúster Aurora MySQL de solo lectura. Para obtener más información, consulte [Escalado de lecturas para su base de datos MySQL con Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Un clúster de base de datos de Aurora MySQL en una Región de AWS y hasta cinco clústeres de base de datos de Aurora de solo lectura de Aurora MySQL en diferentes regiones, mediante la creación de una base de datos global de Aurora. Puede utilizar una base de datos global Aurora para admitir aplicaciones con presencia mundial. El clúster de base de datos Aurora MySQL principal tiene una instancia de escritor y hasta 15 réplicas Aurora. Los clústeres de base de datos Aurora MySQL secundarios de solo lectura pueden estar formados por hasta 16 réplicas Aurora. Para obtener más información, consulte [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md). **nota** Al reiniciarse la instancia principal de un clúster de base de datos Amazon Aurora también se reinician automáticamente las réplicas de Aurora de ese clúster de base de datos para restablecer un punto de entrada que garantice la coherencia de lectura/escritura en el clúster de base de datos. ## Consideraciones sobre el rendimiento de la replicación de Amazon Aurora MySQL las siguientes características le ayudan a ajustar el rendimiento de la replicación de Aurora MySQL. La característica de compresión de registros de réplica reduce automáticamente en ancho de banda de la red para los mensajes de replicación. Dado que cada mensaje se transmite a todas las réplicas de Aurora, los beneficios son mayores para los clústeres de mayor tamaño. Esta característica implica algo de gasto general de CPU en el nodo escritor para realizar la compresión. Siempre está habilitada en la versión 2 y la versión 3 de Aurora MySQL. La característica de filtrado de binlog reduce automáticamente en ancho de banda de la red para los mensajes de replicación. Puesto que las réplicas de Aurora no usan la información de binlog que se incluye en los mensajes de replicación, esos datos se omiten de los mensajes enviados a esos nodos. En la versión 2 de Aurora MySQL, puede controlar esta característica cambiando el parámetro `aurora_enable_repl_bin_log_filtering`. Este parámetro está activado de forma predeterminada. Dado que la optimización está pensada para ser transparente, podría desactivar este ajuste solo durante el diagnóstico o la resolución de problemas relacionados con la replicación. Por ejemplo, para hacer coincidir el comportamiento de un clúster de Aurora MySQL más antiguo en el que esta característica no estuviera disponible. El filtrado de binlog siempre está habilitado en la versión 3 de Aurora MySQL. # Reinicio sin tiempo de inactividad (ZDR) para Amazon Aurora MySQL La característica de reinicio sin tiempo de inactividad (ZDR) puede conservar algunas o todas las conexiones activas a instancias de base de datos durante ciertos tipos de reinicios. El ZDR se aplica a los reinicios que Aurora realiza de forma automática para resolver las condiciones de error, por ejemplo, cuando una réplica comienza a retrasarse demasiado respecto al origen. **importante** El mecanismo de ZDR funciona sobre la base del mejor esfuerzo. Las versiones de Aurora MySQL, las clases de instancias, las condiciones de error, las operaciones SQL compatibles y otros factores que determinan dónde se aplica el ZDR están sujetos a cambios en cualquier momento. El ZDR para 2.x de Aurora MySQL requiere la versión 2.10 y posteriores. ZDR está disponible en todas las versiones secundarias de Aurora MySQL 3.x. En Aurora MySQL versión 2 y 3, el mecanismo de ZDR está activado de forma predeterminada y Aurora no utiliza el parámetro `aurora_enable_zdr`. Aurora informa en la página **Events (Eventos)** las actividades relacionadas con el reinicio del tiempo de inactividad cero. Aurora registra un evento cuando intenta reiniciar mediante el mecanismo ZDR. En este evento se indica por qué Aurora realiza el reinicio. Luego, Aurora registra otro evento cuando finaliza el reinicio. En este último evento se informa cuánto tiempo tardó el proceso y cuántas conexiones se han conservado o eliminado durante el reinicio. Puede consultar el registro de errores de la base de datos para ver más detalles sobre lo que ocurrió durante el reinicio. Aunque las conexiones permanecen intactas tras una operación de ZDR correcta, se reinicializan algunas variables y características. Los siguientes tipos de información no se conservan durante un reinicio causado por un reinicio sin tiempo de inactividad: + Variables globales Aurora restaura las variables de sesión, pero no restaura las variables globales después del reinicio. + Variables de estado. En particular, se restablece el valor de tiempo de actividad que informa el estado del motor. + `LAST_INSERT_ID`. + Estado `auto_increment` en memoria para tablas. El estado de incremento automático en memoria se reinicializa. Para obtener más información sobre los valores de incremento automático, consulte el [Manual de referencia de MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization). + Información de diagnóstico de las tablas `INFORMATION_SCHEMA` y `PERFORMANCE_SCHEMA`. Esta información de diagnóstico también aparece en la salida de comandos como `SHOW PROFILE` y `SHOW PROFILES`. En la tabla siguiente se muestran las versiones, los roles de instancia y otras circunstancias que determinan si Aurora puede utilizar el mecanismo de ZDR al reiniciar instancias de base de datos en el clúster. | Aurora MySQL version | ¿Se aplica el ZDR al escritor? | ¿Se aplica el ZDR a los lectores? | ¿El ZDR siempre está activado? | Notas | | --- | --- | --- | --- | --- | | 2.x, inferior a la 2.10.0 | No | No | N/A | El ZDR no está disponible para estas versiones. | | 2.10.0—2.11.0 | Sí | Sí | Sí | Aurora revierte cualquier transacción que esté en curso en las conexiones activas. La aplicación debe volver a intentar las transacciones. Aurora cancela cualquier conexión que utilice TLS/SSL, tablas temporales, bloqueos de tablas o bloqueos de usuario. | | 2.11.1 y versiones posteriores | Sí | Sí | Sí | Aurora revierte cualquier transacción que esté en curso en las conexiones activas. La aplicación debe volver a intentar las transacciones. Aurora cancela cualquier conexión que utilice tablas temporales, bloqueos de tablas o bloqueos de usuario. | | 3.01—3.03 | Sí | Sí | Sí | Aurora revierte cualquier transacción que esté en curso en las conexiones activas. La aplicación debe volver a intentar las transacciones. Aurora cancela cualquier conexión que utilice TLS/SSL, tablas temporales, bloqueos de tablas o bloqueos de usuario. | | 3.04 y versiones posteriores | Sí | Sí | Sí | Aurora revierte cualquier transacción que esté en curso en las conexiones activas. La aplicación debe volver a intentar las transacciones. Aurora cancela cualquier conexión que utilice tablas temporales, bloqueos de tablas o bloqueos de usuario. | # Configuración de filtros de replicación con Aurora MySQL Puede utilizar filtros de replicación para especificar qué bases de datos y tablas se replican con una réplica de lectura. Los filtros de replicación pueden incluir bases de datos y tablas en la replicación o excluirlas de la replicación. Los siguientes son algunos casos de uso para filtros de replicación: + Para reducir el tamaño de una réplica de lectura. Con el filtrado de replicación, puede excluir las bases de datos y las tablas que no son necesarias en la réplica de lectura. + Para excluir bases de datos y tablas de réplicas de lectura por razones de seguridad. + Para replicar diferentes bases de datos y tablas para casos de uso específicos en diferentes réplicas de lectura. Por ejemplo, puede utilizar réplicas de lectura específicas para análisis o fragmentación. + Con un clúster de base de datos que tiene réplicas de lectura en diferentes Regiones de AWS, para replicar diferentes bases de datos o tablas en diferentes Regiones de AWS. + Para especificar qué bases de datos y tablas se replican con un clúster de base de datos de Aurora MySQL que está configurado como una réplica en una topología de replicación entrante. Para obtener más información acerca de esta configuración, consulte [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md). **Topics** + [Configuración de parámetros de filtrado de replicación para Aurora MySQL](#AuroraMySQL.Replication.Filters.Configuring) + [Limitaciones del filtrado de replicación para Aurora MySQL](#AuroraMySQL.Replication.Filters.Limitations) + [Ejemplos de filtrado de replicación para Aurora MySQL](#AuroraMySQL.Replication.Filters.Examples) + [Visualización de los filtros de replicación para una réplica de lectura](#AuroraMySQL.Replication.Filters.Viewing) ## Configuración de parámetros de filtrado de replicación para Aurora MySQL Para configurar filtros de replicación, establezca los siguientes parámetros: + `binlog-do-db`: replicar los cambios en los registros binarios especificados. Cuando se establece este parámetro para un clúster de origen de binlog, solo se replican los registros binarios especificados en el parámetro. + `binlog-ignore-db`: no replicar los cambios en los registros binarios especificados. Cuando el parámetro `binlog-do-db` se establece para un clúster de origen de binlog, este parámetro no se evalúa. + `replicate-do-db` – Replicar los cambios en las bases de datos especificadas. Cuando se establece este parámetro para un clúster de réplicas de binlog, solo se replican las bases de datos especificadas en el parámetro. + `replicate-ignore-db` – No replicar los cambios en las bases de datos especificadas. Cuando el parámetro `replicate-do-db` se establece para un clúster de réplicas de binlog, este parámetro no se evalúa. + `replicate-do-table` – Replicar los cambios en las tablas especificadas. Cuando se establece este parámetro para una réplica de lectura, solo se replican las tablas especificadas en el parámetro. Además, cuando se establece el parámetro `replicate-do-db` o `replicate-ignore-db`, asegúrese de incluir la base de datos que incluye las tablas especificadas en la replicación con el clúster de réplicas de binlog. + `replicate-ignore-table` – No replicar los cambios en las tablas especificadas. Cuando el parámetro `replicate-do-table` se establece para un clúster de réplicas de binlog, este parámetro no se evalúa. + `replicate-wild-do-table` – Replicar tablas en función de la base de datos y los patrones de nombre de tabla especificados. Se admiten los caracteres comodín `%` y `_`. Cuando se establece el parámetro `replicate-do-db` o `replicate-ignore-db`, asegúrese de incluir la base de datos que incluye las tablas especificadas en la replicación con el clúster de réplicas de binlog. + `replicate-wild-ignore-table` – No replicar tablas en función de la base de datos y los patrones de nombre de tabla especificados. Se admiten los caracteres comodín `%` y `_`. Cuando los parámetros `replicate-do-table` o `replicate-wild-do-table` se establece para un clúster de réplica binlog, este parámetro no se evalúa. Los parámetros se evalúan en el orden en que se enumeran. Para obtener más información sobre cómo funcionan estos parámetros, consulte la documentación de MySQL. + Para obtener información general, consulte [Opciones y variables del servidor de réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Para obtener información acerca de cómo se evalúan los parámetros de filtrado de replicación de bases de datos, consulte [Evaluación de opciones de registros binarios y replicación a nivel de base de datos](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Para obtener información acerca de cómo se evalúan los parámetros de filtrado de replicación de tablas, consulte [Evaluación de las opciones de replicación a nivel de tabla](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Por defecto, cada uno de estos parámetros tiene un valor vacío. En cada clúster de binlog, puede utilizar estos parámetros para establecer, cambiar y eliminar los filtros de replicación. Cuando establezca uno de estos parámetros, separe cada filtro de los demás con una coma. Puede utilizar los caracteres comodín `%` y `_` en los parámetros `replicate-wild-do-table` y `replicate-wild-ignore-table`. El comodín `%` coincide con cualquier número de caracteres y el comodín `_` solo coincide con un carácter. El formato de registro binario de la instancia de base de datos de origen es importante para la replicación, ya que determina el registro de los cambios en los datos. La configuración del parámetro `binlog_format` determina si la replicación está basada en filas o en instrucciones. Para obtener más información, consulte [Configuración del registro binario de Aurora MySQL para bases de datos Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **nota** Todas las instrucciones de lenguaje de definición de datos (DDL) se replican como instrucciones, independientemente de la configuración de `binlog_format` en la instancia de base de datos de origen. ## Limitaciones del filtrado de replicación para Aurora MySQL Las siguientes limitaciones se aplican al filtrado de replicación para Aurora MySQL: + Los filtros de replicación solo son compatibles con Aurora MySQL versión 3. + Cada parámetro de filtrado de replicación tiene un límite de 2000 caracteres. + Las comas no son compatibles con los filtros de replicación. + El filtrado de replicación no es compatible con transacciones XA. Para obtener más información, consulte [Restricciones a las transacciones XA ](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) en la documentación de MySQL. ## Ejemplos de filtrado de replicación para Aurora MySQL Para configurar el filtrado de replicación para una réplica de lectura, modifique los parámetros de filtrado de replicación en el grupo de parámetros del clúster de base de datos asociado a la réplica de lectura. **nota** No puede modificar un grupo de parámetros de clúster de base de datos predeterminado. Si la réplica de lectura emplea un grupo de parámetros predeterminado, cree un nuevo grupo de parámetros y asócielo con la réplica de lectura. Para obtener más información acerca de los grupos de parámetros de clústeres de base de datos, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Puede establecer parámetros en un grupo de parámetros de clústeres de base de datos mediante la Consola de administración de AWS, la AWS CLI o la API de RDS. Para obtener información acerca de cómo configurar los parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). Cuando se establecen parámetros en un grupo de parámetros de clústeres de base de datos, todos los clústeres de base de datos asociados al grupo de parámetros utilizan la configuración de los parámetros. Si establece los parámetros de filtrado de replicación en un grupo de parámetros de clústeres de base de datos, asegúrese de que el grupo de parámetros está asociado solo con clústeres de réplicas de lectura. Deje los parámetros de filtrado de replicación vacíos para las instancias de base de datos de origen En los siguientes ejemplos se establecen los parámetros mediante el uso de AWS CLI. Estos ejemplos establecen `ApplyMethod` en `immediate` para que los cambios de los parámetros se produzcan inmediatamente después de que se complete el comando de la CLI. Si desea que se aplique un cambio pendiente después de reiniciar la réplica de lectura, establezca `ApplyMethod` en `pending-reboot`. Los siguientes ejemplos establecen filtros de replicación: + [Including databases in replication](#rep-filter-in-dbs-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **Example Inclusión de bases de datos en la replicación** En el ejemplo siguiente se incluyen las bases de datos `mydb1` y `mydb2` en la replicación. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example Inclusión de tablas en la replicación** En el siguiente ejemplo se incluyen las tablas `table1` y `table2` en la base de datos `mydb1` en la replicación. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` **Example Inclusión de tablas en la replicación mediante el uso de caracteres comodín** En el ejemplo siguiente se incluyen tablas con nombres que empiezan con `order` y `return` en la base de datos `mydb` en la replicación. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Exclusión de bases de datos de la replicación** En el siguiente ejemplo se excluyen las bases de datos `mydb5` y `mydb6` de la replicación. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate" ``` **Example Exclusión de tablas de la replicación** En el siguiente ejemplo, se excluyen de la replicación las tablas `table1` en la base de datos `mydb5` y `table2` en la base de datos `mydb6`. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Exclusión de tablas de la replicación mediante el uso de caracteres comodín** En el siguiente ejemplo se excluyen las tablas con nombres que empiezan con `order` y `return` en la base de datos `mydb7` de la replicación. Para Linux, macOS o:Unix ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` En:Windows ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` ## Visualización de los filtros de replicación para una réplica de lectura Puede ver los filtros de replicación para una réplica de lectura de las siguientes maneras: + Verifique la configuración de los parámetros de filtrado de replicación en el grupo de parámetros asociado a la réplica de lectura. Para obtener instrucciones, consulte [Visualización de los valores de parámetros de un grupo de parámetros de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.Viewing.md). + En un cliente de MySQL, conéctese a la réplica de lectura y ejecute la instrucción `SHOW REPLICA STATUS`. En la salida, los siguientes campos muestran los filtros de replicación para la réplica de lectura: + `Binlog_Do_DB` + `Binlog_Ignore_DB` + `Replicate_Do_DB` + `Replicate_Ignore_DB` + `Replicate_Do_Table` + `Replicate_Ignore_Table` + `Replicate_Wild_Do_Table` + `Replicate_Wild_Ignore_Table` Para obtener más información acerca de estos campos, consulte [Comprobación del estado de replicación](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) en la documentación de MySQL. ## Monitoreo de replicación de Amazon Aurora MySQL El escalado de lectura y la alta disponibilidad dependen de un tiempo de retardo mínimo. Puede monitorizar el retardo de una réplica de Aurora con respecto a la instancia principal del clúster de base de datos de Aurora MySQL mediante la monitorización de la métrica `AuroraReplicaLag` de Amazon CloudWatch. La métrica `AuroraReplicaLag` se registra en cada réplica de Aurora. La instancia de base de datos principal también registra las métricas `AuroraReplicaLagMaximum`, `AuroraReplicaLagMinimum` y Amazon CloudWatch. La métrica `AuroraReplicaLagMaximum` registra la cantidad máxima de retraso entre la instancia de base de datos principal y cada réplica de Aurora en el clúster de base de datos. La métrica `AuroraReplicaLagMinimum` registra la cantidad mínima de retraso entre la instancia de base de datos principal y cada réplica de Aurora en el clúster de base de datos. Si necesita el valor más actualizado del retardo de réplica de Aurora, puede comprobar la métrica de `AuroraReplicaLag` en Amazon CloudWatch. El retraso de réplica de Aurora también se registra en cada réplica de Aurora del clúster de base de datos de Aurora MySQL en la tabla `information_schema.replica_host_status`. Para obtener más información sobre esta tabla, consulte [information\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Para obtener más información acerca de la monitorización de instancias de RDS y de las métricas de CloudWatch, consulte [Supervisión de métricas en un clúster de Amazon Aurora](MonitoringAurora.md). # Reproducción de clústeres de base de datos de Amazon Aurora MySQL entre Regiones de AWS Puede crear un clúster de base de datos de Amazon Aurora MySQL como réplica de lectura en una Región de AWS distinta a la del clúster de base de datos de origen. Utilizar este método puede mejorar las capacidades de recuperación de desastres, permitirle escalar las operaciones de lectura en una Región de AWS que esté más cerca de sus usuarios y facilitar la migración de una Región de AWS a otra. Puede crear réplicas de lectura de clústeres de base de datos cifrados y sin cifrar. La réplica de lectura se debe cifrar si el clúster de base de datos de origen está cifrado. Por cada clúster de base de datos origen, puede tener hasta cinco clústeres de base de datos réplica de lectura entre regiones. **nota** Como alternativa a las réplicas de lectura entre regiones, puede escalar las operaciones de lectura con un retraso mínimo mediante una base de datos global Aurora. Una base de datos global de Aurora tiene un clúster de base de datos primaria de Aurora en una Región de AWS y hasta 10 clústeres de base de datos secundaria de solo lectura en diferentes regiones. Cada clúster de base de datos secundario puede incluir hasta 16 réplicas Aurora (en lugar de 15). La replicación desde el clúster de base de datos principal a todos los secundarios es manejada por la capa de almacenamiento Aurora en lugar del motor de base de datos, por lo que el tiempo de demora para replicar cambios suele ser mínimo, menos de 1 segundo. Mantener el motor de base de datos fuera del proceso de replicación significa que el motor de base de datos está dedicado al procesamiento de cargas de trabajo. También significa que no necesita configurar o administrar la replicación de binlog (registro binario) de Aurora MySQL. Para obtener más información, consulte [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md). Cuando se crea una réplica de lectura del clúster de base de datos de Aurora MySQL en otra Región de AWS, se debe tener en cuenta lo siguiente: + Tanto el clúster de base de datos origen como el clúster de base de datos réplica de lectura entre regiones pueden tener un máximo de 15 réplicas de Aurora junto con la instancia principal del clúster de base de datos. Usando esta funcionalidad, puede escalar las operaciones de lectura tanto para la Región de AWS de origen como para la Región de AWS de destino de la replicación. + En una situación con varias regiones, hay más tiempo de retardo entre el clúster de base de datos de origen y la réplica de lectura porque los canales de red entre Regiones de AWS son más largos. + Los datos transferidos en las replicaciones entre regiones conllevan cargos por transferencia de datos de Amazon RDS. Las siguientes acciones de replicación entre regiones generan cargos para los datos transferidos fuera de la Región de AWS de origen: + Cuando se crea la réplica de lectura, Amazon RDS realiza una instantánea del clúster de origen y transfiere la instantánea a la Región de AWS que contiene la réplica de lectura. + Para cada modificación de datos realizada en las bases de datos de origen, Amazon RDS transfiere los datos de la región de origen a la Región de AWS que contiene la réplica de lectura. Para obtener más información acerca de los precios de las transferencias de datos de Amazon RDS, consulte [Precios de Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/). + Puede ejecutar varias acciones de creación o eliminación simultáneas para réplicas de lectura que hagan referencia al mismo clúster de base de datos origen. Sin embargo, debe permanecer dentro del límite de cinco réplicas de lectura por cada clúster de base de datos de origen. + Para que la replicación sea eficaz, cada réplica de lectura debe tener la misma cantidad de recursos de computación y de almacenamiento que el clúster de base de datos origen. Si modifica la escala del clúster de base de datos origen, debe ajustar también la escala de las réplicas de lectura. **Topics** + [Antes de empezar](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [Creación de un clúster de base de datos de réplica de lectura entre regiones para Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Creating.md) + [Promoción de una réplica de lectura a un clúster de base de datos para Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Promote.md) + [Resolución de problemas de réplicas entre regiones para Amazon Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Antes de empezar Antes de crear un clúster de base de datos de Aurora MySQL que sea una réplica de lectura entre regiones, debe activar el registro binario en el clúster de base de datos de Aurora MySQL de origen. La replicación entre regiones de Aurora MySQL usa la replicación binaria de MySQL para volver a reproducir los cambios en el clúster de base de datos de la réplica de lectura entre regiones. Para activar el registro binario en un clúster de base de datos Aurora MySQL, actualice el parámetro `binlog_format` para el clúster de base de datos de origen. El parámetro `binlog_format` es un parámetro de nivel de clúster que se encuentra en el grupo de parámetros de clúster predeterminado. Si su clúster de base de datos usa el grupo de parámetros de clúster de base de datos predeterminado, cree un nuevo grupo de parámetros de clúster de base de datos para modificar la configuración de `binlog_format`. Es recomendable que defina `binlog_format` como `MIXED`. Sin embargo, también puede configurar `binlog_format` como `ROW` o `STATEMENT` si necesita un formato binlog concreto. Reinicie el clúster de base de datos de Aurora para que el cambio entre en vigor. Para obtener más información sobre la utilización del registro binario con Aurora MySQL, consulte [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md). Para obtener más información acerca de cómo modificar los parámetros de configuración de Aurora MySQL, 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). # Creación de un clúster de base de datos de réplica de lectura entre regiones para Aurora MySQL Puede crear un clúster de base de datos de Aurora que sea una réplica de lectura entre regiones mediante la Consola de administración de AWS, la AWS Command Line Interface (AWS CLI) o la API de Amazon RDS. Puede crear réplicas de lectura entre regiones desde clústeres de base de datos cifrados y sin cifrar. Cuando se crea una réplica de lectura entre regiones para Aurora MySQL con la Consola de administración de AWS, Amazon RDS crea un clúster de base de datos en la Región de AWS de destino y, luego, crea automáticamente una instancia de base de datos que es la instancia principal de ese clúster de base de datos. Cuando se crea una réplica de lectura entre regiones mediante la AWS CLI o la API de RDS, primero se crea el clúster de base de datos en la Región de AWS de destino y se espera a que pase a estar activo. Una vez que está activo, se crea una instancia de base de datos que es la instancia principal de ese clúster de base de datos. La replicación comienza cuando la instancia principal del clúster de base de datos de la réplica de lectura pasa a estar disponible. Use los siguientes procedimientos para crear una réplica de lectura entre regiones a partir de un clúster de base de datos de Aurora MySQL. Estos procedimientos sirven para crear réplicas de lectura desde clústeres de base de datos cifrados y sin cifrar. ## Consola **Para crear un clúster de base de datos de Aurora MySQL que sea una réplica de lectura entre regiones con la Consola de administración de AWS** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En la esquina superior derecha de la Consola de administración de AWS, seleccione la Región de AWS que aloja el clúster de base de datos de origen. 1. En el panel de navegación, seleccione **Databases** (Bases de datos). 1. Elija el clúster de base de datos para el que desea crear una réplica de lectura entre regiones. 1. En **Actions** (Acciones), elija **Create cross-Region read replica** (Crear réplica de lectura entre regiones). 1. En la página **Create cross region read replica (Crear réplica de lectura entre regiones)**, elija la configuración de opciones para su clúster de base de datos réplica de lectura entre regiones, como se describe en la siguiente tabla. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Elija **Create (Crear)** para crear una réplica de lectura entre regiones de Aurora. ## AWS CLI **Para crear un clúster de base de datos de Aurora MySQL que sea una réplica de lectura entre regiones con la CLI** 1. Llame al comando [create-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) de la AWS CLI en la en la que desee crear el clúster de base de datos de la réplica de lectura. Incluya la opción `--replication-source-identifier` y especifique el Nombre de recurso de Amazon (ARN) del clúster de base de datos de origen para el que desea crear una réplica de lectura. Para una replicación entre regiones en la que el clúster de base de datos identificado por `--replication-source-identifier` esté cifrado, especifique también las opciones `--kms-key-id` y `--storage-encrypted`. **nota** Puede configurar la replicación entre regiones desde un clúster de base de datos sin cifrar en una réplica de lectura cifrada especificando `--storage-encrypted` y proporcionando un valor para `--kms-key-id`. No puede especificar los parámetros `--master-username` y `--master-user-password`. Esos valores se toman del clúster de base de datos de origen. El siguiente ejemplo de código crea una réplica de lectura en la región us-east-1 a partir de una instantánea de clúster de base de datos sin cifrar de la región us-west-2. Se llama al comando en la región us-east-1. En este ejemplo se especifica la opción `--manage-master-user-password` para generar la contraseña del usuario maestro y administrarla en Secrets Manager. Para obtener más información, consulte [Administración de contraseñas con Amazon Aurora y AWS Secrets Manager](rds-secrets-manager.md). También puede utilizar la opción `--master-password` para especificar y administrar la contraseña usted mismo. Para Linux, macOS o Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Para Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` El siguiente ejemplo de código crea una réplica de lectura en la región us-east-1 a partir de una instantánea de clúster de base de datos cifrado de la región us-west-2. Se llama al comando en la región us-east-1. Para Linux, macOS o Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Para Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` La opción `--source-region` es necesaria para la replicación entre regiones entre las regiones AWSGovCloud (Este de EE. UU.) y AWS GovCloud (Oeste EE. UU.), donde el clúster de base de datos identificado por `--replication-source-identifier` está cifrado. Para `--source-region`, especifique la Región de AWS del clúster de base de datos de origen. Si no se ha especificado `--source-region`, especifique un valor de `--pre-signed-url`. Una *URL prefirmada* es una URL que contiene una solicitud firmada de Signature Version 4 para el comando `create-db-cluster` que se llama en la Región de AWS de origen. Para obtener más información acerca de la opción `pre-signed-url`, consulte [create-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) en la *Referencia de los comandos de AWS CLI*. 1. Compruebe que el clúster de base de datos está disponible para su uso con el comando [describe-db-clústers](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) de la AWS CLI, como se muestra en el siguiente ejemplo. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Cuando los resultados de **`describe-db-clusters`** muestren el estado `available`, cree la instancia principal del clúster de base de datos para que pueda comenzar la replicación. Para ello, utilice el comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) de la AWS CLI como se muestra en el siguiente ejemplo. Para Linux, macOS o Unix: ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Para Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Cuando la instancia de base de datos se ha creado y está disponible, comienza la replicación. Puede determinar si la instancia de base de datos está disponible llamando al comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) de la AWS CLI. ## API de RDS **Para crear un clúster de base de datos de Aurora MySQL que sea una réplica de lectura entre regiones con la API** 1. Llame a la operación [CreateDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de la API de RDS en la Región de AWS en la que desea crear el clúster de base de datos de la réplica de lectura. Incluya el parámetro `ReplicationSourceIdentifier` y especifique el Nombre de recurso de Amazon (ARN) del clúster de base de datos de origen para el que desea crear una réplica de lectura. Para una replicación entre regiones en la que el clúster de base de datos identificado por `ReplicationSourceIdentifier` esté cifrado, especifique el parámetro `KmsKeyId` y establecer el parámetro `StorageEncrypted` en `true`. **nota** Puede configurar la replicación entre regiones desde un clúster de base de datos sin cifrar en una réplica de lectura cifrada especificando `StorageEncrypted` como **true** y proporcionando un valor para `KmsKeyId`. En este caso, no es necesario especificar `PreSignedUrl`. No tiene que incluir los parámetros `MasterUsername` y `MasterUserPassword`, porque esos valores se toman del clúster de base de datos de origen. El siguiente ejemplo de código crea una réplica de lectura en la región us-east-1 a partir de una instantánea de clúster de base de datos sin cifrar de la región us-west-2. Se llama a la acción en la región us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` El siguiente ejemplo de código crea una réplica de lectura en la región us-east-1 a partir de una instantánea de clúster de base de datos cifrado de la región us-west-2. Se llama a la acción en la región us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Para la replicación entre regiones entre GovCloud (Este de EE. UU.) y GovCloud (Oeste EE. UU.), donde el clúster de la base de datos identificado por está codificado, especifique también el parámetro. La URL prefirmada debe ser una solicitud válida para la operación de la API `CreateDBCluster` que se pueda realizar en la Región de AWS de origen que contiene el clúster de base de datos cifrado que se va a replicar. El identificador de la clave de KMSS se utiliza para cifrar la réplica de lectura y debe ser una clave de KMS válida para la Región de AWS de destino. Para generar una URL prefirmada de forma automática y no manual, use el comando [create-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) de la AWS CLI con la opción `--source-region`. 1. Compruebe que el clúster de base de datos está disponible para el uso con la operación [DescribeDBclústers](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de la API de RDS, como se muestra en el siguiente ejemplo. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Cuando los resultados de `DescribeDBClusters` muestren el estado `available`, cree la instancia principal del clúster de base de datos para que pueda comenzar la replicación. Para ello, use la acción [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de la API de RDS, como se muestra en el siguiente ejemplo. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Cuando la instancia de base de datos se ha creado y está disponible, comienza la replicación. Puede determinar si la instancia de base de datos está disponible llamando al comando [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) de la AWS CLI. ## Visualización de réplicas entre regiones de Amazon Aurora MySQL Para ver las relaciones de reproducción entre regiones de sus clústeres de base de datos de Amazon Aurora MySQL, llame al comando [describe-db-clústers](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) de la AWS CLI o a la operación [DescribeDBclústers](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de la API de RDS. En la respuesta, consulte el campo `ReadReplicaIdentifiers` para los identificadores de clúster de base de datos de cualquier clúster de base de datos de réplica de lectura entre regiones. Consulte el elemento `ReplicationSourceIdentifier` para ver el ARN del clúster de base de datos de origen que es el origen de replicación. # Promoción de una réplica de lectura a un clúster de base de datos para Aurora MySQL Puede promover una réplica de lectura de Aurora MySQL a un clúster de base de datos independiente. Cuando se promueve una réplica de lectura de Aurora MySQL, las instancias de base de datos se reinician antes de que estén disponibles. Normalmente, una réplica de lectura de Aurora MySQL se promueve a un clúster de base de datos independiente como un esquema de recuperación de datos si el clúster de base de datos de origen devuelve un error. Para ello, cree primero una réplica de lectura y, a continuación, monitoree el clúster de base de datos de origen para ver si se producen errores. En caso de error, haga lo siguiente: 1. Promocione la réplica de lectura. 1. Dirija el tráfico de la base de datos al clúster de base de datos promovido. 1. Cree una réplica de lectura de reemplazo que tenga el clúster de base de datos promocionados como origen. Cuando promociona una réplica de lectura, esta se convierte en un clúster de base de datos de Aurora independiente. Este proceso de promoción puede tardar unos minutos o más, según el tamaño de la réplica de lectura. Una vez que haya promocionado la réplica de lectura a un nuevo clúster de base de datos, este será como cualquier otro clúster de base de datos. Por ejemplo, podrá crear réplicas de lectura a partir de él y realizar operaciones de restauración a un momento dado. También puede crear réplicas de Aurora para el clúster de base de datos. Como el clúster de base de datos promocionado ya no es una réplica de lectura, no puede usarlo como destino de la replicación. Los siguientes pasos muestran el proceso general para promocionar una réplica de lectura a un clúster de base de datos: 1. Detenga la escritura de transacciones en el clúster de base de datos de origen de la réplica de lectura y espere hasta que se hayan realizado todas las actualizaciones en la réplica de lectura. Las actualizaciones de la base de datos se producen en la réplica de lectura después de completarse en el clúster de base de datos de origen y el retraso de esta replicación puede variar considerablemente. Utilice la métrica `ReplicaLag` para determinar cuándo se han completado todas las actualizaciones en la réplica de lectura. La métrica `ReplicaLag` registra la cantidad de retraso de una instancia de base de datos de réplica de lectura con respecto a la instancia de base de datos de origen. Cuando la métrica `ReplicaLag` llegue a `0`, la réplica estará funcionando al mismo ritmo que la instancia de base de datos de origen. 1. Promocione la réplica de lectura mediante la opción **Promote (Promover)** de la consola de Amazon RDS, el comando [promote-read-replica-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) de la AWS CLI, o la operación [PromoteReadReplicaDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) de la API de Amazon RDS. Elija una instancia de base de datos de Aurora MySQL para promocionar la réplica de lectura. Una vez promocionada la réplica de lectura, el clúster de base de datos de Aurora MySQL se promociona a un clúster de base de datos independiente. La instancia de base de datos con la prioridad más alta se promueve a la instancia de base de datos principal del clúster de base de datos. Las demás instancias de base de datos se convierten en réplicas de Aurora. **nota** El proceso de promoción tarda algunos minutos en completarse. Cuando se promociona una réplica de lectura, la replicación se detiene y las instancias de base de datos se reinician. Una vez completado el reinicio, la réplica de lectura pasa a estar disponible como un nuevo clúster de base de datos. ## Consola **Para promocionar una réplica de lectura de Aurora MySQL a un clúster de base de datos** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En la consola, elija **Instances (Instancias)**. Aparece el panel **Instance (Instancia)**. 1. En el panel **Instances (Instancias)**, seleccione la réplica de lectura que desea promocionar. Las réplicas de lectura aparecen como instancias de base de datos de Aurora MySQL. 1. En **Actions (Acciones)**, elija **Promote read replica (Promover réplica de lectura)**. 1. En la página de confirmación, elija **Promote Read Replica (Promocionar réplica de lectura)**. ## AWS CLI Para promover una réplica de lectura a un clúster de base de datos, utilice la operación [promote-read-replica-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) de la AWS CLI. **Example** Para Linux, macOS o:Unix ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` En:Windows ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## API de RDS Para promover una réplica de lectura a un clúster de base de datos, llame a [PromoteReadReplicaDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). # Resolución de problemas de réplicas entre regiones para Amazon Aurora MySQL A continuación, puede encontrar una lista de mensajes de error frecuentes que pueden aparecer al crear una réplica de lectura entre regiones de Amazon Aurora y cómo resolver los errores especificados. ## Source clúster [DB clúster ARN] doesn't have binlogs enabled Para resolver este problema, habilite el registro binario en el clúster de base de datos de origen. Para obtener más información, consulte [Antes de empezar](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## Source clúster [DB clúster ARN] doesn't have clúster parameter group in sync on writer Este error aparece si se ha actualizado el parámetro `binlog_format` del clúster de base de datos pero no se ha reiniciado su instancia principal. Reinicie la instancia principal (es decir, la de escritura) del clúster de base de datos y vuelva a intentarlo. ## Source clúster [DB clúster ARN] already has a read replica in this region Puede tener hasta cinco clústeres de base de datos interregionales que sean réplicas de lectura para cada clúster de base de datos de origen en cualquier Región de AWS. Si ya tiene el número máximo de réplicas de lectura para un clúster de base de datos en una Región de AWS concreta, debe eliminar una existente antes de poder crear un nuevo clúster de base de datos entre regiones en dicha región. ## El clúster de base de datos [ARN del clúster de base de datos] requiere una actualización del motor de base de datos para admitir la replicación entre regiones Para resolver este problema, actualice la versión del motor de base de datos para todas las instancias del clúster de base de datos de origen a la versión más reciente del motor de base de datos e intente de nuevo crear una base de datos de réplica de lectura entre regiones. # 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. 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](USER_VPC.Scenarios.md#USER_VPC.Scenario3). 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](AuroraMySQL.Replication.CrossRegion.md). 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](mysql-replication-gtid.md). 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\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versión 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **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 . 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. # Uso de la replicación basada en GTID El siguiente contenido explica cómo utilizar los identificadores de transacciones globales (GTID) con replicación de registro binario (binlog) entre un clúster de Aurora MySQL y un origen externo. **nota** Para Aurora, solo puede usar esta característica con clústeres de Aurora MySQL que usan la replicación del binlog en una base de datos de MySQL externa o desde ella. La otra base de datos puede ser una instancia de Amazon RDS MySQL, una base de datos de MySQL en las instalaciones o un clúster de base de datos de Aurora en una Región de AWS diferente. Para obtener información sobre cómo configurar ese tipo de replicación, consulte [Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario)](AuroraMySQL.Replication.MySQL.md). Si utiliza la replicación del binlog y no conoce la replicación basada en GTID con MySQL, consulte [Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) en la documentación de MySQL. La replicación basada en GTID no es compatible con las versiones 2 y 3 de Aurora MySQL. **Topics** + [Información general de identificadores de transacciones globales (GTID)](#mysql-replication-gtid.overview) + [Parámetros de replicación basada en GTID](#mysql-replication-gtid.parameters) + [Activación de la replicación basada en GTID para un clúster de Aurora MySQL](mysql-replication-gtid.configuring-aurora.md) + [Desactivación de la reproducción basada en GTID para un clúster de base de datos de Aurora MySQL](mysql-replication-gtid.disabling.md) ## Información general de identificadores de transacciones globales (GTID) Los *identificadores de transacciones globales (GTID)* son indentificadores únicos generados por transacciones confirmadas por MySQL. Puede utilizar GTID para que la replicación del binlog sea más simple y sencilla para la solución de problemas. **nota** Cuando Aurora sincroniza datos entre las instancias de base de datos en un clúster, ese mecanismo de replicación no incluye el registro binario (binlog). Para Aurora MySQL, la replicación basada de GTID solo se aplica cuando también utiliza la replicación del binlog para realizar la replicación dentro o fuera de un clúster de base de datos de Aurora MySQL a partir de una base de datos compatible con MySQL externa. MySQL usa dos tipos distintos de transacciones para la replicación del binlog: + *Transacciones de GTID*: transacciones que se identifican mediante GTID. + *Transacciones anónimas*: transacciones que no tienen un GTID asignado. En una configuración de replicación, los GTID son únicos en todas las instancias de base de datos. Los GTID simplifican la configuración de replicación porque cuando se usan no es necesario hacer referencia a las posiciones de los archivos de registro. Los GTID también simplifican el seguimiento de las transacciones replicadas y determinan si las instancias de origen y las réplicas son coherentes. Normalmente utiliza la replicación basada en GTID con Aurora cuando efectúa la replicación desde una base de datos compatible con MySQL externa en un clúster de Aurora. Puede configurar esta configuración de replicación como parte de una migración desde una base de datos de Amazon RDS o local en Aurora MySQL. Si la base de datos externa ya utiliza GTID, habilitar la replicación basada en GTID para el clúster de Aurora simplifica el proceso de replicación. Configure la replicación basada en GTID para un clúster de Aurora MySQL configurando primero los parámetros de configuración relevantes en un grupo de parámetros de clúster de base de datos. A continuación, asocie ese grupo de parámetros al clúster. ## Parámetros de replicación basada en GTID Use los parámetros siguientes para configurar replicación basada en GTID. | Parámetro | Valores válidos | Descripción | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` especifica que las nuevas transacciones son anónimas (es decir, no tienen GTID) y que una transacción debe ser anónima para replicarse. `OFF_PERMISSIVE` especifica que las nuevas transacciones son anónimas, pero que todas las transacciones pueden replicarse. `ON_PERMISSIVE` especifica que las nuevas transacciones son de GTID, pero que todas las transacciones pueden replicarse. `ON` especifica que las nuevas transacciones son de GTID y que una transacción debe ser de GTID para poder replicarse. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` permite que las transacciones infrinjan la uniformidad de GTID. `ON` evita que las transacciones infrinjan la uniformidad de GTID. `WARN` permite que las transacciones infrinjan la uniformidad de GTID, pero genera un aviso cuando se proudce una infracción. | **nota** En la Consola de administración de AWS, el parámetro `gtid_mode` aparece como `gtid-mode`. Para la replicación basada en GTID, utilice esta configuración para el grupo de parámetros de clúster de base de datos para el clúster de base de datos de Aurora MySQL: + `ON` y `ON_PERMISSIVE` se aplican solo a la replicación saliente de una instancia de base de datos de RDS o un clúster de Aurora MySQL. Estos valores provocan que su clúster de base de datos de Aurora utilice GTID para transacciones que se replican en una base de datos externa. `ON` requiere que la base de datos externa también utilice la replicación basada en GTID. `ON_PERMISSIVE` hace que la replicación basada en GTID sea opcional en la base de datos externa. + Si se establece `OFF_PERMISSIVE`, significa que su instancia de base de datos de Aurora puede aceptar la replicación entrante de una base de datos externa. Se puede aplicar este procedimiento si la base de datos tanto si la base de datos utiliza la replicación basada en GTID como si no. + Si se establece `OFF`, significa que su clúster de base de datos de Aurora solo acepta la replicación entrante desde bases de datos externas que no utilizan la replicación basada en GTID. **sugerencia** La replicación entrante es el escenario de replicación del binlog más frecuente para los clústeres de Aurora MySQL. Para la replicación entrante, recomendamos que establezca el modo de GTID en `OFF_PERMISSIVE`. Esta configuración permite la replicación entrante desde bases de datos externas independientemente de la configuración de GTID en el origen de replicación. Para obtener más información acerca de los grupos de parámetros, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). # Activación de la replicación basada en GTID para un clúster de Aurora MySQL Cuando la replicación basada en GTID está habilitada para un clúster de base de datos de Aurora MySQL, la configuración de GTID se aplica a la replicación del binlog entrante y saliente. **Para habilitar la replicación basada en GTID para un clúster de Aurora MySQL, realice el siguiente procedimiento:** 1. Cree o edite un grupo de parámetros del clúster de base de datos con la siguiente configuración de parámetros: + `gtid_mode` – `ON` o `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Asocie el grupo de parámetros del clúster de base de datos con el clúster de Aurora MySQL. Para ello, siga los procedimientos en [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). 1. (Opcional) Especifique cómo asignar GTID a las transacciones que no los incluyen. Para ello, llame al procedimiento almacenado en [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versión 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). # Desactivación de la reproducción basada en GTID para un clúster de base de datos de Aurora MySQL Puede desactivar la reproducción basada en GTID para un clúster de base de datos de Aurora MySQL. Si realiza esto, significa que el clúster de Aurora no puede realizar la reproducción del binlog interna o externa con bases de datos externas que utilizan la reproducción basada en GTID. **nota** En el siguiente procedimiento, *réplica de lectura* hace referencia al destino de replicación en una configuración de Aurora con la replicación del binlog en una base de datos externa o desde ella. No hace referencia a las instancias de base de datos de réplica de Aurora de solo lectura. Por ejemplo, cuando un clúster de Aurora acepta la replicación entrante desde una fuente externa, la instancia principal de Aurora funciona como la réplica de lectura para la replicación del binlog. Para obtener más información sobre los procedimientos almacenados mencionados en esta sección, consulte [Referencia de procedimientos almacenados en Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md). **Para desactivar la reproducción basada en GTID para un clúster de base de datos de Aurora MySQL** 1. En las réplicas de Aurora, ejecute el siguiente procedimiento: Para la versión 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Para la versión 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Restablezca `gtid_mode` en `ON_PERMISSIVE` . 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 `gtid_mode` establecido en `ON_PERMISSIVE`. Para obtener más información sobre el establecimiento de parámetros de configuración con grupos de consultas, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Reinicie el clúster de base de datos de Aurora MySQL. 1. Restablezca `gtid_mode` en `OFF_PERMISSIVE` . 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 `gtid_mode` establecido en `OFF_PERMISSIVE`. 1. Reinicie el clúster de base de datos de Aurora MySQL. 1. Espere a que todas las transacciones de GTID se hayan aplicado en la instancia principal de Aurora. Para comprobar que se hayan aplicado, realice los siguientes pasos: 1. En la de la base de datos de MySQL, ejecute el comando `SHOW MASTER STATUS`. El resultado debería ser similar al que se indica a continuación. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Tenga en cuenta el archivo y la posición en su resultado. 1. En cada réplica de lectura, use la información de archivo y posición de su instancia de origen en el paso anterior para ejecutar la siguiente consulta: Para la versión 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Para la versión 2 ``` SELECT MASTER_POS_WAIT('file', position); ``` Por ejemplo, si el nombre del archivo es `mysql-bin-changelog.000031` y la posición es `107`, ejecute la siguiente instrucción: Para la versión 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Para la versión 2 ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Restablezca los parámetros de GTID para deshabilitar la replicación basada en GTID. 1. Asegúrese de que el grupo de parámetros del clúster de base de datos asociado al clúster de Aurora MySQL tenga la siguiente configuración de parámetros: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Reinicie el clúster de base de datos de Aurora MySQL.