Solución del retraso de replicación de registros binarios para Aurora MySQL

En esta sección se proporciona orientación sobre el retraso en la replicación de registros binarios para Aurora MySQL configurado como réplica de registros binarios. Abarca la arquitectura de replicación, la replicación paralela, el seguimiento de dependencias, la supervisión y las prácticas recomendadas de configuración.

La replicación de registros binarios replica los datos entre bases de datos compatibles con MySQL. La replicación de registros binarios que se describe en esta sección es asíncrona: el origen no espera a que las réplicas confirmen la aplicación de los cambios antes de confirmar las transacciones. Esto no se aplica a la replicación semisíncrona. En la replicación semisíncrona, el origen espera a que al menos una réplica acuse recibo de la transacción antes de confirmarla. Por ejemplo, los clústeres de bases de datos Multi-AZ para Amazon RDS para MySQL utilizan la replicación semisíncrona, lo cual queda fuera del ámbito de esta sección. La réplica mantiene una conexión persistente con el origen a través del subproceso de E/S para transmitir de forma continua los eventos de registros binarios. Esta sección se aplica a todas las topologías de replicación binlog en las que Aurora MySQL es la réplica. El origen puede ser otro clúster de Aurora MySQL, Amazon RDS para MySQL, MySQL en las instalaciones o MySQL en Amazon EC2. Esta sección también se aplica cuando Aurora MySQL es el origen que se replica en cualquier destino compatible con MySQL.

¿Está experimentando un pico de retraso en este momento? Omita el material de referencia y comience por Identificación del cuello de botella del retraso de la replicación para determinar si el subproceso de E/S o el subproceso de SQL es el cuello de botella; a continuación, siga el enlace correspondiente a ese escenario: Solución de problemas de retraso del subproceso de E/S o Solución de problemas de retraso del subproceso de SQL.

Arquitectura de replicación de MySQL

La replicación de MySQL se implementa a través de subprocesos especializados:

El proceso de replicación funciona de la siguiente manera:

Identificación del cuello de botella del retraso de la replicación

El retraso de la replicación puede producirse en dos áreas: el subproceso de E/S o el subproceso de SQL. El primer paso es determinar qué componente está retrasado.

Source_Log_File:       mysql-bin.000045
Read_Source_Log_Pos:   524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos:   524200000

File:     mysql-bin.000045
Position: 1073741824

Solución de problemas de retraso del subproceso de E/S

El subproceso de E/S es responsable de recuperar los eventos de registro binario del origen y escribirlos en el registro de retransmisión. Causas y soluciones comunes:

Estrategias de optimización para el retraso de los subprocesos de E/S

Solución de problemas de retraso del subproceso de SQL

El subproceso de SQL es el cuello de botella cuando el subproceso de E/S está al día con el origen, pero Seconds_Behind_Source sigue creciendo. Para cuantificar el retraso, supervise durante un periodo de 15 minutos. Compare la tasa de generación de binlog en el origen (la Position delta desde SHOW MASTER STATUS) con la tasa de aplicación de subprocesos de SQL en la réplica (la Exec_Source_Log_Pos delta).

Causas y soluciones comunes:

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
  LEFT JOIN information_schema.table_constraints tc
    ON t.table_schema = tc.table_schema
    AND t.table_name = tc.table_name
    AND tc.constraint_type = 'PRIMARY KEY'
WHERE tc.constraint_type IS NULL
  AND t.table_type = 'BASE TABLE'
  AND t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
ORDER BY 1;

SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;

SELECT database_name, table_name,
    MIN(last_update) AS oldest_stat_update,
    DATEDIFF(NOW(), MIN(last_update)) AS stats_age_in_days
FROM mysql.innodb_index_stats
WHERE database_name NOT IN ('mysql', 'sys')
GROUP BY database_name, table_name
HAVING stats_age_in_days > 7
ORDER BY stats_age_in_days DESC;

Reducción de la carga de trabajo de aplicación con filtros de replicación de la réplica

Aurora MySQL versión 3.01.0 y versiones posteriores son compatibles con los filtros de replicación de la réplica. Úselos para omitir bases de datos o tablas irrelevantes durante la aplicación, lo que reduce la carga de trabajo de los subprocesos de SQL. Los filtros de la réplica los aplica el subproceso de SQL: el subproceso de E/S sigue buscando todos los eventos de registro binario del origen, por lo que estos filtros reducen solo el trabajo de aplicación, no la transferencia de red. A diferencia de los filtros por origen (que funcionan solo por base de datos), los filtros de réplica admiten la granularidad por tabla mediante replicate-do-table y replicate-ignore-table. Para obtener más información, consulte Configuración de filtros de replicación con Aurora MySQL.

