¿Conoce dos parámetros de configuración importantes de la replicación maestro-esclavo de MySQL?

Prefacio

Cuando configuramos la replicación maestro-esclavo de MySQL, además de los parámetros de configuración necesarios, a menudo se configuran estos dos parámetros: innodb_flush_log_at_trx_commit
y sync_binlog. Echemos un vistazo al rol de este parámetro.

innodb_flush_log_at_trx_commit

Cuando confirme la transacción, escriba el registro de rehacer en el disco. El llamado registro de rehacer es para registrar los cambios que ha realizado en los datos. Por ejemplo, si cambia el valor del campo de nombre a "id = 10", esto es un registro. Si queremos confirmar una transacción, descargaremos el registro de rehacer del búfer de registro de rehacer al archivo de disco de acuerdo con una estrategia determinada. En este momento, esta estrategia se configura a través de innodb_flush_log_at_trx_commit, y tiene varias opciones.

El valor es 0: cuando se confirma la transacción, los datos en el búfer del registro de rehacer no se vacían inmediatamente en el archivo de disco, pero el hilo principal de InnoDB se descarga en el disco cada segundo. En este momento, puede confirmar la transacción y, como resultado, mysql está inactivo y luego se pierden todos los datos en la memoria.

El valor es 1: al realizar una transacción, debe vaciar el registro de rehacer de la memoria al archivo de disco. Siempre que la transacción se haya confirmado correctamente, el registro de rehacer debe estar en el disco. Tenga en cuenta que debido a la función de "escritura retrasada" del sistema operativo, el parpadeo en este momento solo se escribe en el búfer del sistema operativo, por lo que la operación de sincronización puede garantizar que se mantenga en el disco duro.

Valor 2: Al realizar la transacción, escriba el registro de rehacer en la caché del sistema operativo correspondiente al archivo de disco en lugar de ingresar directamente en el archivo de disco. Puede tomar 1 segundo escribir los datos en la caché del sistema operativo en el archivo de disco.

Se puede ver que solo 1 realmente puede garantizar la durabilidad de la transacción, pero debido a que la operación de actualización fsync () está bloqueada y no regresa hasta que se completa, sabemos que la velocidad de escritura en el disco es muy lenta, por lo que el rendimiento de MySQL será evidente en declive. Si no le importa la pérdida de transacciones, 0 y 2 pueden lograr un mayor rendimiento.

# 查询
select @@innodb_flush_log_at_trx_commit;

Inserte la descripción de la imagen aquí

sync_binlog

Este parámetro controla el proceso de escritura de registros binarios en el disco.

Los valores válidos de este parámetro son 0, 1, N:

0:默认值。事务提交后,将二进制日志从缓冲写入磁盘,但是不进行刷新操作(fsync()),此时只是写入了操作系统缓冲,若操作系统宕机则会丢失部分二进制日志。

1:事务提交后,将二进制文件写入磁盘并立即执行刷新操作,相当于是同步写入磁盘,不经过操作系统的缓存。

N:每写N次操作系统缓冲就执行一次刷新操作。

Establecer este parámetro en un valor superior a 1 mejorará el rendimiento de la base de datos, pero también estará acompañado por el riesgo de pérdida de datos.

Los archivos de registro binarios implican la recuperación de datos, y si desea lograr la máxima coherencia entre el maestro y el esclavo, debe establecer este parámetro en 1, pero también provocará una cierta pérdida de rendimiento.

Supongo que te gusta

Origin blog.csdn.net/qq_36551991/article/details/111462474
Recomendado
Clasificación