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.
Temas
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.
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.
-
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).
-
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.
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.
-
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.
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.
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_schema.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.
