El método tradicional de replicación maestro-esclavo consiste en realizar transacciones de actualización de datos en el nodo maestro, luego registrar estas transacciones en el binlog y luego enviar el binlog al nodo esclavo para volcarlo en un registro de retransmisión. y luego haga que en el nodo esclavo. Los subprocesos separados lean estos registros de retransmisión y luego vuelvan a ejecutar o aplicar estas transacciones. No se comparte nada. Cada nodo tiene una copia completa de los datos. /p>
MySQL también proporciona replicación semisincrónica, que agrega un paso de sincronización a la replicación maestro-esclavo tradicional. Antes de enviar una transacción en el nodo maestro, debe esperar hasta que el nodo esclavo confirme la recepción de la información de la transacción. (Es por eso que se dijo anteriormente que cuando el nodo esclavo, la respuesta lenta del nodo afectará el envío de transacciones del nodo maestro. El diagrama de flujo técnico es el siguiente:
MGR tampoco comparte nada). Tiene una copia completa de los datos y GCS se utiliza entre nodos (Sistema de comunicación grupal) para interactuar. La capa GCS proporciona mensajes globales entre nodos y garantiza su orden.
MGR puede ejecutar transacciones de lectura y escritura (excluidas transacciones de solo lectura) en cualquier nodo y en cualquier momento. Sin embargo, las transacciones de lectura y escritura deben ser confirmadas por todo el grupo de replicación antes de poder enviarlas. Si es una transacción de solo lectura, no existe tal restricción y cualquier nodo puede iniciarla y enviarla.
Cuando una transacción de lectura-escritura está lista para ser confirmada, enviará una transmisión atómica al grupo de replicación, incluidos los datos modificados por la transacción y su conjunto de escritura correspondiente. O todos los nodos del grupo de replicación reciben la transacción o ninguno la recibe. Si todos los nodos del grupo reciben el mensaje de transacción, todos reciben el mensaje de difusión en el mismo orden en que se envió la transacción anteriormente. Por lo tanto, todos los miembros del grupo reciben los conjuntos de escritura de transacciones en el mismo orden y se establece un orden global para las transacciones.
Las transacciones ejecutadas en paralelo en varios nodos pueden entrar en conflicto. En este caso, es necesario comparar y determinar los conjuntos de escritura de dos transacciones paralelas para confirmar. Este proceso se denomina autenticación de transacciones, también llamado detección de conflictos. La detección de conflictos de transacciones se realiza a nivel de fila, lo que significa que cuando dos transacciones paralelas actualizan la misma fila, se considera que tienen conflictos. El enfoque en este momento es que la transacción en el orden global anterior pueda tener éxito y todos los nodos envíen la transacción. La transacción posterior en el orden global fallará y se revertirá, y cada nodo eliminará la transacción. En realidad, esta es una regla distribuida según la cual quien envíe primero gana la transacción. Sugerencia: si ocurren con frecuencia conflictos de transacciones entre nodos, es mejor ejecutar estas transacciones en el mismo nodo, de modo que todas puedan enviarse exitosamente bajo el control y la coordinación de concurrencia de transacciones locales, sin causar conflictos debido a la detección de conflictos de MGR. siempre retrocedido.
Para las transacciones que se están aplicando o externalizando, MGR permite que se ejecuten no necesariamente en el orden original, siempre y cuando no se destruya la consistencia y validez de la transacción. El requisito predeterminado de MGR es la coherencia final, lo que significa que cuando se completen todas las transacciones, los datos de todos los nodos serán coherentes. Cuando el tráfico es enorme, las transacciones pueden externalizarse, lo que genera ligeras inconsistencias en los pedidos. Por ejemplo, en modo multimaestro, una transacción local se externalizará inmediatamente después de pasar la autenticación, aunque puede haber una transacción remota con una secuencia global anterior que aún no se ha aplicado, siempre que el hilo de autenticación de MGR crea que esta transacción No lo es. Habrá conflictos. En el modo maestro único, el orden de envío y externalización de las transacciones concurrentes locales en el nodo primario puede ser ligeramente inconsistente con el orden de transacción global de la transacción, a menos que ocurran conflictos. En los nodos secundarios, dado que no hay transacciones de escritura, su orden de transacciones es consistente con el orden de transacciones global.
La siguiente figura describe el protocolo de replicación grupal de MGR. Puede ver algunas diferencias con la replicación maestro-esclavo tradicional (y la replicación semisincrónica).
En aras de la simplicidad, el algoritmo de identificación y la información relacionada con Paxos se omiten en la figura:
MGR admite modos de maestro único o multimaestro.
Al inicio, decida qué modo usar configurando la opción group_replication_single_primary_mode. Los requisitos de configuración para este valor en cada nodo son consistentes. Cuando está configurado en ON, indica modo maestro único. Cuando está configurado en APAGADO, indica modo maestro múltiple.
Durante el proceso de ejecución, el valor de group_replication_single_primary_mode no se puede modificar en línea, pero a partir de MySQL 8.0.13, el modo de ejecución se puede modificar en línea llamando a las dos UDF group_replication_switch_to_single_primary_mode() y group_replication_switch_to_multi_primary_mode(), o a través de MySQL Shell Revise.
En el modo maestro único, solo un nodo (principal) puede escribir datos y los otros nodos (secundarios) solo pueden leer datos. En el modo multimaestro, los datos se pueden leer y escribir en cualquier nodo al mismo tiempo.
MGR solo puede admitir hasta 9 nodos, independientemente del modo maestro único o multimaestro.
MGR consta de un conjunto de nodos, cada nodo tiene un nombre único, expresado en formato UUID. Los nodos pueden unirse o abandonar dinámicamente (o ser expulsados pasivamente) MGR.
El servicio de membresía de grupo de MGR se utiliza para mantener la información que define cada nodo activo. Esta información de nodo activo también se denomina vista de grupo. Cada nodo tiene una vista consistente del grupo, que indica qué miembros están activos en el grupo en un momento dado.
Además de mantener la coherencia cuando se envían las transacciones, cada nodo MGR también debe llegar a un consenso cuando cambia la vista del grupo. Cuando un nuevo nodo se une o un nodo existente se va, se activa un nuevo cambio de vista de grupo.
Cuando un nodo abandona voluntariamente el clúster, se activa la reconfiguración automática del clúster y los nodos restantes acuerdan la nueva vista del grupo. Sin embargo, si un nodo abandona accidentalmente el clúster debido a anomalías de la red o tiempo de inactividad, no se puede activar la reconfiguración automática. En este momento, el mecanismo de detección de fallas del clúster reconocerá este estado después de que el nodo salga por un período de tiempo y emitirá un grupo de reconfiguración. vista. La vista del grupo de reconfiguración requiere el consentimiento de la mayoría de los miembros. Cuando no se puede llegar a un consenso, no se puede lograr la reconfiguración automática y se requiere intervención manual. Las posibles razones de la imposibilidad de formar un consenso son que el número de nodos restantes no alcanza más de la mitad de los puntos del resumen, lo que significa que no se puede formar una mayoría.
Antes de que se confirme que un nodo está inactivo, o antes de que el grupo se reconfigure para eliminar el nodo fallido, permita que el nodo se desconecte brevemente y luego intente volver a unirse al clúster. En este caso, el nodo puede perder su estado anterior (datos de transacción), lo que puede provocar problemas como inconsistencia de datos si otros nodos le envían mensajes que contienen mensajes previos a la falla.
Para resolver este problema, a partir de MySQL 5.7.22, MGR comprobará si el nodo con la misma dirección + puerto se une al clúster nuevamente con una nueva identidad para confirmar si su identidad anterior todavía existe. En este momento, su nueva identidad no se puede agregar hasta que la identidad anterior se pueda eliminar del clúster. Nota: La función de la opción group_replication_member_expel_timeout es establecer un período de espera para que el nodo tenga más tiempo para intentar volver a unirse al clúster antes de ser desalojado oficialmente. Es decir, el nodo en el estado sospechoso aún puede intentar volver a unirse al clúster. antes del tiempo de espera. Actuar como nodo activo nuevamente.
Cuando un nodo excede el umbral group_replication_member_expel_timeout y es desalojado del clúster, o el nodo ejecuta STOP GROUP_REPLICATION para salir del clúster, o debido a un tiempo de inactividad del nodo, etc., el nodo debe volver a unirse al clúster con una nueva identidad.
MGR tiene su propio mecanismo de detección de fallas. Puede descubrir e informar qué nodo está en estado silencioso. Cuando se cumplen ciertas condiciones, el nodo se considerará muerto. Es un servicio distribuido de detección de fallas que proporciona información sobre qué nodos están (sospechados) muertos.
Cuando un nodo está en silencio (no envía mensajes activamente ni responde a mensajes de otros nodos), puede generar sospechas. Cuando el nodo A no ha recibido un mensaje del nodo B dentro de un tiempo determinado, se agota el tiempo de espera del mensaje y se levantan sospechas. Después de eso, si otros miembros del grupo están de acuerdo (acuerdo mayoritario) en que la sospecha del nodo es cierta, se considerará que el nodo ha fallado.
Si un nodo se desconecta de otros nodos debido a un fallo de la red, también puede sospechar que otros nodos han fallado. Pero como no puede formar una resolución mayoritaria, esta sospecha no es válida. En este momento, el nodo no puede realizar ninguna transacción de lectura y escritura y, como máximo, solo puede realizar transacciones de solo lectura.
Cuando la red es inestable, dos nodos cualesquiera pueden desconectarse y volverse a conectar con frecuencia. En teoría, todos los nodos pueden marcarse para desalojo y el clúster saldrá y será necesario reconstruirlo. Para evitar esta situación, a partir de MySQL 8.0.20, GCS rastreará los nodos marcados para desalojo y decidirá si un nodo sospechoso todavía se encuentra en la mayoría de los nodos, lo que mantiene al menos un nodo en el clúster sin salir. Cuando el nodo desalojado se elimine oficialmente del clúster, GCS eliminará el registro marcado para el desalojo para poder volver a agregarlo más tarde.
MGR se basa en el algoritmo distribuido de Paxos, por lo que requiere que una mayoría de nodos sobrevivan para garantizar la votación. Esto determina la cantidad de fallas de nodo que se pueden tolerar sin afectar la disponibilidad general del sistema. Suponiendo que el número total de nodos es n y el número de nodos que pueden tolerar fallas es f, su relación es: n = 2*f + 1. En resumen, la cantidad de nodos que pueden tolerar fallas no debe ser superior a la mitad del número total de nodos.
La siguiente tabla muestra la relación correspondiente entre diferentes números de nodo:
Debido al nivel personal limitado, inevitablemente hay errores y omisiones en la columna. No copie directamente los comandos y. métodos en el documento y aplicarlos directamente en un entorno de producción en línea. Los lectores deben comprenderlo y verificarlo completamente en el entorno de prueba antes de implementarlo oficialmente para evitar causar daños o daños al entorno de producción.
Disfruta de GreatSQL :)