¿Cómo puedo solucionar un retraso importante de la réplica con Amazon RDS para MySQL?

10 minutos de lectura
0

Quiero saber por qué se produce un retraso de la réplica cuando utilizo Amazon Relational Database Service (Amazon RDS) para MySQL.

Breve descripción

Amazon RDS para MySQL utiliza la replicación asincrónica. Esto significa que, a veces, la réplica no puede seguir el ritmo de la instancia de base de datos principal. Como resultado, puede producirse un retraso en la replicación.

Para supervisar el retraso de la replicación, utilice una réplica de lectura de Amazon RDS para MySQL con replicación basada en la posición de los archivos de registro binarios.

En Amazon CloudWatch, compruebe la métrica ReplicaLag para Amazon RDS. La métrica ReplicaLag informa del valor del campo Seconds_Behind_Master del comando SHOW SLAVE STATUS.

El campo Seconds_Behind_Master muestra la diferencia respecto a la marca de tiempo actual en la instancia de base de datos de réplica. También muestra la marca de tiempo original registrada en la instancia de base de datos principal para el procesamiento de eventos en la instancia de base de datos de réplica.

La replicación de MySQL utiliza tres hilos: el hilo Binlog Dump, el IO_THREAD y el SQL_THREAD. Para obtener más información sobre el funcionamiento de estos hilos, consulte la documentación de MySQL sobre Replication threads. Si se produce un retraso en la replicación, averigüe si se debe a la réplica IO_THREAD o SQL_THREAD. A continuación, podrá identificar la causa raíz del retraso.

Resolución

Para saber qué hilo de replicación está provocando el retraso, vea estos ejemplos:

1.    Ejecute el comando SHOW MASTER STATUS en la instancia de base de datos principal y revise el resultado. El resultado es similar al siguiente:

mysql> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.066552|      521 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Nota: En el resultado del ejemplo, la instancia de base de datos principal o fuente escribe los registros binarios en el archivo mysql-bin.066552.

2.    Ejecute el comando SHOW SLAVE STATUS en la instancia de base de datos de réplica y revise el resultado. El resultado es similar al de estos ejemplos:

Ejemplo 1:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066548
Read_Master_Log_Pos: 10050480
Relay_Master_Log_File: mysql-bin.066548
Exec_Master_Log_Pos: 10050300
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

En el ejemplo 1, el archivo Master_Log_File: mysql-bin.066548 indica que la réplica de IO_THREAD lee el archivo de registro binario mysql-bin.066548. La instancia de base de datos principal escribe los registros binarios en el archivo mysql-bin.066552. Este resultado indica que la réplica de IO_THREAD tiene un retraso de cuatro registros binarios. Sin embargo, Relay_Master_Log_File es mysql-bin.066548, lo que indica que la réplica de SQL_THREAD lee el mismo archivo que IO_THREAD. Esto significa que la réplica de SQL_THREAD progresa a la par, mientras que la réplica IO_THREAD va retrasada.

Ejemplo 2:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066552
Read_Master_Log_Pos: 430
Relay_Master_Log_File: mysql-bin.066530
Exec_Master_Log_Pos: 50360
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

En el ejemplo 2 se muestra que el archivo de registro de la instancia principal es mysql-bin-changelog.066552. El resultado indica que IO_THREAD progresa al mismo ritmo que la instancia de base de datos principal. En el resultado de la réplica, el hilo de SQL ejecuta Relay_Master_Log_File: mysql-bin-changelog.066530. Como resultado, SQL_THREAD tiene un retraso de 22 registros binarios.

Por norma general, IO_THREAD no provoca grandes retrasos de la replicación porque IO_THREAD solo lee los registros binarios de la instancia principal o fuente. Sin embargo, la conectividad y la latencia de la red pueden afectar a la velocidad de las lecturas entre los servidores. Es posible que la réplica de IO_THREAD sea más lenta por un elevado uso del ancho de banda.

Si la réplica de SQL_THREAD es el origen de los retrasos en la replicación, podrían producirse retrasos en las siguientes circunstancias:

  • Consultas de ejecución prolongada en la instancia de base de datos principal
  • Tamaño o almacenamiento insuficiente de la clase de la instancia de base de datos
  • Ejecución de consultas paralelas en la instancia de base de datos principal
  • Registros binarios sincronizados con el disco de la instancia de base de datos de réplica
  • Binlog_format se ha definido como ROW en la réplica
  • Retraso en la creación de la réplica

Consultas de ejecución prolongada en la instancia principal

Las consultas de ejecución prolongada en la instancia de base de datos principal que tardan el mismo tiempo en ejecutarse en la instancia de base de datos de réplica pueden aumentar el valor seconds_behind_master. Por ejemplo, si inicia un cambio en la instancia principal y tarda una hora en ejecutarse, el retraso será de una hora. Si el cambio también tarda una hora en completarse en la réplica, el retraso total es de aproximadamente dos horas en el momento de la finalización. Se trata de un retraso previsto, pero puede supervisar el registro lento de las consultas en la instancia principal para minimizarlo. También puede identificar las sentencias de ejecución prolongada para reducir el retraso. Luego, fragmente las instrucciones de ejecución prolongada en instrucciones o transacciones más pequeñas.

Tamaño o almacenamiento insuficiente de la clase de la instancia de base de datos

