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
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.
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
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 comoROW. -
binlog_group_commit_sync_delay -
binlog_group_commit_sync_no_delay_count -
binlog_transaction_dependency_history_size -
binlog_transaction_dependency_tracking: el valor recomendado esWRITESET -
replica_preserve_commit_order -
replica_parallel_type: el valor recomendado esLOGICAL_CLOCK -
replica_parallel_workers -
replica_pending_jobs_size_max -
transaction_write_set_extraction: el valor recomendado esXXHASH64
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_requestsmuestra el número de solicitudes de lectura de E/S de binlog de la caché. -
aurora_binlog_io_cache_readsmuestra 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.
