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.
Temas
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/a | 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 predeterminado134217728
se ajusta automáticamente a268435456
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 cuandoApplyMethod
esté enimmediate
.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)
El binlog mejorado se desactiva después de mysql-bin-changelog.000003
. 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:
El binlog mejorado se desactiva después de mysql-bin-changelog.000003
. 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 Soporte.
-
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.