Si la configuración del almacenamiento o la clase de la instancia de base de datos de réplica son inferiores a la principal, es posible que la réplica se vea limitada debido a la falta de recursos. Esto se debe a que la réplica no puede seguir el ritmo de los cambios realizados en la instancia principal. Asegúrese de que el tipo de la instancia de base de datos de réplica sea igual o superior al de la principal. Para que la replicación funcione de manera eficaz, cada réplica de lectura requiere la misma cantidad de recursos de computación y almacenamiento que la instancia de base de datos fuente. Para obtener más información, consulte Clases de instancia de base de datos.

Ejecución de consultas paralelas en la instancia de base de datos principal

Si ejecuta consultas en paralelo en la instancia principal, se reproducirán en la réplica por orden. Esto se debe a que, de forma predeterminada, la replicación de MySQL solo tiene un hilo (SQL_THREAD). Si tiene lugar un gran volumen de escritura en la instancia de base de datos fuente en paralelo, las escrituras se reproducirán en serie en la réplica de lectura. Las escrituras en la réplica de lectura utilizan solo un SQL_THREAD para la serialización. Esto puede provocar un retraso entre la instancia de base de datos fuente y la réplica de lectura.

La replicación de varios hilos (en paralelo) está disponible para MySQL 5.6, MySQL 5.7 y versiones posteriores. Para obtener más información sobre la replicación de varios hilos, consulte la documentación de MySQL sobre las variables y opciones de registros binarios.

La replicación de varios hilos puede provocar brechas en la replicación. Por ejemplo, la replicación de varios hilos no se recomienda cuando se omiten los errores de replicación, porque es difícil identificar qué transacciones se están omitiendo. Esto puede provocar brechas en la coherencia de los datos entre la instancia de base de datos principal y la réplica.

Registros binarios sincronizados con el disco de la instancia de base de datos de réplica

La activación de las copias de seguridad automáticas en la réplica puede generar una sobrecarga al sincronizar los registros binarios con el disco de la réplica. El valor predeterminado del parámetro sync_binlog es 1. Si cambia este valor a 0, también desactivará la sincronización del registro binario con el disco por parte del servidor MySQL. En lugar de iniciar sesión en el disco, el sistema operativo vacía ocasionalmente los registros binarios en el disco.

Desactivar la sincronización de registros binarios puede reducir la sobrecarga de rendimiento tal y como se necesita para sincronizar los registros binarios con el disco en cada confirmación. Sin embargo, si se produce un fallo eléctrico o el sistema operativo se bloquea, es posible que algunas de las confirmaciones no se sincronicen con los registros binarios. Esta falta de sincronización puede afectar a las capacidades de recuperación a un momento dado (PITR). Para obtener más información, consulte la documentación de MySQL sobre sync_binlog.

Binlog_format se ha definido como ROW

El hilo de SQL realiza un análisis completo de la tabla en la réplica cuando se dan estos dos factores:

  • En la instancia de base de datos principal binlog_format se ha definido como ROW.
  • Falta una clave principal en la tabla de origen.

Esto se debe a que el valor predeterminado del parámetro slave_rows_search_algorithms es TABLE_SCAN,INDEX_SCAN.

Para solucionar este problema a corto plazo, cambie el algoritmo de búsqueda a INDEX_SCAN,HASH_SCAN con el fin de reducir la sobrecarga del análisis completo de la tabla. A largo plazo, se recomienda añadir una clave principal explícita a cada tabla.

Para obtener más información sobre el parámetro slave-rows-search-algorithms, consulte la documentación de MySQL sobre slave_rows_search_algorithms.

Retraso en la creación de la réplica

Amazon RDS toma una instantánea de la base de datos para crear una réplica de lectura de una instancia principal de MySQL. A continuación, Amazon RDS restaura la instantánea para crear una nueva instancia de base de datos (réplica) y establece la replicación entre ambas.

Amazon RDS tarda un tiempo en crear nuevas réplicas de lectura. Una vez establecida la replicación, se produce un retraso por el tiempo que se tarda en crear una copia de seguridad de la instancia de base de datos principal. Para minimizar este retraso, cree una copia de seguridad manual antes de solicitar la creación de la réplica. Entonces, la instantánea de la base de datos será una copia de seguridad incremental.

Cuando se restaura una réplica de lectura a partir de una instantánea, la réplica no espera a que se transfieran todos los datos desde el origen. La instancia de base de datos de réplica está disponible para llevar a cabo operaciones de base de datos. Las cargas de la instantánea existente de Amazon Elastic Block Store (Amazon EBS) crean un nuevo volumen en segundo plano.

Nota: En el caso de las réplicas de Amazon RDS para MySQL (volúmenes basados en EBS), el retraso de la réplica puede aumentar al principio. Esto se debe a que el efecto de la carga diferida puede influir en el rendimiento de la replicación.

Para mitigar los efectos de la carga diferida en las tablas de la réplica de lectura recién creada, puede realizar operaciones que impliquen análisis de tablas completas. Por ejemplo, ejecutar una operación mysqldump en su réplica de lectura en el caso de bases de datos o tablas concretas. Esto permite que Amazon RDS priorice y descargue todos los datos de tablas con copia de seguridad de Amazon Simple Storage Service (Amazon S3).

Además, plantéese utilizar la característica de calentamiento de la caché de InnoDB «a la carta». La función de calentamiento de la caché de InnoDB guarda el estado del grupo de búferes en el disco, en un archivo denominado ib_buffer_pool en el directorio de datos de InnoDB. Esto puede mejorar el rendimiento al volcar el estado actual del grupo de búferes de la instancia de base de datos principal antes de crear la réplica de lectura. Luego vuelva a cargar el conjunto de búferes, una vez creada una réplica de lectura.

Información relacionada

Uso de la replicación de MySQL en Amazon RDS

Uso de réplicas de lectura de MySQL