# Optimización de la replicación de registros binarios para Aurora MySQL A continuación, puede aprender a optimizar el rendimiento de replicación de registros binarios y solucionar problemas relacionados en Aurora MySQL. **sugerencia** Esta discusión supone que está familiarizado con el mecanismo de replicación del registro binario de MySQL y cómo funciona. Para obtener información de fondo, consulte [Implementación de replicación](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) en la documentación de MySQL. ## Replicación de registros binarios de varios subprocesos Con la replicación de registros binarios de múltiples procesos, un subproceso SQL lee los eventos del registro de retransmisión y los pone en cola para que se apliquen los subprocesos de trabajo de SQL. Los subprocesos de trabajo SQL se administran mediante el subproceso coordinador. Los eventos de registros binarios se aplican en paralelo cuando es posible. El nivel de paralelismo depende de factores como la versión, los parámetros, el diseño del esquema y las características de la carga de trabajo. La replicación de registros binarios de varios subprocesos se admite en la versión 3 de Aurora MySQL y la versión 2.12.1 de Aurora MySQL y versiones posteriores. Para que una réplica multiproceso procese de forma eficiente los eventos binlog en paralelo, debe configurar el origen para la replicación de registro binario multiproceso y el origen debe utilizar una versión que incluya la información de paralelismo en los archivos de registro binarios. Cuando se configura una instancia de base de datos de Aurora MySQL para utilizar la replicación de registros binarios, la instancia de réplica utiliza de forma predeterminada la replicación de un solo subproceso para las versiones de Aurora MySQL anteriores a la 3.04. Para habilitar la replicación de múltiples procesos, actualice el parámetro `replica_parallel_workers` con un valor superior a `1` en el grupo de parámetros personalizados. En la versión 3.04 y las versiones posteriores de Aurora MySQL, la replicación es multiproceso de forma predeterminada y `replica_parallel_workers` está establecido en `4`. Puede modificar este parámetro en su grupo de parámetros personalizado. Para aumentar la resiliencia de la base de datos frente a paradas inesperadas, le recomendamos que habilite la replicación de GTID en el origen y permita GTID en la réplica. Para permitir la replicación de GTID, establezca `gtid_mode` en `ON_PERMISSIVE` tanto en el origen como en la réplica. Para obtener más información sobre la replicación basada en GTID, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md). Las siguientes opciones de configuración le ayudan a ajustar la replicación de múltiples procesos. Para obtener más información, consulte [Opciones y variables de replicación y registro binario](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) en el *Manual de referencia de MySQL*. Para obtener más información sobre la replicación multiproceso, consulte el blog de MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/). Los valores óptimos de los parámetros dependen de varios factores. Por ejemplo, el rendimiento de la replicación de registros binarios se ve afectado por las características de la carga de trabajo de la base de datos y la clase de instancia de base de datos en la que se ejecuta la réplica. Por lo tanto, le recomendamos que pruebe detenidamente todos los cambios en estos parámetros de configuración antes de aplicar la nueva configuración de parámetros a una instancia de producción. + `binlog_format recommended value` – se establece como `ROW` + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_transaction_dependency_history_size` + `binlog_transaction_dependency_tracking`: el valor recomendado es `WRITESET` + `replica_preserve_commit_order` + `replica_parallel_type`: el valor recomendado es `LOGICAL_CLOCK` + `replica_parallel_workers` + `replica_pending_jobs_size_max` + `transaction_write_set_extraction`: el valor recomendado es `XXHASH64` El esquema y las características de la carga de trabajo son factores que afectan la replicación en paralelo. Los factores más comunes son los siguientes. + Ausencia de claves principales: RDS no puede establecer la dependencia de conjunto de escrituras para tablas sin claves principales. Con el formato `ROW`, se puede lograr una sola instrucción de varias filas con un solo escaneo completo de la tabla en el origen, pero da como resultado un análisis completo de la tabla por cada fila modificada en la réplica. La ausencia de claves principales disminuye significativamente el rendimiento de la replicación. + Presencia de claves externas: si hay claves externas, Amazon RDS no puede utilizar la dependencia de conjunto de escrituras para el paralelismo de las tablas con la relación FK. + Tamaño de las transacciones: si una sola transacción abarca decenas o cientos de megabytes o gigabytes, el subproceso coordinador y uno de los subprocesos de trabajo podrían tardar mucho tiempo en procesar solo esa transacción. Durante ese tiempo, todos los demás hilos de los trabajadores pueden permanecer inactivos después de que concluyan el procesamiento de las transacciones anteriores. En Aurora MySQL versión  3.06 y versiones posteriores, puede mejorar el rendimiento de las réplicas de registros binarios al replicar transacciones para tablas grandes con más de un índice secundario. Esta característica introduce un grupo de subprocesos para aplicar cambios de índice secundarios en paralelo en una réplica de binlog. La característica se controla mediante el parámetro del clúster de base de datos `aurora_binlog_replication_sec_index_parallel_workers`, que controla el número total de subprocesos paralelos disponibles para aplicar los cambios de índice secundarios. El parámetro está establecido en `0` (deshabilitado) de forma predeterminada. Para habilitar esta característica, no es necesario reiniciar la instancia. Para habilitar esta característica, detenga la replicación en curso, establezca el número deseado de subprocesos de trabajo paralelos y, a continuación, vuelva a iniciar la replicación. ## Optimización de replicación binlog En Aurora MySQL versión 2.10 y versiones posteriores, Aurora aplica automáticamente una optimización conocida como caché de E/S de binlog a la reproducción de registros binarios. Al almacenar en caché los eventos de binlog confirmados más recientemente, esta optimización se ha diseñado para mejorar el rendimiento del subproceso de copia de datos de binlog y, a la vez, limitar el impacto de las transacciones en primer plano en la instancia de origen de binlog. **nota** La memoria utilizada para esta característica es independiente de la configuración `binlog_cache` de MySQL. Esta característica no se aplica a las instancias de base de datos de Aurora que utilizan las clases de instancias `db.t2` y `db.t3`. No es necesario ajustar ningún parámetro de configuración para activar esta optimización. En particular, si ajusta el parámetro de configuración `aurora_binlog_replication_max_yield_seconds` a un valor distinto de cero en versiones anteriores de Aurora MySQL, vuelva a establecerlo en cero para las versiones disponibles actualmente. Las variables de estado `aurora_binlog_io_cache_reads` y `aurora_binlog_io_cache_read_requests` lo ayudan a supervisar la frecuencia con que se leen los datos de la caché de E/S de binlog. + `aurora_binlog_io_cache_read_requests` muestra el número de solicitudes de lectura de E/S de binlog de la caché. + `aurora_binlog_io_cache_reads` muestra el número de lecturas de E/S de binlog que recuperan información de la caché. La siguiente consulta SQL calcula el porcentaje de solicitudes de lectura de binlog que aprovechan la información almacenada en caché. En este caso, cuanto más cerca esté la proporción de 100, mejor será. ``` mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+ ``` La característica de caché de E/S de binlog también incluye métricas nuevas relacionadas con los subprocesos de copia de datos de binlog. Los *subprocesos de volcado* son los subprocesos que se crean cuando se conectan réplicas de binlog nuevas a la instancia de origen de binlog. Las métricas de subprocesos de copia de datos se imprimen en el registro de la base de datos cada 60 segundos con el prefijo `[Dump thread metrics]`. Las métricas incluyen información para cada réplica de binlog como `Secondary_id`, `Secondary_uuid`, el nombre del archivo de binlog y la posición que lee cada réplica. Las métricas también incluyen `Bytes_behind_primary`, que representan la distancia en bytes entre el origen de la reproducción y la réplica. Esta métrica mide el retraso del subproceso de E/S de réplica. Esta cifra es diferente del retraso del subproceso del aplicador SQL de la réplica, que se representa mediante la métrica `seconds_behind_master` de la réplica de binlog. Puede determinar si las réplicas de binlog alcanzan al origen o se quedan atrás al comprobar si la distancia disminuye o aumenta. ## Registro de transmisiones en memoria En Aurora MySQL versión 3.10 y versiones posteriores, Aurora presenta una optimización conocida como registro de transmisiones en memoria para mejorar el rendimiento de la replicación. Esta optimización mejora el rendimiento de E/S de los registros de transmisiones al almacenar en caché todo el contenido de los registros de transmisiones intermedios en la memoria. Como resultado, reduce la latencia de confirmación al minimizar las operaciones de E/S del almacenamiento, ya que el contenido del registro de transmisiones permanece fácilmente accesible en la memoria. De forma predeterminada, la característica de registro de transmisiones en memoria se habilita automáticamente para los escenarios de replicación administrados por Aurora (incluidas las implementaciones azul/verde, la replicación de Aurora-Aurora y las réplicas entre regiones) cuando la réplica cumple alguna de estas configuraciones: + Modo de replicación de un solo subproceso (replica\$1parallel\$1workers = 0) + Replicación multiproceso con el modo GTID activado: + Posicionamiento automático habilitado + El modo GTID está activado en la réplica + Replicación basada en archivos con replica\$1preserve\$1commit\$1order = ON La característica de registro de transmisión en memoria se admite en clases de instancias superiores a t3.large, pero no está disponible en las instancias de Aurora Serverless. El búfer circular del registro de transmisión tiene un tamaño fijo de 128 MB. Para supervisar el consumo de memoria de esta característica, puede ejecutar la siguiente consulta: ``` SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache'; ``` La característica de registro de transmisión en memoria se controla mediante el parámetro aurora\$1in\$1memory\$1relaylog, que se puede configurar en el clúster o instancia de base de datos. Puede habilitar o desactivar esta característica de forma dinámica sin reiniciar la instancia: 1. Detención de la replicación en curso 1. Establecimiento de aurora\$1in\$1memory\$1relaylog en ON (para habilitar) u OFF (para desactivar) en el grupo de parámetros 1. Reinicio de la replicación Ejemplo: ``` CALL mysql.rds_stop_replication; set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group CALL mysql.rds_start_replication; ``` Incluso cuando aurora\$1in\$1memory\$1relaylog esté ON, es posible que la característica de registro de transmisión en memoria siga desactivada en determinadas condiciones. Para comprobar el estado actual de la característica, puede usar el siguiente comando: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status'; ``` Si la característica se desactiva de forma inesperada, puede identificar el motivo ejecutando lo siguiente: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason'; ``` Este comando devuelve un mensaje que explica por qué la característica está desactivada actualmente.