Migración de red sin tiempo de inactividad con MySQL Galera Cluster utilizando el nodo de retransmisión

El aprovisionamiento automático de nodos de Galera Cluster simplifica la complejidad de escalar un clúster de base de datos con coherencia de datos garantizada. SST e IST mejoran la facilidad de uso de la sincronización de datos inicial sin necesidad de hacer una copia de seguridad manual de la base de datos y copiarla en el nuevo nodo. Combine esto con la capacidad de Galera de tolerar diferentes configuraciones de red (por ejemplo, replicación WAN), ahora podemos migrar la base de datos entre diferentes redes aisladas sin interrupción del servicio.

En esta publicación de blog, veremos cómo migrar nuestro MySQL Galera Cluster sin tiempo de inactividad. Moveremos la base de datos de Amazon Web Service (AWS) EC2 a Google Cloud Platform (GCP) Compute Engine, con la ayuda de un nodo de retransmisión. Tenga en cuenta que tuvimos una publicación de blog similar en el pasado, pero esta utiliza un enfoque diferente.

El siguiente diagrama simplifica nuestro plan de migración:

Preparación del sitio antiguo

Dado que ambos sitios no pueden comunicarse entre sí debido al grupo de seguridad o al aislamiento de VPC, necesitamos tener un nodo de retransmisión para unir estos dos sitios. Este nodo se puede ubicar en cualquier sitio, pero debe poder conectarse a uno o más nodos en el otro lado en el puerto 3306 (MySQL), 4444 (SST), 4567 (gcomm) y 4568 (IST). Esto es lo que ya tenemos y cómo escalaremos el sitio anterior:

También puede usar un nodo de Galera existente (por ejemplo, el tercer nodo) como nodo de retransmisión, siempre que tenga conectividad con el otro lado. La desventaja es que la capacidad del clúster se reducirá a dos, porque un nodo se usará para SST y retransmitirá el flujo de replicación de Galera entre sitios. Según el tamaño del conjunto de datos y la conexión entre los sitios, esto puede generar problemas de confiabilidad de la base de datos en el clúster actual.

Por lo tanto, vamos a utilizar un cuarto nodo para reducir el riesgo en el clúster de producción actual cuando se sincroniza con el otro lado. En primer lugar, cree una nueva instancia en el Panel de AWS con una dirección IP pública (para que pueda comunicarse con el mundo exterior) y permita los puertos de comunicación necesarios de Galera (TCP 3306, 4444, 4567-4568).

Implemente el cuarto nodo (nodo de retransmisión) en el sitio anterior. Si está utilizando ClusterControl, simplemente puede usar la función "Agregar nodo" para escalar el clúster (no olvide configurar SSH sin contraseña desde el nodo de ClusterControl a este cuarto host de antemano):

Asegúrese de que el nodo de retransmisión esté sincronizado con el clúster actual y pueda comunicarse con el otro lado.

Desde el nuevo sitio, nos conectaremos al nodo de retransmisión ya que este es el único nodo que tiene conectividad con el mundo exterior.

Implementación de nuevo sitio

En el nuevo sitio, implementaremos una configuración similar con un nodo ClusterControl y un clúster Galera de tres nodos. Ambos sitios deben usar la misma versión de MySQL. Esta es nuestra arquitectura en el nuevo sitio:

Con ClusterControl, la implementación del nuevo clúster está a solo un par de clics y es una función gratuita en la edición comunitaria. Vaya a ClusterControl -> Implementar clúster de base de datos -> MySQL Galera y siga el asistente de implementación:

Haga clic en Implementar y supervise el progreso en Actividad -> Trabajos -> Crear clúster. Una vez hecho esto, debería tener lo siguiente en el tablero:

En este punto, tiene dos clústeres de Galera separados:4 nodos en el sitio anterior y 3 nodos en el sitio nuevo.

Conectando Ambos Sitios

En el sitio nuevo (GCP), elija un nodo para comunicarse con el nodo de retransmisión en el sitio anterior. Vamos a elegir galera-gcp1 como conector para el nodo de retransmisión (galera-aws4). El siguiente diagrama ilustra nuestro plan puente:

Las cosas importantes para configurar son los siguientes parámetros:

