# 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.
**nota**
Para los casos de uso de la replicación entre regiones, considere utilizar [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md) como alternativa a la replicación basada en registros binarios. La base de datos global de Aurora utiliza una infraestructura especificada para la replicación, lo que proporciona una latencia más baja y requiere menos administración operativa que la replicación de registros binarios en todas las regiones.
**¿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](#aurora-mysql-replication-lag-identifying) 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](#aurora-mysql-replication-lag-io-thread) o [Solución de problemas de retraso del subproceso de SQL](#aurora-mysql-replication-lag-sql-thread).
**Topics**
+ [Arquitectura de replicación de MySQL](#aurora-mysql-binlog-replication-lag-overview)
+ [Identificación del cuello de botella del retraso de la replicación](#aurora-mysql-replication-lag-identifying)
+ [Solución de problemas de retraso del subproceso de E/S](#aurora-mysql-replication-lag-io-thread)
+ [Solución de problemas de retraso del subproceso de SQL](#aurora-mysql-replication-lag-sql-thread)
+ [Replicación multiproceso (MTR)](#aurora-mysql-replication-lag-mtr)
+ [Optimizaciones de replicación específicas de Aurora](#aurora-mysql-replication-lag-aurora-optimizations)
+ [Supervisión de la replicación en paralelo](#aurora-mysql-replication-lag-monitoring)
+ [Prácticas recomendadas para minimizar el retraso de replicación](#aurora-mysql-replication-lag-best-practices)
## Arquitectura de replicación de MySQL
La replicación de MySQL se implementa a través de subprocesos especializados:
+ **Subproceso de volcado de registros binarios (origen)**: se crea cuando se conecta una réplica. Envía el contenido del registro binario a la réplica. Visible en `SHOW PROCESSLIST` como el subproceso “Copia de datos de binlog”.
+ **Subproceso de E/S de replicación (réplica)**: se conecta al origen y solicita actualizaciones del registro binario. Las escribe en el registro de retransmisiones de la réplica. Siempre un único subproceso por canal de replicación, independientemente de la configuración de replicación multiproceso (MTR).
+ **Subproceso de SQL de replicación (réplica)**: lee el registro de retransmisión y aplica las transacciones. El aplicador siempre consta de un subproceso coordinador que lee las transacciones del registro de retransmisión, más N subprocesos de trabajo que las aplican, donde N es el valor de `replica_parallel_workers`. Con `replica_parallel_workers=1`, el único trabajador aplica las transacciones de forma secuencial. Con `replica_parallel_workers >= 2`, el coordinador asigna transacciones independientes a varios subprocesos de trabajo para su aplicación en paralelo.
**nota**
La configuración de `replica_parallel_workers=0` está obsoleta a partir de MySQL 8.0.30 y está sujeta a eliminación en una versión futura de MySQL. En su lugar, use `replica_parallel_workers=1` para aplicar con un solo subproceso.
El proceso de replicación funciona de la siguiente manera:
1. El origen ejecuta instrucciones DML, DCL o DDL.
1. Al confirmar, el origen escribe los datos en el registro binario.
1. El subproceso de E/S de la réplica busca los eventos y los escribe en el registro de retransmisión.
1. El subproceso de SQL aplica los cambios del registro de retransmisión (de un solo subproceso o de varios subprocesos).
## 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.
**nota**
El campo `Seconds_Behind_Source` en `SHOW REPLICA STATUS` mide el tiempo transcurrido entre el momento en que se registra un evento en el origen y el momento en que el subproceso SQL lo aplica. Esta métrica no indica específicamente el retraso del subproceso de E/S. Para identificar el retraso del subproceso de E/S, debe comparar las posiciones de los registros binarios tal y como se describe en los pasos siguientes.
**nota**
Algunos comandos y cadenas internas de MySQL que se muestran en esta sección, por ejemplo `SHOW MASTER STATUS`, utilizan terminología antigua. En esta documentación, se utilizan los términos preferidos “origen” y “réplica” en todo el documento.
**Determinación de qué subproceso de replicación está retrasado**
1. En la réplica, ejecute `SHOW REPLICA STATUS` y compare `Source_Log_File` / `Read_Source_Log_Pos` (posición del subproceso de E/S) con `File` / `Position` de `SHOW MASTER STATUS` en el origen. Si estas diferencias son significativas (con una separación de >50 MB o >1 archivo binlog), el subproceso de E/S está retrasado.
1. Compare la posición del subproceso de E/S con la posición del subproceso de SQL (`Relay_Source_Log_File` / `Exec_Source_Log_Pos`). Si el subproceso de E/S está al día pero el subproceso de SQL está atrasado (separados por >50 MB), el subproceso de SQL es el cuello de botella.
**Evaluación inicial rápida con datos solo de réplica**
Puede realizar una evaluación inicial solo con datos de la réplica. Ejecute `SHOW REPLICA STATUS` dos veces, con 1-2 minutos de diferencia, y observe lo siguiente:
Si `Read_Source_Log_Pos` avanza pero `Exec_Source_Log_Pos` se detiene o avanza mucho más despacio, el subproceso de SQL es el cuello de botella (escenario B). Continúe en [Solución de problemas de retraso del subproceso de SQL](#aurora-mysql-replication-lag-sql-thread).
Si ambos `Read_Source_Log_Pos` y `Exec_Source_Log_Pos` se estancan mientras `Seconds_Behind_Source` está creciendo, es probable que el subproceso de E/S esté retrasado. Antes de realizar cambios en la configuración, confirme comparando las posiciones de la réplica con las del origen mediante `SHOW MASTER STATUS` como se describe en el paso 1 del procedimiento anterior.
| Escenario | Subproceso de E/S frente a origen | Subproceso de SQL frente a subproceso de E/S | Cuello de botella |
| --- | --- | --- | --- |
| A | Muy por detrás (>50 MB) | Cerca (<10 MB) | Subproceso de E/S |
| B | Cerca (<10 MB) | Muy por detrás (>50 MB) | Subproceso de SQL |
| C | Muy por detrás | Muy por detrás | Ambos (comience con E/S) |
**Example Interpretación de posiciones de registros binarios**
En el ejemplo siguiente, se muestra cómo comparar las posiciones de registros binarios para determinar el cuello de botella.
En la réplica, `SHOW REPLICA STATUS` devuelve:
```
Source_Log_File: mysql-bin.000045
Read_Source_Log_Pos: 524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos: 524200000
```
En el origen, `SHOW MASTER STATUS` devuelve:
```
File: mysql-bin.000045
Position: 1073741824
```
Para determinar el retraso del subproceso de E/S, reste la posición del subproceso de E/S de la posición de origen:
(1073741824 − 524288000) / 1048576 = **524 MB**: el subproceso de E/S está muy por detrás del origen (escenario A).
Para determinar el retraso del subproceso de SQL, reste la posición del subproceso de SQL de la posición del subproceso de E/S:
(524288000 − 524200000) / 1048576 = **0,08 MB**: el subproceso de SQL sigue el ritmo del subproceso de E/S.
En este caso, centre la solución de problemas en el subproceso de E/S. Para obtener más información, consulte [Solución de problemas de retraso del subproceso de E/S](#aurora-mysql-replication-lag-io-thread).
**Anatomía de un pico de retraso de replicación**
Un patrón común es un pico repentino en `Seconds_Behind_Source` seguido de un rápido retorno a valores cercanos a cero. Esto ocurre cuando un DML de larga duración en el origen (como una UPDATE que escanea millones de filas pero modifica solo unas pocas) tarda unos minutos en ejecutarse. Con el registro binario basado en FILAS, solo las filas modificadas se escriben en el registro binario. Cuando el subproceso de SQL detecta este evento, calcula el retraso en función de la hora de inicio de la transacción en el origen. Esto produce un valor inicial elevado. Sin embargo, dado que solo es necesario aplicar unas pocas filas, la réplica se recupera rápidamente. Este es el comportamiento esperado y no indica un problema de replicación sostenido.
## 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:
| Causa | Cómo identificar | Resolución |
| --- | --- | --- |
| Limitaciones de ancho de banda de la red | Comprobación de CloudWatch NetworkReceiveThroughput / NetworkTransmitThroughput | Uso instancias con mayor capacidad de red; asegurarse de que haya clases de instancias similares en el origen y en la réplica |
| Latencia de red (entre regiones o en las instalaciones) | Distancia geográfica entre el origen y la réplica; tiempo de ida y vuelta elevado | En el caso de los orígenes en las instalaciones, utilícelos para una conectividad dedicada de baja latencia |
| Limitaciones de recursos en el origen | Uso elevado de CPU (CPUUtilization), presión de memoria (FreeableMemory) | Escale verticalmente la instancia de origen. Cada réplica conectada crea un subproceso de copia de datos de binlog en el origen; reduzca la cantidad de réplicas conectadas si el origen tiene recursos limitados. |
| Transacciones de gran tamaño con datos de BLOB/TEXT | Supervisión del tamaño de los eventos de registro binario mediante la métrica de CloudWatch SumBinaryLogSize | Establezca binlog\_row\_image=noblob; habilite la compresión de transacciones de registros binarios (binlog\_transaction\_compression=ON). Realice primero la prueba en un entorno que no sea de producción: la compresión aumenta el uso de la CPU en el origen y en la réplica. |
| Se ha alcanzado el límite de espacio de registro de retransmisión | Replica\_IO\_State muestra “En espera de que el subproceso de SQL de réplica libere suficiente espacio del registro de retransmisión” | Esto indica que el subproceso de SQL es la causa principal, no el subproceso de E/S. Aborde primero el retraso del subproceso de SQL. En Aurora MySQL, el valor predeterminado de relay\_log\_space\_limit es aproximadamente 953 MiB. Este mensaje forma parte del funcionamiento normal cuando el subproceso de SQL no puede aplicar los cambios con la suficiente rapidez. Este mensaje no indica necesariamente un problema de rendimiento del subproceso de E/S. |
### Estrategias de optimización para el retraso de los subprocesos de E/S
1. **Utilice al menos la misma clase de instancia que el origen**: este enfoque proporciona suficiente CPU, memoria, capacidad de E/S y ancho de banda de la red.
1. **Garantice un ancho de banda de la red suficiente**: utilice instancias con una gran capacidad de red. Para orígenes en las instalaciones, opte por un ancho de banda dedicado y una experiencia de red más coherente.
1. **Compruebe los recursos del origen, especialmente con muchas réplicas**: supervise la CPU, la memoria, la red y la E/S de binlog del origen. Cada réplica conectada agrega un subproceso de descarga de binlog en el origen, de modo que un origen que sirva a muchas réplicas puede convertirse él mismo en el cuello de botella. Se recomienda confirmar que el origen no está saturado antes de escalar verticalmente la réplica. Si el origen tiene recursos limitados, considere reducir el número de réplicas conectadas.
1. **Compruebe que la caché de E/S de binlog de Aurora esté activa**: la caché de E/S de binlog reduce la E/S del disco en el origen para servir los eventos de registro binario. Se habilita automáticamente en Aurora MySQL versión 2.10 y versiones posteriores; no es necesaria ninguna configuración. Si el origen es un clúster de Aurora, compruebe que se esté utilizando la caché con `SHOW GLOBAL STATUS LIKE 'aurora_binlog_io_cache%'`. Para obtener más información, consulte [Optimización de replicación binlog](binlog-optimization.md#binlog-optimization-binlog-io-cache).
1. **Habilite la compresión de transacciones de registros binarios**: establezca `binlog_transaction_compression=ON` en el grupo de parámetros. Reduce los requisitos de ancho de banda. Esta configuración tiene las siguientes consideraciones:
+ La compresión aumenta el uso de la CPU en el origen y en la réplica.
+ Primero, realice pruebas en un entorno que no sea de producción para encontrar el equilibrio óptimo entre la compresión y la utilización de recursos.
+ Si lo desea, ajuste el nivel de compresión mediante `binlog_transaction_compression_level_zstd` (predeterminado: 3, rango: 1–22).
1. **Minimice las escrituras en registros binarios**: configure `binlog_row_image=noblob` para eliminar los datos de BLOB/TEXT de los registros binarios. No lo utilice si la réplica tiene desencadenadores que hacen referencia a las columnas de BLOB. Para obtener más información, consulte [binlog\_row\_image](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image) en el sitio web de MySQL.
1. **Implemente filtros de replicación en el origen**: utilice `binlog-do-db` o `binlog-ignore-db` para excluir las bases de datos innecesarias. Estos son parámetros estáticos que requieren un reinicio.
**importante**
Los filtros del origen afectan por completo a lo que se escribe en los registros binarios. Las bases de datos excluidas no se replican en ninguna réplica posterior. Si el origen es una instancia de MySQL autoadministrada (en las instalaciones o en Amazon EC2), las bases de datos excluidas tampoco están disponibles para la recuperación en un momento dado basada en registros binarios. Amazon RDS para MySQL no admite el filtrado de binlog del origen (`binlog-do-db`/`binlog-ignore-db` no son configurables); en su lugar, utilice filtros de replicación de la réplica. Aurora usa el volumen del clúster para PITR y no se ve afectada por los filtros de registro binarios con fines de copia de seguridad.
## 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:
| Causa | Cómo identificar | Resolución |
| --- | --- | --- |
| Replicación de un solo subproceso | SELECT @@global.replica\_parallel\_workers; devuelve 0 o 1 | Habilite la replicación multiproceso (MTR) con el seguimiento de dependencias de WRITESET. La MTR por sí sola no resuelve el retraso si los conflictos de reloj son intensos. Consulte [Seguimiento de dependencias en el origen](#aurora-mysql-replication-lag-mtr-dependency) para ajustar el seguimiento de dependencias y [Estadísticas de réplicas multiprocesos de registro de errores](#aurora-mysql-replication-lag-monitoring-error-log) para identificar los conflictos de reloj. |
| Falta de claves principales | Sin una clave principal (o una clave única con un valor NOT NULL), la réplica realiza un análisis completo de la tabla por cada fila modificada en las operaciones UPDATE y DELETE. Utilice la siguiente consulta para identificar las tablas sin claves principales: 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;
| Agregue claves principales a todas las tablas replicadas. Si no es posible agregar claves principales explícitas de forma inmediata, considere habilitar 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). Para obtener más información sobre las claves principales invisibles generadas, consulte [Claves principales invisibles generadas](https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html) en el sitio web de MySQL. |
| Grandes transacciones de escritura en el origen | Una transacción que modifica muchas filas (por ejemplo, una UPDATE o DELETE masivas) se replica como una sola unidad que solo puede aplicar un subproceso de trabajo, independientemente de la configuración de la MTR. En el origen, identifique las transacciones de escritura activas de larga duración con: SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;
En la réplica, un trabajador permanece ocupado con la misma instrucción en SHOW PROCESSLIST mientras los demás permanecen inactivos. Las transacciones inactivas durante mucho tiempo o las transacciones en espera de bloqueos en el origen no provocan por sí solas un retraso en la replicación; solo importa el volumen de escritura confirmado, ya que los eventos llegan al registro binario en el momento de la confirmación. | Divida las operaciones masivas en transacciones más pequeñas (por ejemplo, unos pocos miles de filas por confirmación) para que la réplica pueda aplicarlas en paralelo. Para ver un ejemplo práctico, consulte [Ejemplo 4: No se puede paralelizar una sola transacción grande](#aurora-mysql-replication-lag-monitoring-example4). |
| Operaciones DDL | DDL bloquea otros eventos de replicación | Utilice una herramienta de cambio de esquema en línea o utilice implementaciones azul/verde. Programe DDL durante los periodos de poco tráfico. Para pt-online-schema-change, consulte el [kit de herramientas de Percona](https://docs.percona.com/percona-toolkit/) en el sitio web de Percona. Para gh-ost, consulte [gh-ost](https://github.com/github/gh-ost) en el sitio web de GitHub. |
| Configuración de replicación en paralelo subóptima | Baja utilización de los trabajadores; gran cantidad de conflictos de reloj en las estadísticas de los coordinadores. Compruebe el campo “Tiempo de espera en conflictos del reloj” en la entrada del registro de errores de las estadísticas de réplicas multiproceso (consulte [Estadísticas de réplicas multiprocesos de registro de errores](#aurora-mysql-replication-lag-monitoring-error-log)). Los valores altos en relación con los “segundos transcurridos” indican que las dependencias bloquean con frecuencia las transacciones. | Ajuste del seguimiento de las dependencias (WRITESET) y de recuento de trabajadores |
| Contención de recursos a causa de las cargas de trabajo de análisis | Consultas de OLAP complejas que compiten con el subproceso de SQL por los recursos (CPU, memoria) | Separación de las cargas de trabajo de análisis en réplicas dedicadas |
| Estadísticas de tablas desactualizadas | Planes de consultas subóptimos en la réplica. Utilice la siguiente consulta para identificar las tablas con estadísticas obsoletas (de más de 7 días): 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;
| Ejecución de ANALYZE TABLE periódicamente en tablas con estadísticas obsoletas |
### 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](AuroraMySQL.Replication.Filters.md).
## 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:
+ El cuello de botella es el subproceso de E/S (problema de red/ancho de banda de la red).
+ El retraso se debe a una sola transacción de larga duración.
+ La réplica está saturada de CPU (más subprocesos empeoran la situación).
+ Las tablas carecen de claves principales (lo que obliga a realizar análisis completos de la tabla, lo que anula el paralelismo).
### 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`.
+ **COMMIT\_ORDER**: rastrea las dependencias en función del tiempo de confirmación. Funciona mejor con un alto nivel de simultaneidad y con confirmaciones de grupos grandes. Paralelismo limitado en entornos de baja simultaneidad.
+ **WRITESET (recomendado)**: rastrea las dependencias de datos reales por fila. El rendimiento siempre es al menos tan bueno como el de COMMIT\_ORDER. Significativamente mejor con cargas de trabajo de baja simultaneidad. Requiere que las tablas tengan claves principales.
El seguimiento de dependencias de WRITESET produce conjuntos de escritura vacíos o parciales (lo que limita el paralelismo) en los siguientes casos:
+ Tablas sin claves primarias o únicas
+ Instrucciones DDL (CREATE TABLE, ALTER TABLE, etc.)
+ Transacciones que modifican las tablas principales en relaciones de clave externa
Además, el historial de dependencias se borra cuando el registro binario rota o cuando se alcanza el límite de `binlog_transaction_dependency_history_size`, lo que reduce temporalmente el paralelismo.
+ **WRITESET\_SESSION**: igual que WRITESET, con la restricción adicional de que las transacciones de la misma sesión no se pueden paralelizar.
**nota**
MySQL 8.4 ha eliminado `binlog_transaction_dependency_tracking` y su valor predeterminado es WRITESET (no configurable). En las versiones anteriores, el valor predeterminado era COMMIT\_ORDER.
### 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:
+ **LOGICAL\_CLOCK (recomendado)**: utiliza marcas temporales lógicas para determinar qué transacciones se pueden ejecutar en paralelo, incluso dentro de la misma base de datos. Este enfoque da como resultado un mayor rendimiento de replicación y una menor latencia para la mayoría de las cargas de trabajo. Úselo a menos que tenga una carga de trabajo específica con varias bases de datos que no se beneficie de ella.
+ **DATABASE**: asigna las transacciones a los subprocesos de trabajo en función de la base de datos a la que afectan. Considérelo solo cuando la aplicación utilice varias bases de datos con cargas de trabajo claramente separadas y las transacciones rara vez sobrepasen los límites de las bases de datos. Cuando se utiliza DATABASE, no se utiliza la configuración de `binlog_transaction_dependency_tracking` del origen; el paralelismo viene determinado solo por la base de datos a la que se dirige la transacción.
**nota**
En MySQL versiones 8.0.26 y anteriores, el valor predeterminado de `replica_parallel_type` es `DATABASE`. A partir de MySQL 8.0.27, el valor predeterminado es `LOGICAL_CLOCK`. Si utiliza una versión anterior, defina este parámetro de forma explícita en `LOGICAL_CLOCK` para aprovechar un seguimiento de dependencias más detallado.
### Configuración de MTR
**Parámetros del origen**
| Parámetro | Valor recomendado | Notas |
| --- | --- | --- |
| binlog\_transaction\_dependency\_tracking | WRITESET | Grupo de parámetros del clúster. Dinámico. No es necesario para MySQL 8.4. |
| binlog\_transaction\_dependency\_history\_size | 25 000 (predeterminado) | Grupo de parámetros del clúster. Dinámico. Controla el número de hashes de fila que guarda el origen para el seguimiento de las dependencias de WRITESET; cuando el historial se llena o el registro binario rota, se borra y el paralelismo disminuye temporalmente. Considere la posibilidad de duplicar el valor (por ejemplo, hasta 50 000) en orígenes con un uso intensivo de escritura si la réplica muestra picos periódicos en la estadística del registro de errores “tiempo de espera en conflictos del reloj” (consulte [Estadísticas de réplicas multiprocesos de registro de errores](#aurora-mysql-replication-lag-monitoring-error-log)) que coinciden con la rotación del registro binario. Los valores más altos consumen más memoria en el origen. |
| binlog\_format | ROW | Grupo de parámetros del clúster. Estático (requiere reinicio). |
| binlog\_group\_commit\_sync\_delay | 0 (predeterminado) | Microsegundos para retrasar la confirmación del grupo. Al aumentar este valor, se agrupan más transacciones, lo que mejora el paralelismo en la réplica a costa de un ligero aumento de la latencia de confirmación en el origen. Solo es beneficioso cuando se utiliza el seguimiento de dependencias de COMMIT\_ORDER: WRITESET ya rastrea las dependencias reales por fila, independientemente del tiempo de confirmación. Dinámico. |
| binlog\_group\_commit\_sync\_no\_delay\_count | 0 (predeterminado) | Número máximo de transacciones que se deben esperar antes de la confirmación. Use con binlog\_group\_commit\_sync\_delay para limitar el retraso una vez que se hayan agrupado suficientes transacciones. Solo es relevante para el seguimiento de dependencias de COMMIT\_ORDER. Dinámico. |
**Parámetros de la réplica**
| Parámetro | Valor recomendado | Notas |
| --- | --- | --- |
| replica\_parallel\_workers | Comienzo con el recuento de vCPU, hasta el doble del recuento de vCPU | Grupo de parámetros de instancia. Dinámico pero requiere reiniciar la replicación. El valor predeterminado de la comunidad es 4 a partir de la versión 8.0.27 de MySQL (y las versiones de Aurora MySQL 3 basadas en él); en las versiones anteriores, el valor predeterminado es 0, que queda obsoleto a partir de la versión 8.0.30 de MySQL. Recomendamos empezar con el recuento de vCPU y, a continuación, supervisar el uso de la CPU y la estadística del registro de errores “Tiempo de espera (recuento) cuando los trabajadores estaban ocupados” (consulte [Estadísticas de réplicas multiprocesos de registro de errores](#aurora-mysql-replication-lag-monitoring-error-log)). Aumente solo cuando “Tiempo de espera (recuento) cuando los trabajadores estaban ocupados” sea coherentemente alto y el uso de la CPU se mantenga por debajo del 80 %. |
| replica\_parallel\_type | LOGICAL\_CLOCK | Grupo de parámetros del clúster. Dinámico pero requiere reiniciar la replicación. |
| replica\_pending\_jobs\_size\_max | >= max\_allowed\_packet en el origen | Grupo de parámetros de instancia. Dinámico. |
| replica\_preserve\_commit\_order | ON | Grupo de parámetros del clúster. Dinámico pero requiere reiniciar la replicación. |
| binlog\_format | OFF | Grupo de parámetros del clúster. Estático. Extensión específica de Aurora para desactivar el registro binario. |
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.
| Característica | Versión | Predeterminado | Cómo habilitar / verificar |
| --- | --- | --- | --- |
| Registro de transmisiones en memoria | Aurora MySQL 3.10\+ | ACTIVADO (para la replicación administrada por Aurora cuando se cumplen las condiciones) | Habilitada automáticamente para la replicación administrada por Aurora (implementaciones azul/verde, réplicas de Aurora a Aurora y réplicas entre regiones) cuando la réplica utiliza la replicación de un solo subproceso (replica\_parallel\_workers=0), la replicación multiproceso con el modo GTID y el posicionamiento automático activado, o la replicación basada en archivos con replica\_preserve\_commit\_order=ON. Se controla mediante el parámetro dinámico aurora\_in\_memory\_relaylog (nivel de clúster de base de datos o de instancia): detenga la replicación, configúrela en ON o OFF en el grupo de parámetros y, a continuación, reinicie la replicación; no es necesario reiniciar la instancia. No disponible en Aurora Serverless. Compruebe el estado actual con SHOW GLOBAL STATUS LIKE 'Aurora\_in\_memory\_relaylog\_status'. Para obtener más información, consulte [Registro de transmisiones en memoria](binlog-optimization.md#binlog-optimization-in-memory-relay-log). |
| Cambios paralelos de índice secundario | Aurora MySQL 3.06\+ | DESACTIVADO (0) | Establezca aurora\_binlog\_replication\_sec\_index\_parallel\_workers en el número de subprocesos deseado. Detenga la replicación, establezca el parámetro y, a continuación, inicie la replicación. No es necesario reiniciar la instancia. Para obtener más información, consulte [Replicación de registros binarios de varios subprocesos](binlog-optimization.md#binlog-optimization-multithreading). |
| Caché de E/S de binlog | Aurora MySQL 2.10\+ y 3.x | ACTIVADO (automático) | Habilitado automáticamente. Reduce la E/S del disco en el origen al enviar eventos de registro binario a las réplicas. No se necesita configuración. Para obtener más información, consulte [Optimización de replicación binlog](binlog-optimization.md#binlog-optimization-binlog-io-cache). |
## 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:
+ `performance_schema.replication_applier_status_by_worker`: muestra los detalles de las transacciones gestionadas por cada subproceso de trabajo, incluidas las marcas temporales de aplicación y los errores.
+ `performance_schema.replication_applier_status_by_coordinator`: muestra información sobre la actividad de almacenamiento en búfer del subproceso de coordinador.
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:
+ En la consola de RDS, en la sección **Registros y eventos**, consulte el registro de errores.
+ Descarga mediante AWS CLI: `aws rds download-db-log-file-portion --db-instance-identifier --log-file-name error/mysql-error-running.log`
+ Si la exportación de Registros de CloudWatch está habilitada para el registro de errores, busque en el grupo de registro exportado.
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:
| Campo | Descripción | Action |
| --- | --- | --- |
| segundos transcurridos | Tiempo en segundos desde la última salida de las estadísticas. Aurora MySQL no escribe estadísticas a intervalos regulares, sino que las escribe en función del número de eventos ejecutados más el tiempo transcurrido. | Se utiliza para calcular el rendimiento: eventos asignados / segundos transcurridos = promedio de eventos por intervalo. |
| eventos asignados | Número de eventos asignados por el subproceso de coordinador a los subprocesos de trabajo desde la última salida. | Supervise los cambios en el rendimiento de la replicación a lo largo del tiempo. |
| Colas de trabajadores llenadas por encima del nivel de saturación | El número de eventos en cola para los subprocesos de trabajo supera el nivel de saturación (el 90 % de la longitud máxima de la cola, que es de 16 384 eventos). Si es cero, ningún trabajador está operando al máximo de su capacidad. | Indica que los trabajadores no pueden seguir el ritmo del coordinador. Compruebe si hay transacciones de larga duración o índices faltantes. |
| Tiempo de espera debido a que la cola de trabajadores estaba llena | Número de veces que el coordinador tuvo que esperar porque la cola de un subproceso de trabajo estaba llena (se alcanzó el 100 % de su capacidad). | Compruebe si hay transacciones de larga duración, índices faltantes o contención de bloqueos en los subprocesos de trabajo. |
| Tiempo de espera debido al tamaño total | Número de veces que el coordinador esperó porque se alcanzó el límite de replica\_pending\_jobs\_size\_max. Si un evento inusualmente grande supera este tamaño, la transacción se retiene hasta que todos los trabajadores tengan colas vacías. | Aumente replica\_pending\_jobs\_size\_max. Compruebe si hay transacciones grandes en el origen. |
| Tiempo de espera por conflictos de reloj | Número de nanosegundos que esperó el coordinador porque una transacción dependía de otra transacción que aún no se había confirmado. Esto cuantifica el tiempo en que no se pudieron asignar los eventos debido a las dependencias. | Cambie al seguimiento de dependencias de WRITESET en el origen. Asegúrese de que las tablas tengan claves principales. Se esperan algunos conflictos de espera con el reloj; concéntrese en reducir la proporción en relación con otras esperas. |
| Tiempo de espera (recuento) cuando los trabajadores estaban ocupados | Número de veces que el coordinador tuvo que asignar el primer evento de una transacción, pero todas las colas de trabajadores no estaban vacías. El coordinador espera hasta que se vacíe una cola. | Esto indica que replica\_parallel\_workers está insuficientemente aprovisionado. Las dependencias no son el cuello de botella: podría haber ejecutado más eventos en paralelo, pero no había subprocesos de trabajo disponibles. Aumente replica\_parallel\_workers. |
| Tiempo de espera cuando los trabajadores estaban ocupados | Total de nanosegundos que el coordinador estuvo en espera mientras aguardaba una cola de trabajadores vacía. | Los valores altos confirman que la capacidad de los trabajadores es el cuello de botella. Aumente replica\_parallel\_workers. |
### 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](#aurora-mysql-replication-lag-identifying)) 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](#aurora-mysql-replication-lag-monitoring-error-log)):
```
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:
+ **tiempo de espera cuando los trabajadores estaban ocupados = 110293847000** nanosegundos o aproximadamente 110 segundos. De los 123 segundos de este intervalo, el coordinador pasó aproximadamente el 90 % de su tiempo esperando a que se liberara un subproceso de trabajador.
+ **Tiempo de espera en conflictos de reloj = 8455000** nanosegundos, es decir, aproximadamente 0,008 segundos, lo cual es insignificante. Las dependencias entre las transacciones no son el factor limitante.
**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](#aurora-mysql-replication-lag-monitoring-perf-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
```
+ **tiempo de espera en conflictos de reloj = 98712340000** nanosegundos, es decir, aproximadamente 99 de los 120 segundos. El coordinador pasó alrededor del 82 % del intervalo sin poder tramitar la siguiente transacción porque dependía de que se siguiera aplicando alguna.
+ **tiempo de espera cuando los trabajadores estaban ocupados = 1209847000** nanosegundos o aproximadamente 1,2 segundos. Los trabajadores casi siempre estaban libres, por lo que tener más trabajadores no ayuda.
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](#aurora-mysql-replication-lag-sql-thread)). 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](#aurora-mysql-replication-lag-sql-thread):
```
+--------------+----------------+
| 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](#aurora-mysql-replication-lag-sql-thread)).
**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)](#aurora-mysql-replication-lag-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
1. Configure las alarmas de CloudWatch en la métrica `ReplicaLag` con los umbrales adecuados.
1. Utilice tablas de latidos para medir el retraso con mayor precisión que `Seconds_Behind_Source`. Por ejemplo, use `pt-heartbeat`, que requiere una instalación independiente (consulte el [kit de herramientas de Percona](https://docs.percona.com/percona-toolkit/) en el sitio web de Percona).
1. Supervise la métrica de CloudWatch `SumBinaryLogSize` en el origen para realizar un seguimiento de la tasa de generación de registros binarios.
1. Habilite las exportaciones de registros de Registros de CloudWatch para el registro de errores a fin de retener las estadísticas de réplicas multiprocesos.
1. Utilice la supervisión mejorada para la utilización de CPU, memoria y E/S en el origen y en la réplica.
1. Utilice Información sobre las bases de datos de Amazon CloudWatch para identificar los principales eventos de espera y las consultas que provocan la contención de recursos. Información de rendimiento finaliza su ciclo de vida el 31 de julio de 2026; después de esa fecha, la consola de Información de rendimiento redirige a Información sobre las bases de datos de CloudWatch. Elija el modo de Información de base de datos que mejor se adapte a sus necesidades: el modo estándar conserva la experiencia y los precios básicos de la supervisión, mientras que el modo avanzado agrega la supervisión por flota, el diagnóstico de bloqueos y la captura del plan de ejecución. Para obtener más información, consulte [Supervisión de la carga de la base de datos con Información sobre las bases de datos de Amazon CloudWatch en Amazon Aurora](USER_PerfInsights.md).
## 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.
1. **Asegúrese de que todas las tablas tengan claves principales**: sin claves principales, la réplica realiza análisis completos de la tabla para cada fila modificada en las operaciones UPDATE y DELETE. Para obtener más información, consulte [Solución de problemas de retraso del subproceso de SQL](#aurora-mysql-replication-lag-sql-thread).
1. **Habilite la replicación multiproceso con WRITESET**: paraleliza la aplicación de SQL para transacciones independientes. Para obtener más información sobre la configuración, consulte [Replicación multiproceso (MTR)](#aurora-mysql-replication-lag-mtr).
1. **Utilice al menos la misma clase de instancia que el origen**: proporciona suficientes recursos de CPU, memoria y red para la replicación. Para obtener más información, consulte [Estrategias de optimización para el retraso de los subprocesos de E/S](#aurora-mysql-replication-lag-io-optimization).
1. **Mantenga un tamaño reducido de las transacciones**: las transacciones grandes reducen el paralelismo y aumentan la longitud de la lista de historiales. Para obtener más información, consulte [Solución de problemas de retraso del subproceso de SQL](#aurora-mysql-replication-lag-sql-thread).
1. **Desactive el registro binario en las réplicas**: configure `binlog_format=OFF` a menos que se necesite una replicación descendente. Para obtener detalles sobre los parámetros, consulte [Configuración de MTR](#aurora-mysql-replication-lag-mtr-config).
1. **Evite las transacciones y consultas prolongadas en las réplicas**: las transacciones de lectura prolongadas impiden que se purguen las listas de historiales, lo que puede degradar el rendimiento de la replicación.
1. **Habilite la replicación basada en GTID**: proporciona un seguimiento automático de la posición y habilita el registro de retransmisión en memoria de Aurora (Aurora MySQL 3.10\+). Para obtener más información, consulte [Optimizaciones de replicación específicas de Aurora](#aurora-mysql-replication-lag-aurora-optimizations).