contorno
MySQL sincronización maestro-esclavo es una arquitectura muy sofisticados, ventajas:
① en pueden realizar consultas de trabajo (que es, a menudo decimos que la función de lectura) desde el servidor, reduciendo el estrés del servidor principal;
② la copia de seguridad del servidor principal para evitar el impacto durante la copia de seguridad servicio maestro;
③ un problema si el servidor principal, el servidor se puede cambiar de.
Estoy seguro de que estos beneficios han sido muy comprensivos, sino también en el proyecto de implementación usando este programa. Pero MySQL retardo de sincronización maestro-esclavo ha sido un problema desde la biblioteca, entonces ¿por qué hay tal problema. ¿Cómo resolver este problema?
- principio de retardo de sincronización maestro-esclavo base de datos MySQL.
- MySQL retardo de sincronización de base de datos maestro-esclavo es cómo generado.
- soluciones de retardo de sincronización maestro-esclavo de base de datos MySQL.
principio de retardo de sincronización maestro-esclavo base de datos MySQL
Hablando maestro-esclavo principio retardo de sincronización de base de datos MySQL, era de la base de datos principal MySQL desde principio de replicación, de la mysql principal operaciones de replicación son de un solo subproceso, la principal biblioteca generada binlog todo DDL y DML, orden binlog escrito, por lo alta eficiencia, el esclavo a la biblioteca principal logs toma de hilo de Slave_IO_Running, eficacia muy alta, al lado, la pregunta, las operaciones de rosca esclavo Slave_SQL_Running DDL y DML en maestro esclavo realización repositorio. operaciones DDL IO DML y es entonces, no secuenciales, costos mucho más altos, también pueden haber otras consultas generadas contención de bloqueo en el esclavo, porque el Slave_SQL_Running es de un solo subproceso, por lo que una tarjeta principal DDL, y lo que necesita para llevar a cabo durante 10 minutos, por lo que después de todo DDL DDL esperará a la finalización de la ejecución continuará, lo que llevó a la demora. Un amigo le pregunta: "DDL mismas bibliotecas que también tienen que realizar en los 10 puntos principales, esclavo ¿Por qué demora?", La respuesta es un maestro puede ser complicado, hilo Slave_SQL_Running no puede.
base de datos MySQL retardo de sincronización maestro-esclavo es cómo lo hizo
Cuando TPS principal biblioteca de la cantidad concurrente de DDL genera más de un flujo SQL esclavo podía permitirse, entonces surge la demora, por supuesto, es posible con instrucciones de consulta grandes esclavo espera de bloqueo.
Sabemos que un enlace del servidor N abierta para conectar con el cliente, por lo que habrá un gran operaciones de actualización concurrentes, pero lee el hilo binlog desde el interior de un servidor sólo cuando una ejecución de SQL del servidor o un poco más largo debido a una tabla de SQL hará que el bloqueo sea gran atraso SQL del servidor principal no se ha sincronizado con el servidor desde el interior. Esto conduce a la inconsistente maestro-esclavo, es decir, el retardo de maestro-esclavo.
base de datos MySQL retardo de sincronización maestro-esclavo Soluciones
El programa más fácil la reducción de retardo de sincronización esclavo es hacer la optimización de la arquitectura, tratar de hacer una rápida implementación de la biblioteca principal DDL. Hay una biblioteca principal está escrito, seguridad de datos es alta, como sync_binlog = 1, innodb_flush_log_at_trx_commit = 1 se establece y similares, mientras que el esclavo no se necesita una seguridad de datos tan alta, puede hablar conjunto sync_binlog a cero o cerca binlog, innodb_flushlog también puede ajustarse a 0 para mejorar la eficiencia de SQL. La otra es utilizar mejor que la biblioteca principal de dispositivos de hardware como esclavo.
De hecho, retardo de sincronización maestro-esclavo no tiene ninguna forma de engañar a sus enemigos, por todo el SQL debe ejecutarse desde un servidor dentro de nuevo, pero si el servidor principal seguirá teniendo un flujo constante de operación de actualización de escritura, a continuación, una vez que el generador de retardo , entonces la posibilidad de retrasar el énfasis mayor será originales. Por supuesto, podemos hacer algunas medidas de mitigación.
- a. Lo sabemos porque el servidor primario es el responsable de la operación de actualización, desde el servidor que él, algunos ajustes pueden ser modificados para todos los requisitos de seguridad, como sync_binlog = 1, innodb_flush_log_at_trx_commit = 1 como el establecimiento, mientras que el esclavo no es necesario un alto tales seguridad de los datos, puede hablar conjunto sync_binlog a 0 o fuera binlog, innodb_flushlog, innodb_flush_log_at_trx_commit también puede ajustarse a 0 para mejorar la eficiencia del SQL puede mejorar mucho la eficiencia. La otra es utilizar mejor que la biblioteca principal de dispositivos de hardware como esclavo.
- b. es, un grado desde el servidor cuando se utiliza como una copia de seguridad, sin proporcionar consulta, su carga allí abajo, en el interior de la eficiencia log retardado la ejecución de SQL naturalmente alto.
- c. Aumentar mí mismo, este objeto se lee desde el servidor o presión distribuida, lo que reduce la carga del servidor.
Analizando el retardo primario, por lo general hay dos métodos:
Seconds_Behind_Master y mk-latido del corazón, la diferencia entre el dos por debajo, en particular, para lograr la función.
Seconds_Behind_Master
El seguimiento puede mostrar slave statusel valor del parámetro de la Seconds_Behind_Master salida de comando para determinar si se produce un retardo desde el maestro.
Los valores son tan pocos:
. NULL - representa IO_THREAD o SQL_THREAD hay algún fallo, es decir, el estado de funcionamiento de la rosca es No, más bien Sí
0 - este valor es cero, estamos muy ansiosos por ver, un frente de una buena copia, se cree lag no existe.
Positivo - un frente ha surgido a partir de la demora, más cuanto mayor sea el número de la biblioteca detrás de la biblioteca principal.
Negativo - rara vez se ve, sólo escucha a algunos said've DBA alto visto, de hecho, esto es un error, este parámetro no está soportado por un valor negativo, es decir, no debería aparecer.
replicación Seconds_Behind_Master por la ejecución de marca de tiempo y el evento IO_THREAD comparación buena SQL_THREAD de la marca de tiempo de evento (abreviado como ts) se comparan, y una diferencia de tales obtiene. Todos sabemos el contenido binlog dentro del relé de registro y la biblioteca principal en exactamente el mismo registro al mismo comprobante de tiempos de SQL que se grabará en los ts, por lo que el valor de comparación de referencia de la binlog, de hecho, no hay necesidad de dominar el NTP sincronización, es decir, sin la necesidad de garantizar consistente reloj maestro y el esclavo. Se encuentra, de hecho, la comparación que realmente sucedió entre IO_THREAD y SQL_THREAD y IO_THREAD realmente estar vinculado a la biblioteca principal, así que el problema salió, cuando la congestión de carga principal de la biblioteca de E / S de gran tamaño o de la red, no oportuna IO_THREAD copiar binlog (sin interrupción, sino también para copiar), y SQL_THREAD sido capaz de seguir el ritmo de la escritura IO_THREAD, entonces el valor Seconds_Behind_Master es 0, que es lo que pensamos sin demora, pero en realidad no, ya sabes. Esto es por lo que tenemos que criticar a utilizar este parámetro para conocer los motivos de la demora no se les permite a las bases de datos se ha producido, pero no siempre se permite este valor, si la red principal cuando el caso IO_THREAD bueno, entonces el valor es también muy valor. Anteriormente, hemos mencionado Seconds_Behind_Master este parámetro puede tener efectos negativos sucede, ya sabemos que el valor es la diferencia entre los ts ejecutada más recientemente a ct con nuevo y SQL_THREAD IO_THREAD, el primero es siempre mayor que el segundo, el único que está dispuesto a ser ts caso de error se produce, más pequeño que el anterior, así que cuando esto sucede, un resultado negativo es posible.
mk-latido del corazón
mk-latido del corazón, Maatkit un kit de herramienta universal, se cree que es un método exacto de determinar la replicación de retardo.
mk-latido del corazón también alcanzado por TIMESTMP comparativo implementado, primero debe asegurarse de que el maestro debe ser coherente desde el servidor, mediante la sincronización de un reloj del mismo servidor NTP. Tiene que ser creada en un latido del corazón mesa principal de la biblioteca, hay al menos dos campos ID y TS, id es server_id, ts es la fecha y hora actual ahora (), la estructura se copiará en la biblioteca, tabla incorporada después, proceso de modo de Taiwan más tarde a realizar en las principales operaciones de biblioteca de actualización de línea de comandos en un paradero base regular insertar datos en la tabla, el valor predeterminado es 1 segundo periodo, mientras que la biblioteca también controlará la ejecución de un comando en el fondo, y la biblioteca principal ciclo para mantener una comparación coherente, copiado en el valor del registro de base de datos principal del mismo TS valor ts, la diferencia es 0 para ningún retraso, cuanto más grande sea la diferencia entre el número de segundos de retardo. Todos sabemos que la replicación es ts asíncronos serían no es exactamente el mismo, por lo que la herramienta permite una brecha medio segundo, en el que la diferencia puede ser ignorada pensar en ningún retraso. Esta herramienta está copiando el trato real, inteligentemente prestado marca de tiempo para comprobar los retrasos, como éste!
adicional:
instrucciones de configuración sync_binlog:
sync_binlog ": Este parámetro es para el sistema de MySQL es crucial, no sólo afectan binlog provocado la pérdida de rendimiento de MySQL, sino que también afecta a la integridad de los datos para MySQL." sync_binlog " Descripción de los distintos parámetros establecidos de la siguiente manera:
sync_binlog = 0, cuando las confirmaciones de transacción, MySQL do fsync como comando de sincronización de disco para actualizar la información en el disco binlog_cache, y dejar Sistema de Archivos para decidir qué hacer sincronización de tiempo, o caché completa Sólo después de la sincronización en el disco.
sync_binlog = n, n veces después de cada uno se dedica de transacción, MySQL fsync o similares será una instrucción de sincronización de los datos del disco binlog_cache el disco de escritura obligatoria.
En MySQL, el valor predeterminado es sync_binlog = 0, es decir, sin ningún tipo de discos obligatorios de actualización de comandos, esta vez el rendimiento es el mejor, pero el riesgo es mayor. Debido a que una vez que el sistema de Choque, toda la información binlog se perderá en el binlog_cache. Cuando se establece en "1" cuando, pero la pérdida de rendimiento es el ajuste máximo más segura. Porque cuando se pone a 1, incluso si el sistema de Choque, también perdió a una transacción binlog_cache sin terminar, sin ningún efecto sustancial en los datos reales.
A partir de la experiencia pasada y la prueba de funcionamiento asociado, el sistema de transacciones simultáneas es alta "sync_binlog" está ajustado a 0 y puesto a 1, el sistema puede escribir hasta cinco veces la diferencia de rendimiento aún más.
Configuración innodb_flush_log_at_trx_commit Descripción:
El valor por defecto de 1 significa que se requieren cada confirmaciones de transacción o instrucciones adicionales para la escritura del registro de transacciones (el color) de disco duro, que es mucho tiempo. Especialmente cuando se utiliza la memoria caché respaldada por batería (batería copia de seguridad de caché). 2 está configurado para utilizar para mucho, sobre todo a partir de tablas MyISAM a su vez más es posible, significa que el disco duro, pero no se escribe en la memoria caché del sistema. El registro es todavía ras por segundo en el disco duro, por lo que generalmente no perderá más de 1-2 segundos para actualizar. 0 está dispuesto a ser un poco más rápido, pero la seguridad es bastante pobre, incluso si MySQL también está vinculada a los datos de la transacción se pueden perder. El valor de 2 sólo se colgará todo el sistema operativo sólo puede perder datos.
mysql-5.6.3 tiene soporte para multi-hilo de la copia principal. Dinc principios y similares, el Dinc se basa en la mesa para hacer multithreading, Oracle está utilizando la base de datos (esquema) como una unidad para hacer multi-hilo, diferentes bibliotecas pueden utilizar diferentes subproceso de replicación.
Sobre la base de mecanismo de maestro / esclavo LAN en circunstancias normales tiene que cumplir 'en tiempo real' requisito de copia de seguridad. Si el retraso es relativamente grande, que confirma los siguientes factores:
- La latencia de red
- maestro de carga
- carga de esclavos
La práctica general es utilizar una pluralidad de esclavos lectura a la solicitud de acciones, a continuación, tomar un servidor dedicado desde el esclavo, sólo como una copia de seguridad sin realizar ninguna otra operación, se puede lograr máximo relativo 'tiempo real' es el requisito
slave_net_timeout segundos a 3600 segundos por defecto
Definición: cuando el esclavo para leer datos de registro de la base de datos principal falla, el tiempo de espera para volver a establecer la conexión y adquiere los datos
master-connect-retry segundos con un valor predeterminado de 60 segundos
Definición: cuando se re- el establecimiento de conexión maestro-esclavo, si el establecimiento de la conexión falla, inténtelo de nuevo después de largos intervalos.
Típicamente dos o más parámetros pueden estar dispuestos para reducir los problemas causados por la red primaria a partir del retardo de sincronización de datos
