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.

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 un subproceso coordinador. Los eventos de registros binarios se aplican en paralelo cuando es posible.

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.

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 cero en el grupo de parámetros personalizado.

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.

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 en el Manual de referencia de MySQL.

La configuración óptima depende 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.

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.

También puede utilizar este parámetro como variable global, donde n es el número de subprocesos de trabajo paralelos:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Optimización de la reproducción binlog (Aurora MySQL 2.10 y versiones posteriores)

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.

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 Aurora MySQL 2.10 o versiones posteriores.

Las variables de estado aurora_binlog_io_cache_reads y aurora_binlog_io_cache_read_requests se encuentran disponibles en Aurora MySQL 2.10 y versiones posteriores. Estas variables de estado lo ayudan a monitorear la frecuencia con que se leen los datos de la caché de E/S de binlog.

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.

Optimización de la replicación de binlog (Aurora MySQL versión 2 a 2.09)

Para optimizar la replicación de registros binarios para Aurora MySQL, ajuste los siguientes parámetros de optimización a nivel de clúster. Estos parámetros le ayudan a especificar el equilibrio correcto entre la latencia en la instancia de origen binlog y el retraso de replicación.

Descripción general del búfer de lectura grande y optimizaciones de rendimiento máximo

Es posible que experimente un rendimiento reducido de replicación de registros binarios cuando el subproceso de volcado de registros binarios accede al volumen del clúster Aurora mientras el clúster procesa un gran número de transacciones. Puede utilizar los parámetros aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds y aurora_binlog_read_buffer_size para ayudar a minimizar este tipo de contención.

Supongamos que tiene una situación en la que aurora_binlog_replication_max_yield_seconds está establecido en mayor que 0 y el archivo binlog actual del subproceso de volcado está activo. En este caso, el subproceso de volcado de registro binario espera un número especificado de segundos para llenar el archivo binlog actual con transacciones. Este período de espera evita la contención que puede surgir al replicar cada evento binlog individualmente. Sin embargo, al hacerlo aumenta el retraso de réplica para las réplicas de registros binarios. Esas réplicas pueden quedarse atrás de la fuente en el mismo número de segundos que la configuración aurora_binlog_replication_max_yield_seconds.

El archivo binlog actual significa el archivo binlog que el subproceso de volcado está leyendo actualmente para realizar la replicación. Consideramos que un archivo binlog está activo cuando el archivo binlog se está actualizando o abierto para ser actualizado por transacciones entrantes. Después de que Aurora MySQL llena el archivo binlog activo, MySQL crea y cambia a un nuevo archivo binlog. El antiguo archivo binlog se vuelve inactivo. Ya no se actualiza mediante transacciones entrantes.

Aurora MySQL reconoce inmediatamente cualquier cambio en el valor del aurora_binlog_replication_max_yield_seconds parámetro. No necesita reiniciar la instancia de base de datos. Sin embargo, cuando activa esta configuración, el subproceso de volcado solo comienza a rendir cuando el archivo binlog actual alcanza su tamaño máximo de 128 MB y se gira a un nuevo archivo.

Parámetros relacionados

Utilice los siguientes parámetros de clúster de base de datos para activar la optimización de binlog.

Activación del mecanismo de rendimiento máximo de replicación de registros binarios

Puede activar la optimización de rendimiento máximo de replicación de registros binarios de la siguiente manera. Al hacerlo, se minimiza la latencia de las transacciones en la instancia de origen binlog. Sin embargo, es posible que experimente un mayor retraso en la replicación.

Desactivación de la optimización de rendimiento máximo de replicación de registros binarios

Puede desactivar la optimización de rendimiento máximo de replicación de registro binario de la siguiente manera. Al hacerlo, se minimiza el retraso de replicación. Sin embargo, es posible que experimente una latencia mayor para las transacciones en la instancia de origen binlog.

Desactivación del búfer de lectura grande

Puede desactivar toda la característica de búfer de lectura grande de la siguiente manera.