Configuración del binlog mejorado para Aurora MySQL - Amazon Aurora
Configuración de los parámetros del binlog mejoradoOtros parámetros relacionadosDiferencias entre el binlog mejorado y el binlog comunitario de MySQLMétricas de Amazon CloudWatch para un binlog mejoradoLimitaciones del binlog mejorado

Configuración del binlog mejorado para Aurora MySQL

El binlog mejorado reduce la sobrecarga de rendimiento de computación provocada por la activación del binlog, que puede alcanzar hasta un 50 % en algunos casos. Con el binlog mejorado, esta sobrecarga se puede reducir a aproximadamente un 13 %. Para reducir la sobrecarga, el binlog mejorado escribe los registros binarios y de transacciones en el almacenamiento en paralelo, lo que minimiza los datos escritos en el momento de la confirmación de la transacción.

El uso del binlog mejorado también mejora el tiempo de recuperación de la base de datos después de los reinicios y las conmutaciones por error hasta en un 99 % en comparación con el binlog comunitario de MySQL. El binlog mejorado es compatible con las cargas de trabajo basadas en binlogs existentes y usted interactúa con él de la misma manera que interactúa con el binlog de MySQL de la comunidad.

El binlog mejorado está disponible en la versión 3.03.1 de Aurora MySQL y versiones posteriores.

Configuración de los parámetros del binlog mejorado

Puede cambiar entre el binlog comunitario de MySQL y el binlog mejorado activando o desactivando los parámetros del binlog mejorado. Los usuarios actuales del binlog pueden seguir leyendo y consumiendo los archivos binlog sin lagunas en la secuencia de archivos binlog.

Para activar el binlog mejorado, defina los siguientes parámetros:

Parámetro Predeterminado Descripción
binlog_format – Establezca el parámetro binlog_format en el formato de registro binario de su elección para activar el registro mejorado. Asegúrese de que binlog_format parameter no esté desactivado. Para obtener más información, consulte Configuración del registro binario de Aurora MySQL.
aurora_enhanced_binlog 0 Establezca el valor de este parámetro en 1 en el grupo de parámetros del clúster de base de datos asociado al clúster de Aurora MySQL. Al cambiar el valor de este parámetro, debe reiniciar la instancia del escritor cuando el valor DBClusterParameterGroupStatus aparezca como pending-reboot.
binlog_backup 1 Desactive este parámetro para activar el binlog mejorado. Para ello, establezca el valor de este parámetro en 0.
binlog_replication_globaldb 1 Desactive este parámetro para activar el binlog mejorado. Para ello, establezca el valor de este parámetro en 0.
importante

Puede desactivar los parámetros binlog_backup y binlog_replication_globaldb solo si usa el binlog mejorado.

Para desactivar el binlog mejorado, defina los siguientes parámetros:

Parámetro Descripción
aurora_enhanced_binlog Establezca el valor de este parámetro en 0 en el grupo de parámetros del clúster de base de datos asociado al clúster de Aurora MySQL. Al cambiar el valor de este parámetro, debe reiniciar la instancia del escritor cuando el valor DBClusterParameterGroupStatus aparezca como pending-reboot.
binlog_backup Desactive este parámetro cuando desactive el binlog mejorado. Para ello, establezca el valor de este parámetro en 1.
binlog_replication_globaldb Desactive este parámetro cuando desactive el binlog mejorado. Para ello, establezca el valor de este parámetro en 1.

Para comprobar si el binlog mejorado está activado, utilice el siguiente comando en el cliente MySQL:

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)

Cuando el binlog mejorado está activado, el resultado muestra ACTIVE para aurora_enhanced_binlog.

Otros parámetros relacionados

Al activar el binlog mejorado, se ven afectados los siguientes parámetros:

  • El parámetro max_binlog_size está visible pero no se puede modificar. El valor predeterminado 134217728 se ajusta automáticamente a 268435456 cuando se activa el binlog mejorado.

  • A diferencia del binlog comunitario de MySQL, binlog_checksum no actúa como parámetro dinámico cuando el binlog mejorado está activado. Para que el cambio en este parámetro surta efecto, debe reiniciar manualmente el clúster de base de datos incluso cuando ApplyMethod esté en immediate.

  • El valor que establezca en el parámetro binlog_order_commits no afecta al orden de las confirmaciones cuando el binlog mejorado está activado. Las confirmaciones siempre se ordenan sin afectar al rendimiento.

Diferencias entre el binlog mejorado y el binlog comunitario de MySQL

El binlog mejorado interactúa de manera diferente con los clones, las copias de seguridad y la base de datos global de Aurora en comparación con el binlog comunitario de MySQL. Recomendamos que entienda las siguientes diferencias antes de usar el binlog mejorado.

  • Los archivos binlog mejorados del clúster de base de datos de origen no están disponibles en un clúster de base de datos clonado.

  • Los archivos binlog mejorados no se incluyen en las copias de seguridad de Aurora. Por lo tanto, los archivos binlog mejorados del clúster de base de datos de origen no están disponibles después de restaurar un clúster de base de datos, a pesar del período de retención establecido en él.

  • Cuando se usan con una base de datos global de Aurora, los archivos binlog mejorados del clúster de base de datos principal no se replican en el clúster de base de datos de las regiones secundarias.

Ejemplos

En los siguientes ejemplos, se muestra la diferencia entre el binlog mejorado y el binlog comunitario de MySQL.

