El principio básico de maestro-esclavo Mysql, la forma principal y el principio de retraso de sincronización maestro-esclavo (separación de lectura y escritura) conducen al problema y la solución
Primero, la diferencia entre las bases de datos maestras y esclavas
La base de datos esclava (Slave) es una copia de seguridad de la base de datos maestra. Cuando la base de datos maestra (Master) cambia, la base de datos esclava debe actualizarse. Este software de base de datos puede diseñar el ciclo de actualización. Este es un medio para mejorar la seguridad de la información. El servidor de base de datos maestro-esclavo no está en una ubicación geográfica, y la base de datos se puede guardar cuando ocurre un accidente.
(1) División de trabajo maestro-esclavo
El maestro es responsable de la carga de las operaciones de escritura, lo que significa que todas las operaciones de escritura se realizan en el maestro y las operaciones de lectura se asignan al esclavo. De esta manera, la eficiencia de lectura se puede mejorar considerablemente. En las aplicaciones generales de Internet, después de algunas encuestas de datos, se concluye que la proporción de lectura / escritura es de aproximadamente 10: 1, lo que significa que una gran cantidad de operaciones de datos se concentran en operaciones de lectura, por lo que tenemos múltiples esclavos. Razón Pero, ¿por qué separar la lectura y la escritura? Los desarrolladores familiarizados con DB saben que las operaciones de escritura involucran bloqueos, ya sea bloqueos de fila, bloqueos de tabla o bloqueos de bloque, que son relativamente cosas que reducen la eficiencia de ejecución del sistema. Nuestra separación es concentrar la operación de escritura en un nodo, mientras que la operación de lectura se realiza en los otros N nodos, lo que mejora efectivamente la eficiencia de lectura desde otro aspecto y asegura la alta disponibilidad del sistema.
(2) Proceso básico
1) La sincronización maestro-esclavo Mysql significa que cuando el maestro (base de datos maestra) cambia los datos, se sincronizará con el esclavo (base de datos esclava) en tiempo real.
2) La replicación maestro-esclavo puede expandir horizontalmente la capacidad de carga de la base de datos, la tolerancia a fallas, la alta disponibilidad y el respaldo de datos.
3) Ya sea que se trate de eliminar, actualizar, insertar o crear funciones, los procedimientos almacenados se encuentran en el maestro, cuando el maestro tiene operaciones, el esclavo recibirá rápidamente estas operaciones para sincronizar.
(3) Usos y condiciones
1), propósitos de replicación maestro-esclavo MySQL
● Recuperación de desastres en tiempo real, utilizada para conmutación por error
● Separación de lectura y escritura, proporcionar servicios de consulta
● Copia de seguridad, para evitar afectar el negocio
2), Condiciones necesarias de implementación maestro-esclavo:
● La biblioteca maestra está abierta binlog log (establecer el parámetro log-bin)
● La identificación del servidor maestro-esclavo es diferente
● El servidor esclavo puede conectarse a la base de datos maestra
En segundo lugar, la granularidad, el principio y la forma de sincronización maestro-esclavo:
(1), tres granularidades de implementación principales
La sincronización maestro-esclavo detallada tiene principalmente tres formas: instrucción, fila, mixto
1), instrucción: escribirá la instrucción SQL para la operación de la base de datos en binlog
2), fila: cada Los cambios de datos se escriben en binlog.
3) Mixto: la declaración y la fila son mixtas. Mysql decide cuándo escribir binlog en formato de declaración y cuándo escribir binlog en formato de fila.
(2), el principio de realización principal, operación específica, diagrama esquemático
1) Operación en la máquina maestra:
cuando los datos en la maestra cambien, el cambio de evento se escribirá en el registro de contenedores en orden. Cuando el esclavo está vinculado al maestro, la máquina maestra iniciará el subproceso de volcado de binlog para el esclavo. Cuando cambia el binlog del maestro, el subproceso de volcado del bin-log notificará al esclavo y enviará el contenido del binlog correspondiente al esclavo.
2). Operar en la máquina esclava:
Cuando la sincronización maestro-esclavo está habilitada, se crean dos hilos en el esclavo: hilos I / O. El hilo está conectado a la máquina maestra, y el hilo de volcado del binlog en la máquina maestra enviará el contenido del binlog al hilo I / O. Después de recibir el contenido de binlog, el hilo de E / S escribe el contenido en el registro de retransmisión local; el hilo sql. Este hilo lee el registro de ralay escrito por el hilo de E / S. Y de acuerdo con el registro de retransmisión. Y de acuerdo con el contenido del registro de retransmisión, realice la operación correspondiente a la base de datos esclava.
3) El diagrama principal de la replicación maestro-esclavo MySQL es el siguiente:
Genere dos subprocesos de la biblioteca, un subproceso de E / S y un subproceso SQL; el subproceso de E / S
solicita el binlog de la biblioteca principal y escribe el registro binlog obtenido en el archivo de registro de retransmisión (registro de retransmisión); la
biblioteca principal genera Se utiliza un subproceso de volcado de registro para transferir el binlog al subproceso de E / S de la biblioteca esclava; el subproceso
SQL leerá el registro en el archivo de registro de retransmisión y lo analizará en operaciones específicas para lograr operaciones coherentes maestro-esclavo y consistencia de datos final;
(2), forma maestro-esclavo
la replicación maestro-esclavo de mysql es flexible
● un maestro un esclavo
● replicación maestro-maestro
● un maestro multi-esclavo --- expande el rendimiento de la lectura del sistema, porque la lectura se lee desde la biblioteca;
● multi-maestro un esclavo --- 5.7 soporte
● replicación en cascada ---
3. Problemas, causas y soluciones para el retraso de la sincronización maestro-esclavo:
(1) El retraso de la sincronización de la base de datos mysql desde la base de datos
1) Parámetros relacionados:
Primero ejecute show slave satus en el servidor; puede ver muchos parámetros sincronizados:
Master_Log_File: el nombre del archivo de registro binario del servidor maestro que el hilo de E / S está leyendo actualmente en SLAVE Read_Master_Log_Pos: en el registro binario del servidor maestro actual, la posición donde ha leído el hilo de E / S en SLAVE Relay_Log_File: el nombre del archivo de registro de retransmisión que el hilo SQL está leyendo y ejecutando actualmente Relay_Log_Pos: en el registro de retransmisión actual, la posición donde el hilo SQL ha leído y ejecutado Relay_Master_Log_File: el nombre del archivo de registro binario del servidor maestro ejecutado por el hilo SQL que contiene los eventos más recientes Slave_IO_Running: si el hilo de E / S se inicia y se conecta correctamente al servidor principal Slave_SQL_Running: si se inicia el hilo SQL Seconds_Behind_Master: el intervalo de tiempo entre el hilo SQL del servidor esclavo y el hilo de E / S del servidor esclavo, en segundos.
Desde la situación de retraso de sincronización de la biblioteca esclava ● mostrar el parámetro de visualización del estado del esclavo Seconds_Behind_Master no es 0, este valor puede ser muy grande ● mostrar estado esclavo muestra que los parámetros Relay_Master_Log_File y Master_Log_File muestran que los números del bin-log son muy diferentes, lo que indica que el bin-log no está sincronizado a tiempo en la biblioteca esclava, por lo que el bin-log ejecutado recientemente es muy diferente del bin-log leído por el hilo de E / S actual Grande ● Hay muchos registros de registro de mysql-relay en el directorio de datos de la base de datos esclava de mysql, y el sistema eliminará automáticamente los registros una vez que se complete la sincronización. Hay muchos registros que indican que el retraso de sincronización maestro-esclavo es muy severo
(2) El retraso de la sincronización de la base de datos MySql de la biblioteca
1), Principio de retraso de sincronización maestro-esclavo de la base de datos MySQL Principio de sincronización maestro-esclavo mysql: la biblioteca maestra para operaciones de escritura, escribe binlog secuencialmente, desde la biblioteca de un solo subproceso a la lectura secuencial de la biblioteca maestra "binlog de operación de escritura", obtén el binlog de la biblioteca como está localmente Realice (escritura aleatoria) para asegurarse de que los datos maestros y esclavos sean lógicamente consistentes. La replicación maestro-esclavo de MySQL es una operación de subproceso único. La biblioteca principal genera binlogs para todos los DDL y DML. Los binlogs se escriben secuencialmente, por lo que la eficiencia es muy alta. El subproceso Slave_IO_Running del esclavo busca registros en la biblioteca principal. Aquí viene, el subproceso Slave_SQL_Running del esclavo implementa las operaciones DDL y DML de la biblioteca principal en el esclavo. Las operaciones IO de DML y DDL son aleatorias, no secuenciales, y el costo es mucho mayor. También puede causar contención de bloqueo para otras consultas en el esclavo. Dado que Slave_SQL_Running también es de un solo subproceso, un maestro de tarjeta DDL necesita realizar 10 minutos Luego, todos los DDL posteriores esperarán a que este DDL finalice la ejecución antes de continuar, lo que provoca un retraso. Algunos amigos preguntarán: "El mismo DDL en la biblioteca principal también necesita ejecutar 10 puntos, ¿por qué se retrasa el esclavo?" La respuesta es que el maestro puede ser concurrente, pero el hilo Slave_SQL_Running no lo es.
2) ¿Cómo se genera el retraso de sincronización maestro-esclavo en la base de datos MySQL? Cuando la concurrencia TPS de la biblioteca principal es alta, el número de DDL generado excede el rango que puede soportar un subproceso sql esclavo, luego se genera el retraso y, por supuesto, puede haber una espera de bloqueo con la declaración de consulta grande del esclavo. La razón principal: la base de datos tiene demasiada presión de lectura y escritura en el negocio, la carga de cálculo de la CPU es grande, la carga de la tarjeta de red es pesada y la E / S aleatoria del disco duro es demasiado alta. Razones secundarias: impacto en el rendimiento causado por leer y escribir binlog, retraso en la transmisión de la red.
(3), la solución de retraso de la sincronización de la base de datos MySql desde la biblioteca
1) 、 Arquitectura
1. La implementación de la capa de persistencia empresarial adopta una arquitectura de sub-base de datos, y el servicio mysql puede ampliarse en paralelo para dispersar la presión.
2. La lectura y escritura separadas de una sola biblioteca, un maestro y muchos esclavos, lectura maestra y esclava, dispersan la presión. De esta manera, la presión del almacenamiento secundario es mayor que la del almacenamiento primario, protegiendo el almacenamiento primario.
3. La infraestructura del servicio agrega capa de caché memcache o redis entre la empresa y mysql. Reduzca la presión de lectura de mysql.
4. MySQL de diferentes negocios se coloca físicamente en diferentes máquinas para dispersar la presión.
5. Utilice un dispositivo de hardware mejor que la biblioteca principal como resumen esclavo, la presión de mysql es pequeña, la demora será naturalmente menor.
2), hardware
1. Utilice un buen servidor: por ejemplo, 4u es significativamente mejor que 2u y 2u es mejor que 1u.
2. El almacenamiento utiliza SSD o matriz de discos o san para mejorar el rendimiento de la escritura aleatoria.
3. La sala maestro-esclavo está garantizada para estar bajo el mismo interruptor y en un entorno de 10 Gigabits.
En resumen, el hardware es fuerte y, naturalmente, el retraso se hará más pequeño. En resumen, la solución para reducir la latencia es gastar dinero y tiempo.
3), aceleración de sincronización maestro-esclavo mysql
1. Sync_binlog se establece en 0 en el lado esclavo
2. –logs-slave-updates Las actualizaciones recibidas por el servidor esclavo del servidor maestro no se registran en su registro binario.
3. Deshabilite directamente el binlog en el lado esclavo
4. En el lado esclavo, si el motor de almacenamiento utilizado es innodb, innodb_flush_log_at_trx_commit = 2
4), optimización desde la perspectiva del propio sistema de archivos
El final maestro modifica el atributo etime de los archivos en los sistemas de archivos Linux y Unix. Dado que el sistema operativo reescribirá la hora en que se produce la operación de lectura en el disco cada vez que se lee el archivo, esto no es necesario para los archivos de bases de datos con operaciones de lectura frecuentes. Solo aumenta la carga en el sistema de disco y afecta el rendimiento de E / S. Puede organizar el sistema operativo para escribir información atime configurando el atributo de montaje del sistema de archivos. La operación en Linux es: abrir / etc / fstab, agregar el parámetro noatime / dev / sdb1 / data reiserfs noatime 1 2 y luego volver a montar el sistema de archivos #mount -oremount / data
5). Se escribe la biblioteca principal para el ajuste de parámetros de sincronización, que tiene una alta seguridad de datos. Por ejemplo, sync_binlog = 1, innodb_flush_log_at_trx_commit = 1, y se necesitan otras configuraciones, y el esclavo no necesita tanta seguridad de datos. Se puede decir que sync_binlog está configurado en 0 o cerrar binlog, innodb_flushlog también se puede establecer en 0 para mejorar la eficiencia de la ejecución de SQL
1. sync_binlog = 1 oMySQL proporciona un parámetro sync_binlog para controlar el binlog de la base de datos para flashear en el disco. Por defecto, sync_binlog = 0, lo que significa que MySQL no controla la actualización de binlog, y la actualización de su caché es controlada por el sistema de archivos. El rendimiento en este momento es el mejor, pero el riesgo también es el mayor. Una vez que el sistema falla, se perderá toda la información de binlog en binlog_cache.
Si sync_binlog> 0, significa que cada transacción sync_binlog se confirma, MySQL llama a la operación de actualización del sistema de archivos para vaciar el caché. El más seguro es sync_binlog = 1, lo que significa que MySQL limpiará el binlog cada vez que se envíe una transacción. En este caso, el sistema puede perder los datos de una transacción solo cuando el sistema operativo del host donde se encuentra la base de datos está dañado o pierde energía repentinamente. Aunque binlog es IO secuencial, pero establece sync_binlog = 1, se envían varias transacciones al mismo tiempo, lo que también afecta en gran medida el rendimiento de MySQL y IO. Aunque el parche de confirmación grupal puede aliviarlo, el impacto de la frecuencia de actualización excesiva en IO también es muy grande.
Para sistemas con transacciones concurrentes altas, la diferencia entre el rendimiento de escritura del sistema con "sync_binlog" establecido en 0 y 1 puede ser tan alto como 5 veces o más. Por lo tanto, el sync_binlog establecido por muchos DBA MySQL no es el más seguro, sino 2 o 0. Esto sacrifica cierta consistencia para lograr una mayor concurrencia y rendimiento. Por defecto, binlog no se sincroniza con el disco duro cada vez que se escribe. Por lo tanto, si el sistema operativo o la máquina (no solo el servidor MySQL) falla, es posible que se pierda la última instrucción en el binlog. Para evitar esto, puede usar la variable global sync_binlog (1 es el valor más seguro, pero también el más lento) para sincronizar binlog con el disco duro después de cada N binlog escribe. Incluso si sync_binlog se establece en 1, puede haber una inconsistencia entre el contenido de la tabla y el contenido de binlog cuando se produce un bloqueo.
2. Innodb_flush_log_at_trx_commit (esto funciona) se queja de que Innodb es 100 veces más lento que MyISAM? Entonces probablemente olvidó ajustar este valor. El valor predeterminado de 1 significa que cada instrucción de confirmación de transacción o fuera de transacción requiere que el registro se vacíe en el disco duro, lo que lleva mucho tiempo. Especialmente cuando se usa caché con respaldo de batería. Establecido en 2 para muchas aplicaciones, especialmente la transferencia desde la tabla MyISAM, significa que no está escrito en el disco duro sino en la memoria caché del sistema. Los registros seguirán siendo enviados al disco duro cada segundo, por lo que normalmente no perderá más de 1-2 segundos de actualizaciones. Establecer en 0 será más rápido, pero la seguridad es relativamente pobre, incluso si MySQL se bloquea, puede perder los datos de la transacción. El valor 2 solo perderá datos cuando se cuelgue todo el sistema operativo.
3. El comando ls (1) se puede usar para enumerar atime, ctime y mtime de los archivos.
El tiempo de acceso del archivo atime cambia el tiempo de creación del archivo ctime cuando lee el archivo o lo ejecuta. Cuando se escribe el archivo, el propietario, los permisos o la configuración del enlace cambian cuando cambia el contenido del inodo. El tiempo modificado del archivo mtime cambia cuando se escribe el archivo. Cuando el contenido del archivo cambia, ls -lc filename enumera los ctimels del archivo -lu filename enumera los atimels del archivo -l filename enumera el nombre de archivo mtimestat del archivo que atime, mtime, ctimeatime no se modifican necesariamente después de acceder al archivo porque : Al usar el sistema de archivos ext3, si el parámetro noatime se usa durante el montaje, la información de atime no se actualizará. Estas tres marcas de tiempo se colocan todas en el inodo. Si se modifican mtime y atime, se cambiará el inodo. Dado que se cambia el inodo, también se cambiará el ctime. La razón por la que se usa noatime en la opción de montaje es que no quiero que el sistema de archivos lo haga. Demasiadas modificaciones para mejorar el rendimiento de lectura
(4), base de datos MySql de la biblioteca para sincronizar otros problemas y soluciones
1) Problemas con la replicación maestro-esclavo mysql: ● Los datos pueden perderse después de que la base de datos maestra esté inactiva ● Solo hay un subproceso sql en la base de datos esclava, la base de datos maestra tiene una gran presión de escritura y es probable que la replicación se demore 2). Solución: ● replicación semisíncrona --- Resolver el problema de pérdida de datos ● Replicación paralela ---- Resolver el problema de replicación retrasada de la biblioteca
3), replicación semi-síncrona mysql semi-sync (replicación semi-síncrona) replicación semi-síncrona: ● 5.5 está integrado en mysql, existe en forma de un complemento, y debe instalarse por separado ● asegúrese de que el binlog se transfiera al menos a una biblioteca esclava después de que se envíe la transacción ● no hay garantía de El binlog después de que la biblioteca haya aplicado esta transacción ● El rendimiento se reducirá en cierta medida y el tiempo de respuesta será más largo ● La red es anormal o la biblioteca esclava está inactiva, la biblioteca maestra de tarjeta maestra, hasta el tiempo de espera o la recuperación de la biblioteca 4), principio de replicación esclava-replicación asíncrona maestra , Replicación semisíncrona y comparación de principios de replicación paralela
El principio de la replicación asincrónica:
b) El principio de replicación semisíncrona:
La transacción debe devolver uno aceptado de la biblioteca después de escribir el binlog en la biblioteca principal, y luego devolverlo al cliente; 5.5 está integrado en mysql y existe en forma de un complemento. Debe instalarse por separado para garantizar que el binlog se transfiera al menos a un esclavo después de que se envíe la transacción El rendimiento de binlog de la aplicación esclava para completar esta transacción tiene una cierta reducción en las anomalías de la red o el tiempo de inactividad esclavo, la biblioteca maestra de tarjetas, hasta el tiempo de espera o la recuperación de la biblioteca
c. Replicación paralela mysql replicación paralela ● Nuevo en la versión 5.6 de la comunidad ● Paralela se refiere a binlog de aplicación de subprocesos múltiples desde la biblioteca ● Aplicación paralela de nivel binario de binlog, los mismos cambios de datos de biblioteca o configuración serial (replicación paralela versión 5.7 basada en el grupo de transacción) establecer global slave_parallel_workers = 10; establecer el número de subprocesos sql en 10
Principio: desde el binlog de aplicación multiproceso de la biblioteca, se agrega una nueva aplicación paralela a nivel de biblioteca de binlog en la comunidad 5.6. Los mismos cambios de datos de la biblioteca o la replicación paralela de la versión serial 5.7 basada en el grupo de transacción
Referencia: https://blog.csdn.net/hao_yunfeng/article/details/82392261