Consideraciones sobre la integridad de los datos y el rendimiento en la replicación semisincrónica de MySQL

La replicación semisincrónica de MySQL proporciona una integridad de datos mejorada porque cuando una confirmación se devuelve correctamente, se sabe que los datos existen en al menos dos lugares:el maestro y su esclavo. En esta publicación de blog, revisamos algunas de las configuraciones de hospedaje de MySQL que influyen en la integridad de los datos y en los aspectos de rendimiento de la replicación semisincrónica. Usaremos el motor de almacenamiento InnoDB y la replicación basada en GTID en un conjunto de réplicas de 3 nodos (maestro y 2 esclavos), lo que garantizará que haya redundancia en los esclavos. Esto significa que si hay problemas con un esclavo, podemos recurrir al otro.

Configuraciones aplicables a los nodos maestro y esclavo

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Estas configuraciones garantizan configuraciones de alta durabilidad y consistencia para los datos. Es decir, se garantiza que cada transacción confirmada estará presente en los registros binarios y también los registros se descargan en el disco. Por lo tanto, en el caso de una falla de energía o un bloqueo del sistema operativo, la consistencia de los datos de MySQL siempre se conserva.

Configuraciones en el Nodo Maestro.

• rpl_semi_sync_master_wait_for_slave_count:

Esta opción se usa para configurar el número de esclavos que deben enviar un reconocimiento antes de que un maestro semisíncrono pueda confirmar la transacción. En el conjunto de réplicas de 3 nodos, recomendamos establecer esto en 1, de modo que siempre tengamos la seguridad de que los datos están disponibles en al menos un esclavo mientras evitamos cualquier impacto en el rendimiento relacionado con la espera del reconocimiento de ambos esclavos.

• rpl_semi_sync_master_timeout:

Esta opción se usa para configurar la cantidad de tiempo que un maestro semisíncrono espera el reconocimiento del esclavo antes de volver al modo asíncrono. Recomendamos configurar esto en un número grande para que no haya un retroceso al modo asincrónico que luego anula nuestro objetivo de integridad de datos. Dado que estamos operando con 2 esclavos y rpl_semi_sync_master_wait_for_slave_count está establecido en 1, podemos suponer que al menos uno de los esclavos reconoce dentro de un período de tiempo razonable, minimizando así el impacto en el rendimiento de esta configuración.

Configuraciones en los Nodos Esclavos

En los esclavos, siempre es importante rastrear dos posiciones con mucha precisión:la posición actual ejecutada del subproceso SQL en el registro de retransmisión y la posición actual del subproceso IO que indica qué tan lejos el archivo binario mater se lee y se copia al esclavo. Las consecuencias de no mantener estas posiciones son bastante obvias. Si hay un bloqueo y reinicio del esclavo, el subproceso SQL puede comenzar a procesar transacciones desde un desplazamiento incorrecto o el subproceso IO puede comenzar a extraer datos desde una posición incorrecta en los registros binarios maestros. Ambos casos conducirán a la corrupción de datos.

es importante garantizar la seguridad contra choques de los esclavos a través de las siguientes configuraciones:

• relay_log_info_repository =TABLA
• relay_log_recovery =ACTIVADO

Configurar relay_log_info_repository en TABLE garantizará que la posición del subproceso SQL se actualice junto con cada confirmación de transacción en el esclavo. Sin embargo, es difícil mantener la posición exacta del subproceso de E/S y vaciarlo en el disco. Esto se debe a que la lectura del registro binario maestro y la escritura en el registro de retransmisión esclavo no se basan en transacciones. El impacto en el rendimiento es muy alto si la posición del subproceso de E/S debe actualizarse y vaciarse en el disco después de cada escritura en los registros de relés esclavos. Una solución más elegante sería establecer relay_log_recovery =ON, en cuyo caso, si hay un reinicio de MySQL, se asumirá que los registros de retransmisión actuales están dañados y se extraerán del maestro en función de la posición del subproceso SQL.

Por último, pero no menos importante, es importante tener en cuenta que la replicación semisíncrona garantiza que los datos acaban de 'llegar' a uno de los esclavos antes de que el maestro confirme la transacción, y no significa que las transacciones se comprometen en el esclavo. Por lo tanto, será bueno asegurarse de que el subproceso SQL funcione con un buen rendimiento. En el caso ideal, el subproceso SQL se mueve de la mano con el subproceso IO para que podamos tener el beneficio de que el esclavo no solo reciba las transacciones, sino que también las confirme. Se recomienda optar por una configuración esclava de subprocesos múltiples para que podamos obtener un mayor rendimiento del subproceso SQL esclavo. Las configuraciones importantes para esclavos de subprocesos múltiples son:

• slave_parallel_workers :Establézcalo en> 1 para habilitar varios trabajadores de subprocesos SQL esclavos. Según la cantidad de subprocesos que escriben en el maestro, podemos decidir un número óptimo para esto para que el esclavo no se retrase.
• tipo-esclavo-paralelo =LOGICAL_CLOCK
• slave-preserve-commit-order =1

Las configuraciones anteriores prometen paralelismo en el esclavo, mientras que al mismo tiempo, preservan el orden de las transacciones como se ve en el maestro.

En resumen, al utilizar las configuraciones anteriores en nuestro conjunto de réplicas de MySQL, podemos mantener una alta integridad de los datos junto con un rendimiento óptimo.

Como siempre, si tiene alguna pregunta, déjenos un comentario, comuníquese con nosotros en @scalegridio en Twitter o envíenos un correo electrónico a soporte @scalegrid.io.