Replicación con Amazon Aurora MySQL - Amazon Aurora
Réplicas de AuroraOpciones de replicaciónRendimiento de replicaciónReinicio sin tiempo de inactividad (ZDR)Configuración de filtros de replicaciónMonitoreo de replicación de

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:

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.

  • 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).

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.

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.

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 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 Working with parameter groups (Trabajar con grupos de parámetros).

Puede establecer parámetros en un grupo de parámetros de clústeres de base de datos mediante la AWS Management Console, la AWS CLI o la API de RDS. Para obtener información acerca de cómo configurar los parámetros, consulte Modificación de parámetros de un grupo de parámetros de base de datos. 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:

ejemplo 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"
ejemplo 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"
ejemplo 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"
ejemplo 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"
ejemplo 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"
ejemplo 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 los parámetros de un grupo de parámetros de base de datos.

  • 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 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_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.