En un clúster de base de datos restaurado o clonado

Cuando el binlog mejorado está activado, los archivos binlog históricos no están disponibles en el clúster de base de datos restaurado o clonado. Tras una operación de restauración o clonación, si el binlog está activado, el nuevo clúster de base de datos comienza a escribir su propia secuencia de archivos binlog, empezando por 1 (mysql-bin-changelog.000001).

Para activar el binlog mejorado después de una operación de restauración o clonación, defina los parámetros del clúster de base de datos requeridos en el clúster de base de datos restaurado o clonado. Para obtener más información, consulte Configuración de los parámetros del binlog mejorado.

ejemplo Ejemplo: operación de clonación o restauración cuando el binlog mejorado está activado

Clúster de base de datos de origen:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

En un clúster de base de datos restaurado o clonado, no se realizan copias de seguridad de los archivos binlog cuando se activa el binlog mejorado. Para evitar la discontinuidad en los datos del binlog, tampoco están disponibles los archivos binlog escritos antes de activar el binlog mejorado. 

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
ejemplo Ejemplo: operación de clonación o restauración cuando el binlog mejorado está desactivado

Clúster de base de datos de origen:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

En un clúster de base de datos restaurado o clonado, los archivos binlog escritos están disponibles después de desactivar el binlog mejorado.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)

En una base de datos global de Amazon Aurora

En una base de datos global de Amazon Aurora, los datos binlog del clúster de base de datos principal no se replican en los clústeres de base de datos secundarios. Tras un proceso de conmutación por error entre regiones, los datos del binlog no están disponibles en el clúster de base de datos principal promocionado recientemente. Si el binlog está activado, el clúster de base de datos promocionado recientemente comienza a escribir su propia secuencia de archivos binlog, empezando por 1 (mysql-bin-changelog.000001).

Para activar el binlog mejorado después de la conmutación por error, debe configurar los parámetros del clúster de base de datos requeridos en el clúster de base de datos secundario. Para obtener más información, consulte Configuración de los parámetros del binlog mejorado.

ejemplo Ejemplo: la operación de conmutación por error de base de datos global se realiza cuando el binlog mejorado está activado

Clúster de base de datos principal antiguo (antes de la conmutación por error):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Nuevo clúster de base de datos principal (después de la conmutación por error):

Los archivos binlog no se replican en regiones secundarias cuando se activa el binlog mejorado. Para evitar la discontinuidad en los datos del binlog, los archivos binlog escritos antes de activar el binlog mejorado no estarán disponibles.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
ejemplo Ejemplo: la operación de conmutación por error de base de datos global se realiza cuando el binlog mejorado está desactivado

Clúster de base de datos de origen:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Clúster de base de datos restaurado o clonado:

Los archivos binlog que se escriben después de desactivar el binlog mejorado se replican y están disponibles en el clúster de base de datos promocionado recientemente.

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)

Métricas de Amazon CloudWatch para un binlog mejorado

Las siguientes métricas de Amazon CloudWatch solo se publican cuando el binlog mejorado está activado.

Métrica de CloudWatch Descripción Unidades
ChangeLogBytesUsed Es la cantidad de almacenamiento utilizada por el binlog mejorado. Bytes
ChangeLogReadIOPs Es el número de operaciones de E/S de lectura realizadas en el binlog mejorado en un intervalo de 5 minutos. Recuento cada 5 minutos
ChangeLogWriteIOPs Es el número de operaciones de E/S de escritura en disco realizadas en el binlog mejorado en un intervalo de 5 minutos. Recuento cada 5 minutos

Limitaciones del binlog mejorado

Las siguientes limitaciones se aplican a los clústeres de base de datos de Amazon Aurora cuando se activa el binlog mejorado.

  • El binlog mejorado solo es compatible en la versión 3.03.1 de Aurora MySQL y versiones posteriores.

  • Los archivos binlog mejorados escritos en el clúster de base de datos principal no se copian en los clústeres de base de datos clonados o restaurados.

  • Cuando se usan con una base de datos global de Amazon Aurora, los archivos binlog mejorados del clúster de base de datos principal no se replican en los clústeres de base de datos secundarios. Por lo tanto, tras el proceso de conmutación por error, los datos históricos del binlog no estarán disponibles en el nuevo clúster de base de datos principal.

  • Se ignoran los siguientes parámetros de configuración del binlog:

    • binlog_group_commit_sync_delay

    • binlog_group_commit_sync_no_delay_count

    • binlog_max_flush_queue_time

  • No puede eliminar ni cambiar el nombre de una tabla dañada de una base de datos. Para eliminar estas tablas, puede ponerse en contacto con AWS Support.

  • La caché de E/S del binlog se deshabilita cuando se activa el binlog mejorado. Para obtener más información, consulte Optimización de la replicación de registros binarios para Aurora MySQL.

    nota

    El binlog mejorado proporciona mejoras en el rendimiento de lectura similares a las de la caché de E/S del binlog y aún más mejoras en el rendimiento de escritura.

  • No se admite la característica Backtrack. El binlog mejorado no se puede activar en un clúster de base de datos bajo las siguientes condiciones:

    • Clúster de base de datos con la característica Backtrack activada actualmente.

    • Clúster de base de datos con la característica Backtrack activada previamente, pero ahora deshabilitada.

    • Clúster de base de datos restaurado desde un clúster de base de datos de origen o una instantánea con la característica Backtrack habilitada.