wsrep_sst_donor :El wsrep_node_name del nodo donante. En galera-gcp1, establezca el donante en galera-aws4.
wsrep_sst_auth :Las credenciales de usuario de SST en formato de nombre de usuario:contraseña deben seguir el sitio anterior (AWS).
wsrep_sst_receive_address :la dirección IP que recibirá SST en el nodo de unión. En galera-gcp1, establezca esto en la dirección IP pública de este nodo.
wsrep_cluster_address :Cadena de conexión Galera. En galera-gcp1, agregue la dirección IP pública de galera-aws4.
wsrep_provider_opciones :
- gmcast.segment:el valor predeterminado es 0. Establezca un número entero diferente en todos los nodos en GCP.

En el nodo de retransmisión (galera-aws4), recupere wsrep_node_name:

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

En my.cnf de galera-gcp1, configure wsrep_sst_donor valor al wsrep_node_name del nodo de retransmisión y wsrep_sst_receive_address a la dirección IP pública de galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
En todos los nodos de GCP, asegúrese de que wsrep_sst_auth el valor es idéntico siguiendo el sitio anterior (AWS) y cambie el segmento de Galera a 1 (para que Galera sepa que ambos sitios están en redes diferentes):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
En galera-gcp1, establezca la wsrep_cluster_address para incluir la dirección IP pública del nodo de retransmisión:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Solo modifique wsrep_cluster_address en galera-gcp1. No modifique este parámetro en galera-gcp2 y galera-gcp3.
Detén todos los nodos en GCP. Si está utilizando ClusterControl, vaya al menú desplegable Acciones de clúster -> Detener clúster. También debe desactivar la recuperación automática tanto a nivel de clúster como de nodo, de modo que ClusterControl no intente recuperar los nodos fallidos.

Ahora la parte de sincronización. Inicie galera-gcp1. Puede ver en el registro de errores de MySQL en el nodo donante que SST se inicia entre el nodo de retransmisión (10.0.0.13) mediante una dirección pública en galera-gcp1 (35.197.136.232):

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Tenga en cuenta que, en este momento, galera-gcp1 se inundará con las siguientes líneas:

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Puede ignorar esta advertencia sin problemas, ya que galera-gcp1 sigue intentando ver los nodos restantes más allá del nodo de retransmisión en AWS.

Una vez que se completa SST en galera-gcp1, ClusterControl en GCE no podrá conectar los nodos de la base de datos debido a la falta de GRANT (los GRANT existentes se anularon después de la sincronización desde AWS). Entonces, esto es lo que debemos hacer después de que SST se complete en galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Una vez hecho esto, ClusterControl informará correctamente el estado de galera-gcp1 como se destaca a continuación:
La última parte es iniciar los restantes galera-gcp2 y galera-gcp3, un nodo a la vez. Vaya a ClusterControl -> Nodos -> elija el nodo -> Iniciar nodo. Una vez que todos los nodos estén sincronizados, debería obtener 7 como el tamaño del clúster:

El clúster ahora está funcionando en ambos sitios y el escalamiento horizontal está completo.

Desmantelamiento

Una vez que se completa la migración y todos los nodos están sincronizados, puede comenzar a cambiar su aplicación al nuevo clúster en GCP:

En este punto, los datos de MySQL se replican en todos los nodos hasta la clausura. El rendimiento de la replicación será tan bueno como lo permita el nodo más lejano del clúster. El nodo de retransmisión es crítico, ya que transmite conjuntos de escritura al otro lado. Desde el punto de vista de la aplicación, se recomienda escribir en un solo sitio a la vez, lo que significa que tendrá que comenzar a redirigir las lecturas/escrituras desde AWS y servirlas desde el clúster de GCP.

Para retirar los antiguos nodos de la base de datos y pasar al clúster en GCP, debemos realizar un apagado correcto (un nodo a la vez) en AWS. Es importante cerrar los nodos correctamente, ya que el sitio de AWS contiene la mayoría de los nodos (4/7) para este clúster. Apagarlos todos a la vez hará que el clúster en GCP pase a un estado no primario, lo que obligará al clúster a rechazar la operación. Asegúrese de que el último nodo que se apague en el lado de AWS sea el nodo de retransmisión.

No olvide actualizar los siguientes parámetros en galera-gcp1 en consecuencia:

wsrep_cluster_address - Eliminar la dirección IP pública del nodo de retransmisión.
wsrep_sst_donor - Comenta esta línea. Deje que Galera seleccione automáticamente al donante.
wsrep_sst_receive_address - Comenta esta línea. Deje que Galera elija automáticamente la interfaz de recepción.

Su Galera Cluster ahora se ejecuta en una plataforma, hosts y red completamente nuevos sin un segundo de tiempo de inactividad en su servicio de base de datos durante la migración. ¿Qué tan genial es eso?