Replicación multiproceso (MTR)

Con MTR, la réplica aplica transacciones independientes en paralelo. No puede dividir una sola transacción grande en partes paralelas. El grado de paralelismo está limitado por la información de dependencia escrita por el origen.

Cuando MTR está habilitada (replica_parallel_workers >= 2), el aplicador de SQL se divide en un subproceso coordinador y varios subprocesos de trabajo. El coordinador lee las transacciones del registro de retransmisión. Examina las marcas temporales lógicas (last_committed y sequence_number) que el origen incorpora en cada transacción. A continuación, asigna transacciones independientes a los subprocesos de trabajo disponibles para su ejecución en paralelo. Dos transacciones son independientes si no comparten dependencias de datos, es decir, si modifican filas diferentes. El origen determina estas dependencias en el momento de la confirmación mediante el método de seguimiento de dependencias configurado y las registra en el registro binario. La réplica no puede aumentar el paralelismo más allá de lo que permite el origen.

MTR es la opción predeterminada recomendada

Recomendamos ejecutar réplicas con la MTR habilitada. La MTR está habilitada de forma predeterminada (replica_parallel_workers=4) en MySQL 8.0.27 y versiones posteriores, incluidas las versiones de Aurora MySQL 3 basadas en esas versiones. En versiones anteriores (Aurora MySQL 2.12.1 y versiones posteriores, o versiones basadas en versiones de MySQL anteriores a la 8.0.27), habilítela de forma explícita estableciendo replica_parallel_workers en un valor de 2 o más. Mantener la MTR habilitada tiene poco costo cuando el paralelismo no está disponible y permite que la réplica lo aproveche siempre que la carga de trabajo lo permita.

La MTR no reduce el retraso en los siguientes casos:

Seguimiento de dependencias en el origen

El origen determina qué transacciones se pueden aplicar en paralelo mediante el parámetro binlog_transaction_dependency_tracking. Valores recomendados: WRITESET.

Tipo paralelo (replica_parallel_type)

El parámetro replica_parallel_type determina cómo se distribuyen las transacciones entre los subprocesos de trabajo. Dispone de dos opciones:

Configuración de MTR

Tras cambiar la configuración de trabajadores paralelos, reinicie la replicación:

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

Optimizaciones de replicación específicas de Aurora

Aurora MySQL proporciona las siguientes características para mejorar el rendimiento de la replicación de registros binarios. En la siguiente tabla, se resume la disponibilidad, el estado predeterminado y cómo habilitar cada característica.

Supervisión de la replicación en paralelo

Utilice los siguientes métodos para supervisar el rendimiento de la replicación e identificar los cuellos de botella en la aplicación paralela:

Performance Schema

Tablas clave para supervisar la MTR:

Para evaluar la distribución uniforme del trabajo entre los subprocesos de trabajo, utilice la siguiente consulta:

SELECT
  a.channel_name,
  rw1.thread_id AS replica_worker_thread_id,
  ts1.count_star AS number_of_trx_executed,
  ROUND((ts1.count_star / sum_count_star) * 100, 2) AS percent_of_trx_executed_by_worker
FROM (
  SELECT rw.channel_name, SUM(ts.count_star) AS sum_count_star
  FROM performance_schema.events_transactions_summary_by_thread_by_event_name AS ts
    JOIN performance_schema.replication_applier_status_by_worker AS rw
      ON ts.thread_id = rw.thread_id
  GROUP BY rw.channel_name
) AS a
JOIN performance_schema.replication_applier_status_by_worker AS rw1
  ON a.channel_name = rw1.channel_name
JOIN performance_schema.events_transactions_summary_by_thread_by_event_name AS ts1
  ON rw1.thread_id = ts1.thread_id;

Si uno o dos trabajadores gestionan la mayoría de las transacciones, esto indica que las dependencias entre las transacciones son altas y limitan el paralelismo. Considere la posibilidad de cambiar al seguimiento de dependencias de WRITESET en el origen.

