Esta sección describe cómo actualizar la configuración de la replicación de grupos. Los pasos básicos para actualizar los miembros del grupo son los mismos que los pasos para actualizar una sola instancia. Con respecto al método de actualización, puede elegir específicamente la actualización in situ (usando el comando mysql_upgrade para actualizar el diccionario de datos basado en el archivo de datos original) o la actualización lógica (construya una nueva versión del servidor por adelantado, Los datos de la versión anterior se exportan de forma lógica y luego se importan a la nueva versión), según la cantidad de datos almacenados en el grupo. Generalmente, la actualización local es más rápida, por lo que se recomienda utilizar la actualización local para actualizar.
Durante la actualización en línea de un grupo, para maximizar la disponibilidad del grupo (en la medida de lo posible para garantizar la disponibilidad del grupo), es necesario realizar una actualización continua (actualización uno por uno) para los miembros del grupo. Por lo tanto, puede ser necesario ejecutar diferentes MySQL en un grupo al mismo tiempo Miembro de la versión Server. Existen algunas estrategias de compatibilidad cuando un grupo contiene miembros de diferentes versiones, que pueden combinar de forma segura miembros que ejecutan diferentes versiones de MySQL en el mismo grupo durante el proceso de actualización. Además, estas estrategias pueden afectar el orden en el que se asciende a los miembros del grupo de actualización. Para obtener más información, consulte "7.1 Miembros compatibles de diferentes versiones en un grupo".
Si el grupo se puede actualizar sin conexión, consulte "7.2. Actualización sin conexión de replicación de grupo" para conocer el proceso de actualización específico. Si necesita actualizar el grupo en línea (normalmente, el entorno de producción requiere una actualización en línea), consulte "7.3. Actualización en línea de replicación de grupo" para conocer los diferentes métodos de actualización del grupo con un tiempo de inactividad mínimo.
7.1. Miembros compatibles de diferentes versiones en un grupo
La replicación de grupo está controlada por versión de acuerdo con la versión de MySQL Server vinculada al complemento MGR. Por ejemplo, si un miembro se ejecuta en MySQL versión 5.7.26, entonces esta es la versión del complemento MGR. Utilice la siguiente declaración para verificar la versión de MySQL Server en los miembros del grupo:
root@localhost : (none):35: > SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_VERSION |
+-------------+-------------+----------------+
| node2 | 3306 | 8.0.17 |
| node3 | 3306 | 8.0.17 |
| node1 | 3306 | 8.0.17 |
+-------------+-------------+----------------+
3 rows in set (0.01 sec)
Para obtener la mejor compatibilidad y rendimiento, se recomienda que todos los miembros del grupo ejecuten la misma versión de MySQL Server, y también se recomienda ejecutar la misma versión del protocolo de comunicación de replicación de grupo. Sin embargo, durante la actualización en línea de un grupo, para maximizar la disponibilidad del grupo, puede ser necesario ejecutar miembros de diferentes versiones de MySQL Server al mismo tiempo. Debido a que algunas características entre diferentes versiones de MySQL pueden ser diferentes (por ejemplo: la versión más reciente puede admitir algunas funciones nuevas pero la versión anterior no, algunas funciones admitidas en la versión anterior se eliminan en la versión más reciente) , En este caso, puede haber problemas de incompatibilidad entre la versión anterior y la nueva. En este caso, si configura diferentes versiones de MySQL Server en un grupo, puede provocar que los miembros que dependen de funciones obsoletas fallen y también puede causar problemas con versiones anteriores que no admiten nuevas funciones en la nueva versión.
Para evitar estos problemas, la replicación de grupo admite algunas estrategias de compatibilidad para hacer que un grupo de miembros del grupo que se ejecute en diferentes versiones de MySQL Server sea seguro y compatible. Los miembros del grupo aplican estas políticas para decidir si unirse al grupo normalmente, o unirse al grupo en modo de solo lectura, o no unirse al grupo, dependiendo de qué opción pueda garantizar la seguridad de las operaciones entre el servidor recién agregado y los miembros existentes del grupo. Al realizar una actualización continua a un grupo, cada miembro debe abandonar el grupo primero, luego actualizar a la nueva versión y luego unirse al grupo nuevamente con la nueva versión. En este momento, los miembros del grupo deben coincidir con la política correspondiente para la nueva versión (el La política puede ser diferente de la política aplicada antes de la actualización del miembro del grupo).
La política de compatibilidad aplicada por los miembros que intentan unirse al grupo es la siguiente:
Si la versión de un servidor MySQL es inferior a la versión mínima ejecutada por los miembros del grupo existentes en el grupo, el servidor no puede unirse al grupo.
Si la versión de un servidor MySQL es la misma que la versión mínima que ejecutan los miembros existentes del grupo, entonces el servidor normalmente (y permitirá) unirse al grupo.
Después de que un servidor se une al grupo, si la versión del servidor MySQL que ejecuta es superior a la versión mínima ejecutada por los miembros del grupo existentes en el grupo, el miembro permanecerá en modo de solo lectura (si el grupo se ejecuta en modo primario único, los miembros recién agregados están en cualquier En todos los casos, el valor predeterminado es de solo lectura; si el grupo se ejecuta en modo de múltiples primarios, los miembros recién agregados pueden estar en modo de lectura y escritura).
El servidor que ejecuta MySQL 8.0.17 o superior considerará la versión de parche de la versión al verificar su compatibilidad (por ejemplo, el número de versión es 8.0.17, donde 8.0 representa la versión principal, 17 representa la versión de parche, que también se puede llamar menor Versión). Los servidores que ejecutan MySQL 8.0.16 o inferior o MySQL 5.7 solo consideran las versiones principales (por ejemplo, el número de versión es 8.0.16, donde 8.0 es la versión principal). Suponiendo un grupo en el que todos los miembros ejecutan la versión 8.0.13, la política de compatibilidad aplicada por el servidor que intenta unirse al grupo es la siguiente:
Un servidor que ejecuta MySQL 5.7.x no puede unirse al grupo.
Un servidor que ejecuta MySQL versión 8.0.16 puede unirse al grupo normalmente (porque aquí solo se considera la cadena 8.0 de la versión principal, que coincide con la cadena 8.0 considerada por los miembros existentes del grupo).
Un servidor que ejecuta MySQL versión 8.0.17 puede unirse al grupo, pero permanecerá en modo de solo lectura (porque el servidor recién agregado también considerará la versión 17 del parche, que es 8.0.17, mientras que los miembros existentes en el grupo solo considerarán cadenas 8.0).
Tenga en cuenta que cuando un servidor con una versión de MySQL anterior a la 5.7.27 se une a un grupo, verificará la versión de todos los miembros del grupo, para verificar si el número de versión principal de MySQL de cada miembro del grupo es menor. Por lo tanto, de acuerdo con el ejemplo anterior y la política de compatibilidad, si algún miembro del grupo está ejecutando la versión MySQL 8.0, esta verificación fallará, lo que provocará que el servidor de la versión MySQL anterior a la 5.7.27 no pueda unirse al grupo, incluso si otros miembros del grupo ya están ejecutando MySQL. En la versión 5.7, tampoco puede unirse al grupo. A partir de la versión MySQL 5.7.27, el servidor que se une al grupo solo verifica la versión principal mínima que ejecutan los miembros existentes del grupo. De esta manera, el servidor que se ejecuta en MySQL 5.7.27 y posterior puede unirse a un servidor que usa un MySQL 5.7.x mixto. El grupo de miembros de la versión.
En un grupo de modo multimaestro con diferentes versiones de MySQL Server, la replicación de grupo administrará automáticamente el estado de lectura-escritura y solo lectura de los miembros que ejecutan MySQL 8.0.17 o posterior. Si un miembro abandona el grupo, el miembro que ejecute la versión más baja actual se configurará automáticamente en modo de lectura y escritura. Al usar group_replication_switch_to_multi_primary_mode () UDF en línea para modificar un grupo de modo primario único a modo primario múltiple, la replicación de grupo establecerá automáticamente a los miembros en el modo correcto. Si un miembro que ejecuta la versión de MySQL Server es superior a la versión más baja del grupo, se configurará automáticamente en modo de solo lectura y el miembro que ejecuta la versión más baja se configurará automáticamente en modo lectura-escritura.
7.1.1. Actualizar miembros del grupo
Durante el proceso de actualización en línea, si el grupo está en modo maestro único, después de que el miembro que realiza la operación de actualización se desconecta (el miembro del grupo que realiza la operación de actualización debe estar desconectado, el miembro del grupo que no realiza la operación de actualización no necesita estar desconectado), el grupo no se ejecuta Los miembros del grupo de actualización elegirán un nuevo nodo principal de acuerdo con la estrategia de elección descrita en "1.3.1 Modo maestro único". Tenga en cuenta que si se requiere que el nodo primario permanezca siempre sin cambios (a menos que esté realizando la actualización en sí), primero debe realizar la actualización en todos los demás miembros del grupo y luego realizar la actualización en el nodo primario por último (cuando se actualiza el nodo primario, el nodo primario está fuera de línea debido a , Por lo tanto, el nuevo nodo principal será reelegido en el grupo. Una vez completada la actualización, si desea que el nodo principal siga siendo el miembro original, puede utilizar group_replication_set_as_primary () UDF para volver a designarlo como nodo principal).
Si el grupo está en modo de múltiples primarios, los miembros del grupo que pueden realizar operaciones de escritura normalmente durante el proceso de actualización serán cada vez menos, porque los miembros actualizados se colocarán en modo de solo lectura y volverán a unirse al grupo (esto es para evitar que la nueva versión Las funciones no se pueden copiar correctamente en la versión anterior). Si todos los miembros se actualizan a MySQL 8.0.17 y versiones posteriores, volverán automáticamente al modo de lectura y escritura. Pero para las versiones anteriores, una vez completada la actualización, debe configurar manualmente las variables del sistema super_read_only y read_only en cada miembro del grupo en OFF (configure el modo de lectura y escritura) para convertirlo en el nodo principal.
Nota: Para la comparación de versiones nuevas y antiguas, a partir de MySQL 8.0.17, se debe considerar el número de versión menor al comparar, y para las versiones 8.0.16 y anteriores, solo se considera el número de versión principal al comparar versiones.
Si necesita hacer que los miembros de la actualización retrocedan durante el proceso de actualización de miembros del grupo, o si necesita agregar un nuevo miembro al grupo, en una emergencia, puede permitir que un miembro cuya versión de MySQL Server sea inferior a la versión más baja del grupo se una al grupo (usando group Copie la variable del sistema group_replication_allow_local_lower_version_join para anular la política de compatibilidad normal. Debe tenerse en cuenta que establecer esta variable del sistema en ON no hará que el nuevo miembro sea compatible con el grupo. Por lo tanto, esta variable del sistema solo se puede usar con precaución en situaciones específicas. Para mayor prevención Consulte la descripción de la variable de sistema group_replication_allow_local_lower_version_join en "8. Variables del sistema de replicación de grupo").
7.1.2. Versión del protocolo de comunicación de copia de grupo
El número de versión del protocolo de comunicación de grupo utilizado por la replicación de grupo no es necesariamente el mismo que el número de versión de MySQL Server de los miembros del grupo (por ejemplo: la versión de protocolo de comunicación utilizada por MySQL Server 8.0.17 es 8.0.16 en lugar de 8.0.17, la versión de protocolo representa La versión más baja de MySQL Server admitida actualmente por este grupo, MySQL versión 5.7.14 admite mensajes comprimidos y MySQL versión 8.0.16 admite la segmentación de mensajes). Para ver la versión del protocolo de comunicación del grupo, puede ejecutar la siguiente declaración en cualquier miembro del grupo para consultar:
root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
Nota: La versión del protocolo de comunicación grupal devuelta por group_replication_get_communication_protocol () UDF representa la versión más baja de MySQL Server soportada actualmente por el grupo. Cuando group_replication_set_communication_protocol () UDF se usa para realizar la configuración del protocolo de comunicación grupal, el valor efectivo final puede ser diferente del valor pasado a la función. Por ejemplo: el valor pasado a esta función es 8.0.17 y el valor efectivo final es 8.0.16.
Cuando todos los miembros de un grupo de replicación se actualizan a una nueva versión de MySQL Server, la versión del protocolo de comunicación de replicación del grupo no se actualizará automáticamente, en caso de que aún sea necesario permitir que los miembros de la versión anterior se unan al grupo. Si después de actualizar a la nueva versión, se determina que no necesita admitir la versión anterior del servidor, y también desea usar algunas funciones adicionales de la nueva versión, puede usar la función UDF group_replication_set_communication_protocol () para actualizar la versión del protocolo de comunicación grupal (cualquiera en el grupo) Solo un miembro puede modificar el funcionamiento de la versión del protocolo de comunicación del grupo). Para obtener más información, consulte "4.1.4 Configuración de la versión del protocolo de comunicación del grupo".
7.2. Actualización sin conexión de la replicación de grupos
Para realizar una actualización sin conexión para la replicación de grupo, debe eliminar a todos los miembros del grupo del grupo uno por uno. Después de asegurarse de que el grupo está fuera de línea, realice actualizaciones de versión en cada servidor. Después de actualizar todas las versiones del servidor, reinicie el grupo normalmente. En un grupo en modo multimaestro, puede eliminar y cerrar miembros del grupo en cualquier orden. En un grupo de modo maestro único, primero debe eliminar y cerrar los servidores de los miembros de solo lectura uno por uno, y finalmente cerrar los servidores del miembro del nodo principal (nodo de escritura). Para saber cómo eliminar miembros del grupo y cerrar MySQL Server, consulte "7.3.2. Actualización de miembros de replicación de grupo".
Una vez que todos los miembros de un grupo se hayan actualizado correctamente a la nueva versión, cuando se reinicie el grupo, estos miembros utilizarán la nueva versión del protocolo de comunicación de replicación de grupo para conectarse. Si necesita permitir que una versión anterior de Server se una al grupo en este momento, puede usar la UDF group_replication_set_communication_protocol () para degradar la versión del protocolo de comunicación del grupo al número de versión del protocolo de comunicación compatible con la versión anterior (o ingresar directamente el número de versión de la versión anterior de MySQL Server)
7.3. Actualización en línea de la replicación de grupos
Cuando desee realizar una actualización de la versión de un grupo en ejecución y debe asegurarse de que el grupo brinde servicios al mundo exterior durante el proceso de actualización, debe utilizar el método de actualización correcto. Esta sección presenta algunos métodos de cómo realizar un grupo de actualización en línea.
7.3.1. Precauciones para la actualización en línea
Al actualizar un grupo en línea, se deben considerar los siguientes puntos:
Independientemente de cómo se actualicen los miembros del grupo, está prohibido realizar operaciones de escritura en los miembros hasta que los miembros del grupo se actualicen y se reincorporen al grupo.
Cuando un miembro detiene la replicación del grupo, la variable del sistema super_read_only se activará automáticamente, pero este valor modificado no es persistente, es decir, el valor modificado se sobrescribirá con la configuración del archivo de configuración o el valor predeterminado después de reiniciar el servidor.
Cuando los miembros de MySQL 5.7.22 o MySQL 8.0.11 intentan unirse a un grupo que ejecuta MySQL 5.7.21 o inferior, fallarán porque MySQL 5.7.21 no enviará el valor de la variable del sistema lower_case_table_names
7.3.2. Actualizar miembros de replicación de grupos
Esta sección describe los pasos necesarios para actualizar los miembros del grupo. Este proceso es parte del "7.3.3 Método de actualización en línea de copia de grupo". El método para actualizar a todos los miembros del grupo es común, pero debe tenerse en cuenta que el grupo se está ejecutando en modo de maestro único o en modo de maestro múltiple, lo que afectará el orden en que los miembros del grupo se actualizan y se vuelven a unir.
El proceso de actualización de los miembros del grupo incluye: eliminarlos del grupo, realizar la actualización de acuerdo con el método seleccionado de actualización de miembros y luego agregar los miembros mejorados al grupo nuevamente. Al actualizar miembros en un grupo de modo maestro único, se recomienda actualizar primero los nodos de solo lectura y luego actualizar los nodos de lectura y escritura (nodos primarios). Si los nodos de lectura y escritura deben actualizarse antes que los nodos de solo lectura, debe seleccionar uno antiguo. Los otros miembros de la versión sirven como nuevos nodos principales. Por lo tanto, para reducir la carga de trabajo, generalmente se recomienda que los nodos de lectura y escritura se actualicen en último lugar.
Actualizar miembros del grupo:
Utilice el cliente para iniciar sesión en el miembro del grupo que se actualizará y ejecute la instrucción STOP GROUP_REPLICATION para detener la replicación del grupo, y luego verifique la tabla performance_schema.replication_group_members para asegurarse de que el miembro está en el estado OFFLINE (tenga en cuenta que solo debe haber una fila en la tabla en este momento , Y el valor del campo MEMBER_STATE de este registro de fila es OFFLINE).
Al establecer la variable del sistema group_replication_start_on_boot = 0 para prohibir que el miembro se una automáticamente al grupo al reiniciar, después de que se completen las operaciones de actualización y configuración, vuelva a unir al miembro al grupo de forma manual y segura. Nota: Si el miembro que realiza la actualización establece la variable del sistema group_replication_start_on_boot = 1, si la operación de actualización falla, cuando se reinicia el servidor, el miembro fallido intentará unirse al grupo automáticamente.
Detenga el proceso de MySQL Server de los miembros del grupo. Por ejemplo, use el comando de apagado mysqladmin en el servidor donde se encuentra el servidor o inicie sesión en la base de datos y use la instrucción de apagado para detener el proceso del servidor de los miembros del grupo que necesitan actualizarse. En este momento, otros miembros del grupo continúan ejecutándose sin verse afectados.
Use in-situ (use el comando mysql_upgrade para actualizar el método del diccionario de datos) o use la nueva versión preinstalada y configurada del servidor para actualizar el derivado lógico. Cuando el servidor se reinicia después de la actualización, debido a que la variable del sistema group_replication_start_on_boot se establece en 0, la replicación del grupo no se iniciará automáticamente y se volverá a unir al grupo, por lo que se requieren operaciones manuales para volver a unirse al grupo.
Cuando se completa la actualización del miembro, la variable del sistema group_replication_start_on_boot debe establecerse en 1, para garantizar que el miembro pueda volver a unirse automáticamente al grupo después del próximo reinicio.
Utilice el cliente para iniciar sesión en el servidor actualizado y ejecute la instrucción START GROUP_REPLICATION para iniciar la replicación del grupo. Vuelva a unirse al servidor al grupo. En este punto, los metadatos de la replicación del grupo están listos en los miembros actualizados, por lo que generalmente no es necesario volver a configurar la replicación del grupo. Pero debe ponerse al día con la última transacción del grupo. Cuando se ponga al día con la última transacción del grupo, se convertirá en un miembro en línea de este grupo. Nota: Cuanto más tiempo se tarda en actualizar el servidor (es decir, más tiempo se tarda en dejar el grupo), mayor es la diferencia entre los datos del servidor y el grupo, y el tiempo necesario para volver a agregarlos al grupo. Cuantas más (porque puede haber más transacciones para ponerse al día).
Cuando el servidor actualizado se une a un grupo, si se encuentra que los miembros del grupo están ejecutando una versión anterior de MySQL Server, el servidor actualizado establecerá su variable de sistema super_read_only en on cuando se reincorpore al grupo. Esto puede garantizar que no se escriban datos nuevos en el servidor recién actualizado antes de que todos los miembros se actualicen a la nueva versión (evitar que los datos escritos en la nueva versión del servidor sean incompatibles con la versión anterior del servidor). En un grupo en modo multimaestro, cuando la actualización del grupo se completa y está lista para proporcionar servicios externos, los miembros que pretenden utilizar el modo maestro de escritura deben configurarse en modo lectura-escritura. A partir de MySQL 8.0.17, cuando todos los miembros de un grupo se actualizan a la misma versión, todos los miembros se configuran automáticamente en modo de lectura y escritura. Pero para versiones anteriores, debe configurar manualmente cada miembro que necesita realizar operaciones de lectura y escritura en el modo de lectura y escritura. Establecido por la siguiente declaración:
root@localhost : (none):30: > SET GLOBAL super_read_only=OFF; set global read_only=OFF;
Query OK, 0 rows affected (0.00 sec)
7.3.3. Método de actualización en línea para la replicación de grupos
Hay varias opciones para la actualización en línea de la replicación de grupos, que se pueden seleccionar de acuerdo con su situación real.
7.3.3.1. Actualización progresiva dentro del grupo
Actualización progresiva dentro del grupo: se refiere a que los miembros del grupo se eliminan del grupo uno por uno, realizan la actualización in situ (no es necesario migrar datos, no es necesario reemplazar el servidor) y luego se vuelven a unir al grupo después de que se completa la actualización. Durante el proceso de actualización, el grupo puede proporcionar servicios de lectura y escritura al mundo exterior, pero los miembros que se eliminan del grupo y realizan la actualización no tienen ninguna carga de trabajo durante el proceso de actualización (no se proporcionan servicios de solo lectura o lectura-escritura). Una vez completada la actualización, al volver a unirse al grupo, si hay miembros con un número de versión inferior en el grupo, se volverá a unir al grupo en modo de solo lectura (en este momento, solo se proporcionan servicios de solo lectura). Si los miembros recién agregados necesitan cambiar del modo de solo lectura al modo de lectura y escritura en el futuro, depende de si el grupo se está ejecutando en modo de maestro único o en modo de maestro múltiple.
Modo primario único: el método de actualización continua dentro del grupo es muy adecuado para el grupo de modo primario único. En el modo primario único, cuando se realiza una actualización continua, los nodos secundarios (nodos de solo lectura) se actualizarán uno por uno, y el nodo primario (nodo de lectura y escritura) Finalmente, realice la actualización, para que durante todo el proceso de actualización, pueda evitar la reelección tanto como sea posible. Por supuesto, en la actualización final del nodo principal, es inevitable reelegir al maestro, pero de acuerdo con este orden recomendado, la reelección solo ocurrirá una vez, es decir, se activará cuando se elimine el nodo principal del grupo y se realice la actualización. Vuelva a elegir al maestro una vez. Cuando se actualiza el último miembro (es decir, el nodo principal anterior), puede utilizar la UDF group_replication_set_as_primary () para reasignarlo como nodo principal. Por supuesto, si no le importa qué miembro del grupo es el nodo principal, puede reasignar el nodo principal sin usar UDF. Para conocer la estrategia de selección de maestro en el modo de maestro único, consulte "1.3.1 Modo de maestro único" para obtener más detalles.
Modo de múltiples primarios: para un grupo en modo de múltiples primarios, puede haber varios nodos primarios (nodos de lectura y escritura). Cuando se usa la actualización continua dentro del grupo, no hay una regla de orden de actualización específica (el orden de actualización de los miembros se puede determinar de acuerdo con la situación real). Sin embargo, antes de que todos los miembros del grupo se actualicen a la última versión, cuando los miembros actualizados se reincorporen al grupo, se verán obligados a establecer el modo de solo lectura (establezca la variable del sistema super_read_only = ON porque hay miembros con versiones inferiores en el grupo. Nota: cuando super_read_only = ON, read_only se establecerá automáticamente en ON, pero cuando super_read_only = OFF, read_only no se establecerá automáticamente en OFF), porque varios nodos en un grupo de modo multimaestro pueden proporcionar servicios de lectura y escritura al mismo tiempo Entonces, en este caso, la disponibilidad de escritura del grupo disminuirá gradualmente hasta que todos los miembros del grupo estén actualizados a la última versión. Cuando todos los miembros del grupo se actualizan a la última versión, si el número de versión de MySQL Server es menor que 8.0.16, se verá obligado a ser miembro del grupo en modo de solo lectura. Debe configurar manualmente las variables del sistema super_read_only = OFF, read_only = OFF para deshabilitar Leer (volver al modo lectura-escritura). Si el número de versión de MySQL Server es mayor o igual a 8.0.17, después de que todos los miembros se actualicen a la nueva versión, las variables del sistema super_read_only = OFF, read_only = OFF se configurarán automáticamente para desactivar solo lectura (volver al modo lectura-escritura). Para obtener información sobre la compatibilidad de versiones en modo multimaestro, consulte "1.3.2.3. Compatibilidad de versiones" para obtener más detalles.
Para obtener información completa sobre la compatibilidad de versiones en un grupo y cómo afecta el comportamiento del grupo durante el proceso de actualización, consulte "7.1. Miembros compatibles de diferentes versiones en un grupo".
PD: en un plan de actualización continua dentro de un grupo, los miembros del grupo se vuelven a unir al grupo original después de que se completa la actualización.
7.3.3.2. Migración y actualización progresiva
Actualización continua de migración: se refiere a que los miembros del grupo se eliminan del grupo uno por uno y, una vez realizada la actualización, no se vuelven a unir al grupo original, sino que utilizan los miembros actualizados para crear un segundo grupo (nuevo grupo). Para un grupo que se ejecuta en modo multimaestro, la cantidad de nodos principales (nodos de lectura y escritura) disminuirá gradualmente durante este proceso, lo que dará como resultado una menor disponibilidad de escritura. Sin embargo, para un grupo que se ejecuta en modo primario único, esto no afectará la disponibilidad de escritura del grupo (pero cuando el nodo de lectura y escritura se actualiza al final del grupo, la aplicación debe realizar un cambio de solicitud de escritura entre el grupo antiguo y el nuevo, y la aplicación se verá afectada en este momento).
En el proceso de actualización del grupo, debido a que el grupo que ejecuta la versión anterior siempre está en línea (proporcionando continuamente servicios de lectura-escritura y solo lectura al mundo exterior), el nuevo grupo compuesto por miembros con la versión actualizada debe ponerse al día con el proceso de actualización. Cualquier transacción recién escrita en el grupo. Por lo tanto, es necesario seleccionar un miembro del nuevo grupo como biblioteca esclava y establecer un canal de replicación maestro-esclavo asíncrono con el nodo principal (nodo de lectura y escritura) en el grupo anterior para ponerse al día con los datos más recientes. Para evitar accidentes al ponerse al día con los datos a través de los canales de replicación asíncronos, es necesario asegurarse de que los parámetros de configuración del sistema relacionados con la replicación de grupos y la replicación maestro-esclavo entre los grupos antiguo y nuevo sean completamente consistentes. Para un grupo que se ejecuta en modo maestro único, el miembro de la biblioteca esclava en el nuevo grupo debe ser el nodo principal (nodo de lectura y escritura) en el nuevo grupo. Para un grupo que se ejecuta en modo maestro múltiple, el miembro de la biblioteca esclava en el nuevo grupo puede ser un nuevo Cualquier miembro del grupo (nodo de lectura y escritura).
El proceso completo de actualización es aproximadamente el siguiente:
Elimine miembros del grupo original que ejecuta la versión anterior uno por uno, consulte "7.3.2. Actualización de miembros de copia de grupo".
Actualice la versión de MySQL Server que se ejecuta en los miembros del grupo excluido. Para conocer los pasos de actualización, consulte "Una fórmula para la pirámide de optimización del rendimiento de MySQL". Capítulo 2 Dos métodos de actualización de uso común para MySQL.
Cree un nuevo grupo con los miembros del grupo actualizados a la nueva versión. Los pasos para implementar el nuevo grupo se detallan en "2. Instalación e implementación de copias de grupo". Cabe señalar que, dado que el grupo anterior se está ejecutando, debe darle al grupo nuevo un nombre de grupo nuevo y usar el primer miembro actualizado para guiar al grupo nuevo, y los miembros actualizados posteriores pueden unirse al grupo nuevo.
Configure un canal de replicación asincrónico entre el grupo antiguo y el nuevo. Configure el nodo principal en el grupo antiguo como la biblioteca maestra para la replicación asincrónica y configure el nodo principal en el nuevo grupo como la biblioteca esclava para la replicación GTID.
Antes de redirigir (cambiar) la aplicación al nuevo grupo, debe asegurarse de que el nuevo grupo tenga una cantidad adecuada de miembros del grupo para que el nuevo grupo pueda responder normalmente cuando un miembro falla. Puede ver el tamaño del grupo del grupo antiguo y del grupo nuevo consultando la vista de miembros del grupo a través de la tabla performance_schema.replication_group_members en cualquier miembro del nuevo grupo. Después de asegurarse de esta información, puede bloquear la escritura de datos en el grupo antiguo (debe observar la diferencia entre el grupo antiguo y el nuevo). Retraso de replicación asincrónica entre el tiempo, este paso se puede realizar cuando el retraso no es demasiado grande), y espere a que el nuevo grupo se ponga al día con los datos más recientes del grupo anterior hasta que el nuevo grupo alcance todos los datos del grupo anterior, y luego cambie la aplicación al nuevo grupo , Y elimine la conexión de replicación asíncrona entre el grupo antiguo y el nuevo. Finalmente, actualice todos los miembros del grupo de la versión anterior. Una vez completada la actualización, agréguelos al nuevo grupo uno por uno.
PD: Migre el plan de actualización gradual. Después de que los miembros del grupo se actualicen, formarán un nuevo grupo y el servidor (host) seguirá siendo el original.
7.3.3.3. Actualización progresiva de réplicas
Actualización de copia continua: en comparación con los dos esquemas de "actualización continua dentro de un grupo" y "actualización continua de migración", los miembros del grupo no necesitan eliminar el grupo del grupo, pero usan una herramienta de respaldo para copiar las copias de datos del grupo en una En el nuevo grupo de servidores, realice la actualización uno por uno y cree un segundo grupo (nuevo grupo). Durante la actualización, debido a que el grupo anterior continúa brindando servicios en línea, los datos incrementales entre los grupos nuevo y antiguo deben pasarse entre los grupos nuevo y antiguo. Establecer un canal de replicación asincrónico para la sincronización de datos entre los grupos nuevo y antiguo (para conocer los requisitos para crear un canal de replicación asincrónico entre los grupos antiguo y nuevo, consulte "7.3.3.2. Migración y actualización progresiva"). Cuando el nuevo grupo alcance los últimos datos del grupo antiguo, se aplicará El acceso al programa se cambia al nuevo grupo. Para los grupos que se ejecutan en modo multimaestro, la cantidad de nodos primarios (nodos de lectura y escritura) no se reducirá durante el proceso de actualización, por lo que la disponibilidad de escrituras no se verá afectada (por lo tanto, este método de actualización es muy adecuado para grupos que se ejecutan en modo multimaestro) . Para los grupos que se ejecutan en modo primario único, la disponibilidad de escritura tampoco se ve afectada.
El proceso completo de actualización es aproximadamente el siguiente:
Utilice la nueva versión del paquete del servidor para inicializar e instalar el nuevo servidor Es necesario asegurarse de que el número de miembros de la nueva versión pueda responder normalmente cuando un miembro falla. Tenga en cuenta que no es necesario crear un grupo en la nueva versión del servidor en este momento, solo use la nueva versión del paquete para inicializar e instalar el servidor de la base de datos, y asegúrese de que el servidor pueda iniciarse normalmente.
Realice una copia de seguridad de los datos existentes de un miembro del grupo original (copia de seguridad completa). Para conocer los pasos detallados de la copia de seguridad, consulte "4.6. Uso de datos de copia de seguridad para restaurar miembros fallidos o expandir miembros nuevos en la replicación del grupo".
Utilice los datos de la copia de seguridad para restaurar en el servidor donde va a crear un nuevo grupo y realice una actualización in situ.
Cree un nuevo grupo con el servidor actualizado a la nueva versión. Los pasos para implementar el nuevo grupo se detallan en "2. Instalación e implementación de copias de grupo". Cabe señalar que, dado que el grupo anterior se está ejecutando, debe darle al nuevo grupo un nuevo nombre de grupo y usar el primer servidor actualizado para guiar al nuevo grupo, y el servidor actualizado posterior puede unirse al nuevo grupo.
Configure un canal de replicación asincrónico entre el grupo antiguo y el nuevo. Configure el nodo principal en el grupo antiguo como la biblioteca maestra para la replicación asincrónica y configure el nodo principal en el nuevo grupo como la biblioteca esclava para la replicación GTID.
Una vez que los datos en el nuevo grupo están lo suficientemente retrasados en comparación con la replicación del grupo anterior, se puede realizar el cambio de aplicación (redirigir el acceso de la aplicación al nuevo grupo), y luego se elimina el canal de replicación asíncrono entre los grupos antiguo y nuevo (detalles Consulte "7.3.3.2. Migración y actualización progresiva" para conocer los requisitos de cambio de aplicación).
PD: El esquema de actualización de copia continua, después de que los miembros del grupo se actualizan, los miembros del grupo y los servidores (hosts) son completamente nuevos.
| Sobre el autor
Luo Xiaobo · Experto en tecnología de bases de datos
Uno de los autores de "A Thousand Golden Recipes-MySQL Performance Optimization Pyramid Rule". Familiarizado con la arquitectura MySQL, bueno en el ajuste general de bases de datos, me gusta especializarse en tecnología de código abierto y interesado en la promoción de la tecnología de código abierto, ha compartido muchos temas de bases de datos públicas en línea y fuera de línea, y ha publicado casi 100 artículos de investigación relacionados con bases de datos.
Otras lecturas
Seguridad de replicación de grupo | Comprensión completa de la replicación de grupo de MySQL 8.0
Monitoreo de replicación de grupo | Una comprensión integral de la replicación de grupo de MySQL 8.0
El texto completo ha terminado.
Disfrute de MySQL 8.0 :)
La clase "MySQL Core Optimization" de Teacher Ye se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la práctica de MySQL 8.0