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 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 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.

• binlog_group_commit_sync_delay

• binlog_group_commit_sync_no_delay_count

• binlog_transaction_dependency_history_size

• binlog_transaction_dependency_tracking

• replica_preserve_commit_order

• replica_parallel_type

• replica_parallel_workers

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.

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 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.

• 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.

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.

• aurora_binlog_use_large_read_buffer

• aurora_binlog_read_buffer_size

• aurora_binlog_replication_max_yield_seconds

nota

Para clústeres compatibles con MySQL 5.7, puede usar estos parámetros en las versiones 2 a 2.09.* de Aurora MySQL. En Aurora MySQL 2.10.0 y versiones posteriores, estos parámetros se sustituyen por la optimización de la caché de E/S de binlog y no es necesario usarlos.

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.

nota

Antes de ajustar estos parámetros, mida la latencia y el rendimiento de la transacción a lo largo del tiempo. Es posible que descubra que el rendimiento de la replicación de registros binarios es estable y tiene baja latencia incluso si hay contención ocasional.

aurora_binlog_use_large_read_buffer

Si este parámetro se establece en 1, Aurora MySQL optimiza la replicación del registro binario en función de la configuración de los parámetros aurora_binlog_read_buffer_size y aurora_binlog_replication_max_yield_seconds. Si aurora_binlog_use_large_read_buffer es 0, Aurora MySQL ignora los valores de los parámetros aurora_binlog_read_buffer_size y aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Los subprocesos de volcado de registros binarios con un búfer de lectura más grande minimizan la cantidad de operaciones de E/S de lectura al leer más eventos para cada E/S. El parámetro aurora_binlog_read_buffer_size establece el tamaño del búfer de lectura. El búfer de lectura grande puede reducir la contención de logs binarios para cargas de trabajo que generan una gran cantidad de datos de binlog.

nota

Este parámetro solo tiene un efecto cuando el clúster también tiene la configuración aurora_binlog_use_large_read_buffer=1.

Aumentar el tamaño del búfer de lectura no afecta al rendimiento de la replicación de registros binarios. Los subprocesos de volcado de registro binario no esperan a que las transacciones de actualización llenen el búfer de lectura.

aurora_binlog_replication_max_yield_seconds

Si la carga de trabajo requiere una latencia de transacción baja y puede tolerar algún retraso de replicación, puede aumentar el parámetro aurora_binlog_replication_max_yield_seconds. Este parámetro controla la propiedad de rendimiento máximo de la replicación de registros binarios en el clúster.

nota

Este parámetro solo tiene un efecto cuando el clúster también tiene la configuración aurora_binlog_use_large_read_buffer=1.

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.

Parámetro	Valor predeterminado	Valores válidos	Descripción
aurora_binlog_use_large_read_buffer	1	0, 1	Conmutador para activar la característica de mejora de replicación. Cuando es 1, el subproceso de volcado de registro binario utiliza aurora_binlog_read_buffer_size para la replicación del registro binario; de lo contrario, se utiliza el tamaño de búfer predeterminado (8K). No se utiliza en la versión 3 de Aurora MySQL.
aurora_binlog_read_buffer_size	5242880	8192-536870912	Tamaño del búfer de lectura utilizado por el subproceso de volcado de registro binario cuando el parámetro aurora_binlog_use_large_read_buffer se establece en 1. No se utiliza en la versión 3 de Aurora MySQL.
aurora_binlog_replication_max_yield_seconds	0	0-36000	El valor máximo aceptado para las versiones 2.07.* de Aurora MySQL es 45. Puede ajustarlo a un valor más alto en las versiones 2.09 y posteriores. Para la versión 2, este parámetro solo funciona cuando el parámetro aurora_binlog_use_large_read_buffer está establecido en 1.

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.

Para activar la optimización de binlog de rendimiento máximo para un clúster de Aurora MySQL

1. Cree o edite un grupo de parámetros del clúster de base de datos con la siguiente configuración de parámetros:

   • aurora_binlog_use_large_read_buffer: activar con un valor de ON o 1.

   • aurora_binlog_replication_max_yield_seconds: especifique un valor mayor que 0.

2. Asocie el grupo de parámetros de clúster de base de datos con el clúster Aurora MySQL que funciona como origen binlog. Para ello, siga los procedimientos en Grupos de parámetros para Amazon Aurora.

3. Confirme que el cambio de parámetro surte efecto. Para ello, ejecute la siguiente consulta en la instancia de origen binlog.

   SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

   El resultado debería ser similar al siguiente.

   +---------------------------------------+-----------------------------------------------+
   | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
   +---------------------------------------+-----------------------------------------------+
   |                                     1 |                                            45 |
   +---------------------------------------+-----------------------------------------------+
   

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.

Para desactivar la optimización de rendimiento máximo para un clúster Aurora MySQL

1. Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de Aurora MySQL disponga de aurora_binlog_replication_max_yield_seconds establecido en 0. Para obtener más información sobre el establecimiento de parámetros de configuración con grupos de consultas, consulte Grupos de parámetros para Amazon Aurora.

2. Confirme que el cambio de parámetro surte efecto. Para ello, ejecute la siguiente consulta en la instancia de origen binlog.

   SELECT @@aurora_binlog_replication_max_yield_seconds;

   El resultado debería ser similar al siguiente.

   +-----------------------------------------------+
   | @@aurora_binlog_replication_max_yield_seconds |
   +-----------------------------------------------+
   |                                             0 |
   +-----------------------------------------------+
   

Desactivación del búfer de lectura grande

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

Para desactivar el búfer de lectura de registro binario grande para un clúster Aurora MySQL

1. Restablezca aurora_binlog_use_large_read_buffer en OFF o 0.

   Asegúrese de que el grupo de parámetros de clúster de base de datos asociado al clúster de Aurora MySQL disponga de aurora_binlog_use_large_read_buffer establecido en 0. Para obtener más información sobre el establecimiento de parámetros de configuración con grupos de consultas, consulte Grupos de parámetros para Amazon Aurora.

2. En la instancia de origen binlog, ejecute la siguiente consulta.

   SELECT @@ aurora_binlog_use_large_read_buffer;

   El resultado debería ser similar al siguiente.

   +---------------------------------------+
   | @@aurora_binlog_use_large_read_buffer |
   +---------------------------------------+
   |                                     0 |
   +---------------------------------------+