Si las posiciones del subproceso de E/S y del subproceso de SQL están cerca una de la otra pero Seconds_Behind_Source sigue creciendo, el propio subproceso de coordinador podría ser el cuello de botella. Compruebe performance_schema.replication_applier_status_by_coordinator si hay retrasos en el almacenamiento en búfer. Un cuello de botella de coordinador suele indicar que hay una gran dependencia entre las transacciones o que el subproceso coordinador único está sobrecargado y no puede distribuir los eventos con la suficiente rapidez.

Estadísticas de réplicas multiprocesos de registro de errores

Cuando log_error_verbosity=3 (predeterminado), Aurora MySQL escribe periódicamente estadísticas de réplicas multiprocesos en el registro de errores de MySQL. Puede ver estas entradas de la siguiente manera:

Para localizar las entradas de estadísticas de réplicas multiproceso en el registro de errores, busque la cadena que se muestra en el siguiente ejemplo. El registro de errores de MySQL utiliza terminología antigua en esta cadena interna; en esta documentación se utiliza el término preferido “réplica” en todo momento.

A continuación, se muestra una entrada de registro de error de ejemplo:

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 7215200; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1203644200 waited (count) when Workers occupied = 1022462 waited when Workers occupied = 62349203500

Campos clave que se deben analizar:

Ejemplos resueltos: diagnóstico de cuellos de botella en aplicaciones paralelas

En los siguientes ejemplos, se muestra cómo utilizar los orígenes de supervisión anteriores para diagnosticar los cuellos de botella comunes en las aplicaciones paralelas. Cada ejemplo comienza con el mismo síntoma, Seconds_Behind_Source crece de forma constante y ya ha confirmado que el subproceso de SQL es el cuello de botella (consulte Identificación del cuello de botella del retraso de la replicación) y utiliza las estadísticas de réplicas multiproceso y el esquema de rendimiento para determinar la acción correctiva.

Ejemplo 1: Los trabajadores están insuficientemente aprovisionados

En CloudWatch, la métrica ReplicaLag aumenta de forma constante desde casi cero hasta aproximadamente 400 segundos en 30 minutos. El uso de la CPU en la réplica se mantiene en torno al 55 %, por lo que la réplica no depende de la CPU.

Para confirmar dónde está el retraso, ejecute SHOW REPLICA STATUS dos veces, con 60 segundos de diferencia. Read_Source_Log_Pos avanza aproximadamente 1,2 GB, mientras que Exec_Source_Log_Pos avanza solo aproximadamente 300 MB. El subproceso de E/S sigue el ritmo del origen, pero el subproceso de SQL se queda atrás: el subproceso de SQL es el cuello de botella.

MTR está habilitada con replica_parallel_workers=4. Recupere las estadísticas de réplicas multiproceso más recientes del registro de errores (consulte Estadísticas de réplicas multiprocesos de registro de errores):

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 123; events assigned = 9876544; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 8455000 waited (count) when Workers occupied = 2456789 waited when Workers occupied = 110293847000

Interprete los campos de clave:

Diagnóstico: el coordinador siempre tiene más transacciones independientes listas para aplicar que trabajadores disponibles para ejecutarlas. Dado que las esperas por conflictos de reloj son insignificantes, el paralelismo está limitado por el número de trabajadores, no por las dependencias.

Acción: aumente replica_parallel_workers al número de vCPU de la réplica (por ejemplo, 16 en una db.r6g.4xlarge) y reinicie la replicación:

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

Verificación: una línea de estadísticas posterior muestra que la espera casi ha desaparecido y ReplicaLag vuelve a ser inferior a 5 segundos:

2026-05-10 15:02:14.882201 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 31840552; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 9120000 waited (count) when Workers occupied = 41233 waited when Workers occupied = 5980411000

“tiempo de espera cuando los trabajadores estaban ocupados” se redujo de aproximadamente 110 segundos a aproximadamente 6 segundos, y el rendimiento (eventos asignados) se triplicó con creces. Deje de aumentar el número de trabajadores una vez que el uso de la CPU se acerque al 80 % o la espera deje de disminuir.

Ejemplo 2: El seguimiento de dependencias de COMMIT_ORDER serializa una carga de trabajo de baja simultaneidad

El origen es una instancia de Amazon RDS para MySQL que ejecuta una carga de trabajo de OLTP con solo 4-8 subprocesos de aplicación que se confirman simultáneamente. La réplica es una db.r6g.4xlarge con replica_parallel_workers=16 y replica_parallel_type=LOGICAL_CLOCK. A pesar de tener 16 trabajadores, ReplicaLag se mantiene estable alrededor de 600 segundos y el uso de la CPU de la réplica es solo de alrededor del 20 %; los trabajadores parecen estar inactivos.

