Introducción: Anteriormente teníamos un artículo sobre cómo implementar la replicación maestro-esclavo de MySQL. Hoy, presentaremos cómo asegurar la consistencia de los datos maestro-esclavo de MySQL. Para decirlo sin rodeos, el principio de la replicación maestro-esclavo de MySQL es que cuando el maestro escribe datos, dejará un registro de escritura y el esclavo escribirá datos de acuerdo con el registro dejado por el maestro imitando su proceso de ejecución de datos. Después de comprender el principio de la replicación maestro-esclavo de MySQL, puede comprender claramente que hay dos pasos que pueden conducir a una inconsistencia maestro-esclavo:
1、mater日志写入不成功导致slave不能正常模仿。
2、slave根据master日志模仿时写入不成功。
Hoy resolveremos el problema de la inconsistencia entre amo y esclavo desde estas dos dimensiones.
1. Asegure la unidad del registro y los datos de MySQL (lado maestro) y maneje situaciones anormales como cortes de energía y tiempo de inactividad.
Unos cuantos pitidos más :
1. Como sistema de base de datos enchufable, MySQL admite un motor de almacenamiento enchufable y está diseñado para dividirse en la capa del servidor y la capa del motor de almacenamiento.
2. En la capa del servidor, MySQL registra el bitácora binaria Binlog de varias operaciones de la base de datos en forma de eventos, sus funciones básicas son: replicación y respaldo. Además, combinamos las necesidades de diversos escenarios comerciales y construimos un poderoso ecosistema MySQL basado en las características de Binlog, tales como: DTS, unitización, sincronización en tiempo real entre sistemas heterogéneos, etc. Binlog se ha convertido desde hace mucho tiempo en una parte indispensable del Ecosistema MySQL Módulo.
3. En la capa del motor de almacenamiento, InnoDB, como motor de almacenamiento más general, tiene un buen equilibrio entre alta disponibilidad y alto rendimiento, y durante mucho tiempo se ha convertido en la primera opción para usar MySQL (PS: el oficial a partir de MySQL 5.5.5, InnoDB sirve como motor de almacenamiento predeterminado para MySQL). Como la mayoría de las bases de datos relacionales, InnoDB usa tecnología WAL, es decir, InnoDB Redo Log registra los cambios físicos en los archivos de datos y asegura que el registro sea siempre el primero. Antes de conservar el archivo de datos, asegúrese de que el registro de rehacer anterior se haya escrito en el disco. El hecho de que Binlog e InnoDB Redo Log se coloquen en el disco afectará directamente la medida en que se pueden recuperar los datos de la instancia después de un tiempo de inactividad anormal. InnoDB proporciona los parámetros correspondientes para controlar el método y la estrategia de escritura del registro cuando se confirma la transacción, por ejemplo:
innodb_flush_method:控制innodb数据文件、日志文件的打开和刷写的方式，建议取值：fsync、O_DIRECT。
innodb_flush_log_at_trx_commit:控制每次事务提交时，重做日志的写盘和落盘策略，可取值：0，1，2。
当innodb_flush_log_at_trx_commit=1时，每次事务提交，日志写到InnoDB Log Buffer后，会等待Log Buffer中的日志写到Innodb日志文件并刷新到磁盘上才返回成功。
sync_binlog：控制每次事务提交时，Binlog日志多久刷新到磁盘上，可取值：0或者n(N为正整数)。
不同取值会影响MySQL的性能和异常crash后数据能恢复的程度。当sync_binlog=1时，MySQL每次事务提交都会将binlog_cache中的数据强制写入磁盘。
innodb_doublewrite：控制是否打开double writer功能，取值ON或者OFF。
当Innodb的page size默认16K，磁盘单次写的page大小通常为4K或者远小于Innodb的page大小时，发生了系统断电/os crash ，刚好只有一部分写是成功的，则会遇到partial page write问题，从而可能导致crash后由于部分写失败的page影响数据的恢复。InnoDB为此提供了Double Writer技术来避免页断裂(partial write)的发生。
innodb_support_xa:控制是否开启InnoDB的两阶段事务提交.默认情况下，innodb_support_xa=true，支持xa两段式事务提交。
A través de los pitidos anteriores, obtenemos la siguiente configuración:
#以下配置保证bin-log写入后事务提交流程会变成两阶段提交，这里的两阶段提交并不涉及分布式事务，mysql把它称之为内部xa事务
innodb_support_xa=ON
#以下配置能够保证不论是MySQL Crash 还是OS Crash 或者是主机断电重启都不会丢失数据
innodb_doublewrite=ON
#以下配置保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
configuración de mysql
2. Asegúrese de que MySQL (lado esclavo) se sincronice con el lado maestro durante la sincronización.
1. Replicación asincrónica
La biblioteca principal devolverá inmediatamente el resultado al cliente después de ejecutar la transacción enviada por el cliente, y no le importa si la biblioteca esclava lo ha recibido y procesado, por lo que habrá un problema. Si el maestro falla, el maestro ya ha Es posible que la transacción enviada no se transmita a la biblioteca de esclavos. Si en este momento, el esclavo forzado se promoverá al maestro, lo que puede dar lugar a una "inconsistencia de datos". Los primeros MySQL (anteriores a 5.5) solo admitían la replicación asincrónica.
2. Replicación semisincrónica
MySQL introdujo la replicación semisincrónica en 5.5. La biblioteca maestra debe asegurarse de que al menos una biblioteca esclava reciba y escriba en el registro de retransmisión antes de responder a la transacción enviada por el cliente. La replicación semisincrónica utiliza el parámetro rpl_semi_sync_master_wait_point para controlar el enlace en el que el maestro recibe el acuse de recibo del esclavo. Después de recibir el acuse de recibo, el maestro devuelve el estado al cliente. Hay dos opciones para este parámetro: AFTER_SYNC & AFTER_COMMIT.
rpl_semi_sync_master_wait_point=WAIT_AFTER_COMMIT
Cuando rpl_semi_sync_master_wait_point es WAIT_AFTER_COMMIT, la llamada de commitTrx es después de la confirmación de la capa del motor, es decir, mientras se espera el Slave ACK, aunque el cliente actual no se devuelve, la transacción se ha confirmado y otros clientes leerán la transacción confirmada. Si el lado esclavo no ha leído los eventos de la transacción y la biblioteca principal falla al mismo tiempo, cambie a la biblioteca en espera. Luego, la transacción leída antes desaparece y hay un problema de inconsistencia de datos. Si la biblioteca principal nunca se puede iniciar, entonces la transacción que realmente se ha comprometido con éxito en la biblioteca principal no se puede encontrar en la biblioteca esclava, es decir, los datos se pierden.
PD: Ya hace 11 años, la base de datos de Alibaba innovó para resolver este problema esperando a Slave ACK antes de comprometerse en la capa del motor.
3. Replicación totalmente sincrónica
En respuesta a los problemas anteriores, MySQL introdujo oficialmente el Semi-Synchronous sin pérdidas en 5.7.2. Después de llamar a binlog sync, espere a Slave ACK antes de confirmar en la capa del motor. De esta manera, la transacción solo se confirmará después de confirmar que el esclavo ha recibido los eventos de transacción.
rpl_semi_sync_master_wait_point=WAIT_AFTER_SYNC
En el modo after_sync, se resuelve el problema de la inconsistencia de datos causada por el modo after_commit, porque la biblioteca principal no confirma la transacción. Pero habrá un problema. Cuando la biblioteca principal se vacía binlog y binlog se sincroniza con la biblioteca en espera, se produce un aborto antes de la sincronización binlog, entonces es obvio que esta transacción no se envió correctamente en la biblioteca principal (porque binlog no se sincronizado antes de abortar, la transacción se revertirá después de que se restaure la biblioteca principal), pero debido a que la biblioteca esclava ha recibido estos Binlogs y se ha ejecutado correctamente, es equivalente a datos adicionales en la biblioteca esclava, lo que puede causar "inconsistencia de datos".
Además, en la arquitectura de replicación semisincrónica de MySQL, cuando la base de datos principal está esperando la confirmación de la base de datos en espera, si el tiempo de espera degenera en asincrónico, también puede causar "inconsistencia de datos".
3. Comentarios y soluciones (las ideas de soluciones anteriores pueden satisfacer el 99,8% de los escenarios comerciales de la empresa)
1. A través del análisis y configuración de los dos puntos anteriores, encontramos que la propia Repliaction de MySQL ya no puede satisfacer el deseo de nuestros compañeros que aman estar cachondos (los programadores de back-end serán demasiado cuidadosos al pensar), lo que debería ser ¿hecho? Para garantizar la consistencia absoluta de los datos maestro-esclavo, permítanme proporcionar dos ideas a continuación (un poco cansado hoy, solo ideas, escuche la próxima vez para soluciones específicas).
2. Una plataforma de corrección de datos desarrollada por la propia Alibaba Cloud.
3. Solución de fuerte consistencia de datos PXC y soporta múltiples maestros y múltiples esclavos La desventaja es que necesita aplicar al jefe para máquinas con poca diferencia en el rendimiento para hacer clústeres.
Autor:
Enlace de palo de palo solitario : https: //www.jianshu.com/p/328ad87bde5e
Fuente: Los libros de Jane
tienen derechos de autor del autor. Para reimpresiones comerciales, comuníquese con el autor para obtener autorización, y para reimpresiones no comerciales, indique la fuente.