En primer lugar, compruebe el nivel de uniformidad con el que se distribuyen las transacciones entre los trabajadores mediante la consulta de distribución de trabajadores desde Performance Schema:

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                1903556 |                             96.41 |
|              |                       46 |                  23104 |                              1.17 |
|              |                       47 |                  18995 |                              0.96 |
|              |                       48 |                  16720 |                              0.85 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

El resultado anterior muestra los primeros 4 de los 16 subprocesos de trabajo. Un trabajador realiza más del 96 % de las transacciones, mientras que los otros 15 están prácticamente inactivos (cada uno de los trabajadores restantes ejecutó menos del 0,05 %). Efectivamente, la aplicación es en serie.

A continuación, confirme esto con las estadísticas de réplica multiproceso del registro de errores:

2026-05-10 15:22:11.110432 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 2014500; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 98712340000 waited (count) when Workers occupied = 50122 waited when Workers occupied = 1209847000

Esto apunta a un problema de dependencia, no a un problema de capacidad. Compruebe el método de seguimiento de dependencias en el origen:

SELECT @@global.binlog_transaction_dependency_tracking;

+-------------------------------------------------+
| @@global.binlog_transaction_dependency_tracking |
+-------------------------------------------------+
| COMMIT_ORDER                                    |
+-------------------------------------------------+

Causa raíz: con COMMIT_ORDER, el origen decide qué transacciones se pueden ejecutar en paralelo en función de las transacciones confirmadas juntas en la misma confirmación del grupo de registro binario. En esta carga de trabajo de baja concurrencia, solo se confirman unos pocos subprocesos a la vez, por lo que las confirmaciones de grupo son muy pequeñas. Como resultado, el origen marca casi todas las transacciones con un valor last_committed igual al sequence_number de la transacción anterior, marcándolas como dependientes de la transacción anterior. A continuación, la réplica debe aplicarlos uno tras otro (aunque modifiquen filas completamente ajenas), motivo por el cual 15 de los 16 trabajadores permanecen inactivos.

Acción: cambie el origen al seguimiento de dependencias por fila, que es independiente del tiempo de confirmación. Configúrelo de forma dinámica y manténgalo en el grupo de parámetros del clúster (o base de datos):

SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;

WRITESET calcula un hash de las filas que modifica cada transacción, de modo que las transacciones que tocan filas diferentes reciben marcas temporales independientes y se pueden aplicar en paralelo independientemente del momento en que se hayan confirmado. Asegúrese de que todas las tablas tengan claves principales, ya que WRITESET genera conjuntos de escrituras vacíos para las tablas que no las tienen (consulte Solución de problemas de retraso del subproceso de SQL). En MySQL 8.4, WRITESET es el valor predeterminado y este parámetro ya no existe.

Verificación: tras el cambio, la consulta de distribución de trabajadores muestra que el trabajo se distribuye uniformemente entre todos los trabajadores (se muestran los primeros 4 de 16; cada trabajador gestiona ahora aproximadamente el 6 % de las transacciones):

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                 132540 |                              6.30 |
|              |                       46 |                 125610 |                              5.97 |
|              |                       47 |                 129774 |                              6.17 |
|              |                       48 |                 122901 |                              5.84 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

las estadísticas del registro de errores muestran que los conflictos del reloj se reducen mientras ReplicaLag cae cerca de cero:

2026-05-10 15:41:55.204713 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 19874100; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 412300000 waited (count) when Workers occupied = 88122 waited when Workers occupied = 7019847000

“tiempo de espera en conflictos de reloj” se redujo de aproximadamente 99 segundos a aproximadamente 0,4 segundos, el rendimiento se multiplicó aproximadamente por diez y el cuello de botella pasó de las dependencias a la capacidad de los trabajadores, momento en el que se puede ajustar el número de trabajadores, como en el ejemplo 1.

Ejemplo 3: La ausencia de una clave principal obliga a realizar escaneos completos de la tabla en la réplica

ReplicaLag se intensifica durante un trabajo por lotes nocturno que ejecuta grandes instrucciones UPDATE y DELETE, y después se recupera. Durante el pico, la CPU de la réplica es moderada, pero parece que un trabajador está atascado.

En la réplica, ejecute SHOW PROCESSLIST y observe los subprocesos del trabajador de replicación. Un trabajador permanece en el estado Updating con la misma instrucción durante varios segundos cada vez:

+----+-------------+------+---------+----------+------+
| Id | User        | db   | Command | State    | Time |
+----+-------------+------+---------+----------+------+
| 12 | system user | app  | Connect | Updating |   38 |
+----+-------------+------+---------+----------+------+

Compruebe qué tablas replicadas carecen de una clave principal mediante la consulta de detección de Solución de problemas de retraso del subproceso de SQL:

+--------------+----------------+
| table_schema | table_name     |
+--------------+----------------+
| app          | events_archive |
+--------------+----------------+

Causa principal: con el registro binario basado en FILAS, cada fila de un evento UPDATE o DELETE debe estar ubicada en la réplica antes de poder aplicarse. Si la tabla no tiene una clave principal o una clave NOT NULL única, la réplica realiza un análisis completo de la tabla para cada fila afectada. En una tabla de varios millones de filas, una operación por lotes se convierte en millones de análisis completos y el trabajador que la ejecuta se detiene, lo que bloquea el progreso de la aplicación y aumenta el retraso.

Acción: agregue una clave principal a la tabla. Si no puede definir una clave explícita de forma inmediata, habilite las claves principales invisibles generadas (GIPK) configurando el parámetro sql_generate_invisible_primary_key en ON (disponible en las versiones de Aurora MySQL 3 basadas en MySQL 8.0.30 y posteriores), de forma que las tablas nuevas reciban una clave principal automática (consulte Solución de problemas de retraso del subproceso de SQL).

Verificación: tras agregar la clave principal, el trabajador ya no permanece en Updating, la tasa de aplicación de los subprocesos de SQL se recupera y ReplicaLag vuelve a la línea base durante el siguiente periodo de lotes.

Ejemplo 4: No se puede paralelizar una sola transacción grande

ReplicaLag salta bruscamente a una hora predecible cada día, se mantiene durante varios minutos y luego vuelve a caer casi a cero. El seguimiento de dependencias de WRITESET está habilitado, replica_parallel_workers=16, y todas las tablas tienen claves principales, por lo que los ejemplos anteriores no se aplican.

Durante el pico, la consulta de distribución de trabajadores muestra a un trabajador ocupado y el resto inactivo, pero, a diferencia del ejemplo 2, el registro de errores no muestra ni conflictos de reloj prolongados ni esperas de trabajadores ocupados:

2026-05-10 02:13:40.551922 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 95; events assigned = 4120000; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1530000 waited (count) when Workers occupied = 980 waited when Workers occupied = 210440000

Las esperas de dependencia y las esperas de trabajadores ocupados son bajas, pero solo hay un trabajador activo. Esto descarta el cuello de botella relacionado con la dependencia (ejemplo 2) y el obstáculo con respecto a la capacidad de los trabajadores (ejemplo 1).

Inspeccione al trabajador ocupado en performance_schema.replication_applier_status_by_worker o ejecute SHOW PROCESSLIST. Un solo trabajador realiza una transacción durante todo el periodo de repunte. En el origen, un trabajo de aplicación ejecuta una instrucción grande (por ejemplo, DELETE FROM orders WHERE created_at < '2025-01-01' que afecta a varios millones de filas) como una sola transacción.

Causa principal: MTR establece un paralelismo entre las transacciones independientes; no puede dividir una sola transacción entre los trabajadores. Una transacción grande la realiza exactamente un trabajador, por lo que agregar trabajadores, cambiar a WRITESET o agregar claves principales no ayuda. Para obtener más información, consulte Replicación multiproceso (MTR).

Acción: divida la operación grande en lotes más pequeños en el origen (por ejemplo, elimínela en bloques de unos pocos miles de filas por transacción, con una breve pausa entre los lotes). Las transacciones más pequeñas se confirman de forma independiente, por lo que la réplica puede distribuirlas entre los trabajadores. Siempre que sea posible, programe trabajos masivos durante los periodos de poco tráfico.

Verificación: después de agrupar el trabajo por lotes, el pico ReplicaLag diario se estabiliza y la consulta de distribución de trabajadores muestra que el lote se distribuye entre varios trabajadores en lugar de uno solo.

Prácticas recomendadas de supervisión

Prácticas recomendadas para minimizar el retraso de replicación

Las siguientes recomendaciones resumen las acciones clave para minimizar el retraso de replicación. Para obtener una guía detallada sobre cada tema, siga los enlaces de referencia cruzada.