Creación de un Hot Standby en Amazon AWS con MariaDB Cluster

Galera Cluster 4.0 se lanzó por primera vez como parte de MariaDB 10.4 y hay muchas mejoras significativas en esta versión. La función más impresionante de esta versión es Streaming Replication, que está diseñada para manejar los siguientes problemas.

Problemas con transacciones largas
Problemas con grandes transacciones
Problemas con puntos calientes en las tablas

En un blog anterior, profundizamos en la nueva función Streaming Replication en una serie de blogs de dos partes (Parte 1 y Parte 2). Parte de esta nueva característica en Galera 4.0 son las nuevas tablas del sistema que son muy útiles para consultar y verificar los nodos de Galera Cluster y también los registros que se han procesado en Streaming Replication.

También en blogs anteriores, también le mostramos la manera fácil de implementar un clúster MySQL Galera en AWS y también cómo implementar un clúster MySQL Galera 4.0 en Amazon AWS EC2.

Percona aún no ha lanzado un GA para su Percona XtraDB Cluster (PXC) 8.0, ya que algunas funciones aún están en desarrollo, como la función MySQL wsrep WSREP_SYNC_WAIT_UPTO_GTID que parece no estar presente todavía (al menos en la versión PXC 8.0.15-5-27dev.4.2). Sin embargo, cuando se lance PXC 8.0, estará repleto de excelentes características como...

Clúster resistente mejorado
Clúster compatible con la nube
embalaje mejorado
Soporte de cifrado
DDL atómico

Mientras esperamos el lanzamiento de PXC 8.0 GA, cubriremos en este blog cómo puede crear un nodo Hot Standby en Amazon AWS para Galera Cluster 4.0 usando MariaDB.

¿Qué es Hot Standby?

Una espera activa es un término común en informática, especialmente en sistemas altamente distribuidos. Es un método de redundancia en el que un sistema se ejecuta simultáneamente con un sistema primario idéntico. Cuando ocurre una falla en el nodo principal, el modo de espera en caliente reemplaza inmediatamente al sistema principal. Los datos se reflejan en ambos sistemas en tiempo real.

Para los sistemas de bases de datos, un servidor de espera activo suele ser el segundo nodo después del maestro principal que se ejecuta en recursos potentes (igual que el maestro). Este nodo secundario debe ser tan estable como el maestro principal para funcionar correctamente.

También sirve como un nodo de recuperación de datos si el nodo maestro o todo el clúster deja de funcionar. El nodo de espera en caliente reemplazará al nodo o clúster fallido mientras atiende continuamente la demanda de los clientes.

En Galera Cluster, todos los servidores que forman parte del clúster pueden funcionar como un nodo de reserva. Sin embargo, si la región o el clúster completo se cae, ¿cómo podrá hacer frente a esto? Crear un nodo en espera fuera de la región o red específica de su clúster es una opción aquí.

En la siguiente sección, le mostraremos cómo crear un nodo en espera en AWS EC2 usando MariaDB.

Implementación de Hot Standby en Amazon AWS

Anteriormente, le mostramos cómo puede crear un clúster de Galera en AWS. Es posible que desee leer Implementación de MySQL Galera Cluster 4.0 en Amazon AWS EC2 en caso de que sea nuevo en Galera 4.0.

La implementación de su nodo de espera en caliente puede realizarse en otro conjunto de Galera Cluster que usa replicación síncrona (consulte este blog Migración de red sin tiempo de inactividad con MySQL Galera Cluster usando el nodo de retransmisión) o mediante la implementación de un nodo MySQL/MariaDB asíncrono . En este blog, configuraremos e implementaremos el nodo de espera activa que se replica de forma asíncrona desde uno de los nodos de Galera.

Configuración del clúster de Galera

En esta configuración de muestra, implementamos un clúster de 3 nodos con la versión MariaDB 10.4.8. Este clúster se está implementando en la región EE. UU. Este (Ohio) y la topología se muestra a continuación:

Usaremos el servidor 172.31.26.175 como maestro para nuestro esclavo asíncrono que servirá como nodo de reserva.

Configuración de su instancia EC2 para el nodo Hot Standby

En la consola de AWS, vaya a EC2 que se encuentra en la sección Cómputo y haga clic en Iniciar instancia para crear una instancia de EC2 como se muestra a continuación.

Crearemos esta instancia en la región EE.UU. Oeste (Oregón). Para su tipo de sistema operativo, puede elegir qué servidor le gusta (prefiero Ubuntu 18.04) y elegir el tipo de instancia según su tipo de destino preferido. Para este ejemplo, usaré t2.micro ya que no requiere ninguna configuración sofisticada y es solo para esta implementación de muestra.

Como mencionamos anteriormente, es mejor que su nodo de espera en caliente esté ubicado en una región diferente y no dentro de la misma región. Por lo tanto, en caso de que el centro de datos regional se caiga o sufra una interrupción de la red, su modo de espera en caliente puede ser su objetivo de conmutación por error cuando las cosas salen mal.

Antes de continuar, en AWS, diferentes regiones tendrán su propia nube privada virtual (VPC) y su propia red. Para poder comunicarnos con los nodos del clúster de Galera, primero debemos definir un emparejamiento de VPC para que los nodos puedan comunicarse dentro de la infraestructura de Amazon y no necesiten salir de la red, lo que solo agrega problemas de sobrecarga y seguridad.

Primero, vaya a su VPC desde donde residirá su nodo de espera activa, luego vaya a Peering Connections. Luego, debe especificar la VPC de su nodo en espera y la VPC del clúster de Galera. En el siguiente ejemplo, tenemos us-west-2 interconectando a us-east-2.

Una vez creado, verá una entrada debajo de sus Peering Connections. Sin embargo, debe aceptar la solicitud de la VPC del clúster de Galera, que se encuentra en us-east-2 en este ejemplo. Véase más abajo,

Una vez aceptado, no olvide agregar el CIDR a la tabla de enrutamiento. Consulte este blog externo VPC Peering sobre cómo hacerlo después de VPC Peering.

Ahora, regresemos y sigamos creando el nodo EC2. Asegúrese de que su grupo de seguridad tenga las reglas correctas o los puertos necesarios que deben abrirse. Consulte el manual de configuración del cortafuegos para obtener más información al respecto. Para esta configuración, solo configuro Todo el tráfico para que se acepte, ya que esto es solo una prueba. Véase más abajo,

Al crear su instancia, asegúrese de haber configurado la VPC correcta y haber definido su subred adecuada. Puedes consultar este blog en caso de que necesites ayuda al respecto.

Configuración del esclavo asíncrono de MariaDB

Paso uno

Primero necesitamos configurar el repositorio, agregar las claves del repositorio y actualizar la lista de paquetes en el caché del repositorio,

$ vi /etc/apt/sources.list.d/mariadb.list

$ apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

$ apt update

Paso dos

Instalar los paquetes de MariaDB y sus binarios requeridos

$ apt-get install mariadb-backup  mariadb-client mariadb-client-10.4 libmariadb3 libdbd-mysql-perl mariadb-client-core-10.4 mariadb-common mariadb-server-10.4 mariadb-server-core-10.4 mysql-common

Paso tres

Ahora, hagamos una copia de seguridad usando xbstream para transferir los archivos a la red desde uno de los nodos en nuestro Galera Cluster.

## Borre el directorio de datos del MySQL recién instalado en su nodo de espera activa.

$ systemctl stop mariadb

$ rm -rf /var/lib/mysql/*

## Luego, en el nodo de espera activo, ejecute esto en la terminal,

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | mbstream -x -C /var/lib/mysql

## Luego, en el maestro de destino, es decir, uno de los nodos en su Galera Cluster (que es el nodo 172.31.28.175 en este ejemplo), ejecute esto en la terminal,

$ mariabackup  --backup --target-dir=/tmp --stream=xbstream | socat - TCP4:172.32.31.2:9999

donde 172.32.31.2 es la IP del nodo de reserva del host.

Cuarto Paso

Prepare su archivo de configuración de MySQL. Como esto está en Ubuntu, estoy editando el archivo en /etc/mysql/my.cnf y con el siguiente ejemplo my.cnf tomado de nuestra plantilla ClusterControl,

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

# log_output = FILE



#Slow logging    

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF



### INNODB OPTIONS

innodb_buffer_pool_size=245M

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path = ibdata1:100M:autoextend

## You may want to tune the below depending on number of cores and disk sub

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=64M

innodb_log_buffer_size=16M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

# innodb_file_format = barracuda

innodb_flush_method = O_DIRECT

innodb_rollback_on_timeout=ON

# innodb_locks_unsafe_for_binlog = 1

innodb_autoinc_lock_mode=2

## avoid statistics update when doing e.g show tables

innodb_stats_on_metadata=0

default_storage_engine=innodb



# CHARACTER SET

# collation_server = utf8_unicode_ci

# init_connect = 'SET NAMES utf8'

# character_set_server = utf8



# REPLICATION SPECIFIC

server_id=1002

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=ON

report_host=172.31.29.72

gtid_ignore_duplicates=ON

gtid_strict_mode=ON



# OTHER THINGS, BUFFERS ETC

key_buffer_size = 24M

tmp_table_size = 64M

max_heap_table_size = 64M

max_allowed_packet = 512M

# sort_buffer_size = 256K

# read_buffer_size = 256K

# read_rnd_buffer_size = 512K

# myisam_sort_buffer_size = 8M

skip_name_resolve

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type = 0

query_cache_size = 0

table_open_cache=1024

lower_case_table_names=0

# 5.6 backwards compatibility (FIXME)

# explicit_defaults_for_timestamp = 1



performance_schema = OFF

performance-schema-max-mutex-classes = 0

performance-schema-max-mutex-instances = 0



[MYSQL]

socket=/var/lib/mysql/mysql.sock

# default_character_set = utf8

[client]

socket=/var/lib/mysql/mysql.sock

# default_character_set = utf8

[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet = 512M

# default_character_set = utf8



[xtrabackup]



[MYSQLD_SAFE]

# log_error = /var/log/mysqld.log

basedir=/usr/

# datadir = /var/lib/mysql

Por supuesto, puede cambiar esto según su configuración y requisitos.

Paso cinco

Prepare la copia de seguridad del paso n.º 3, es decir, la copia de seguridad final que ahora se encuentra en el nodo de espera activa ejecutando el siguiente comando,

$ mariabackup --prepare --target-dir=/var/lib/mysql

Paso Seis

Establezca la propiedad del directorio de datos en el nodo de espera en caliente,

$ chown -R mysql.mysql /var/lib/mysql

Séptimo Paso

Ahora, inicie la instancia de MariaDB

$  systemctl start mariadb

Paso Ocho

Por último, necesitamos configurar la replicación asíncrona,

## Crear el usuario de replicación en el nodo principal, es decir, el nodo en el clúster de Galera

MariaDB [(none)]> CREATE USER 'cmon_replication'@'172.32.31.2' IDENTIFIED BY 'PahqTuS1uRIWYKIN';

Query OK, 0 rows affected (0.866 sec)

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'cmon_replication'@'172.32.31.2';

Query OK, 0 rows affected (0.127 sec)

## Obtenga la posición del esclavo GTID de xtrabackup_binlog_info de la siguiente manera,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

## Luego configure la replicación esclava de la siguiente manera,

MariaDB [(none)]> SET GLOBAL gtid_slave_pos='1000-1000-120454';

Query OK, 0 rows affected (0.053 sec)

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.31.28.175', MASTER_USER='cmon_replication', master_password='PahqTuS1uRIWYKIN', MASTER_USE_GTID = slave_pos;

## Ahora, verifique el estado del esclavo,

MariaDB [(none)]> show slave status \G

*************************** 1. row ***************************

                Slave_IO_State: Waiting for master to send event

                   Master_Host: 172.31.28.175

                   Master_User: cmon_replication

                   Master_Port: 3306

                 Connect_Retry: 60

               Master_Log_File: 

           Read_Master_Log_Pos: 4

                Relay_Log_File: relay-bin.000001

                 Relay_Log_Pos: 4

         Relay_Master_Log_File: 

              Slave_IO_Running: Yes

             Slave_SQL_Running: Yes

               Replicate_Do_DB: 

           Replicate_Ignore_DB: 

            Replicate_Do_Table: 

        Replicate_Ignore_Table: 

       Replicate_Wild_Do_Table: 

   Replicate_Wild_Ignore_Table: 

                    Last_Errno: 0

                    Last_Error: 

                  Skip_Counter: 0

           Exec_Master_Log_Pos: 4

               Relay_Log_Space: 256

               Until_Condition: None

                Until_Log_File: 

                 Until_Log_Pos: 0

            Master_SSL_Allowed: No

            Master_SSL_CA_File: 

            Master_SSL_CA_Path: 

               Master_SSL_Cert: 

             Master_SSL_Cipher: 

                Master_SSL_Key: 

         Seconds_Behind_Master: 0

 Master_SSL_Verify_Server_Cert: No

                 Last_IO_Errno: 0

                 Last_IO_Error: 

                Last_SQL_Errno: 0

                Last_SQL_Error: 

   Replicate_Ignore_Server_Ids: 

              Master_Server_Id: 1000

                Master_SSL_Crl: 

            Master_SSL_Crlpath: 

                    Using_Gtid: Slave_Pos

                   Gtid_IO_Pos: 1000-1000-120454

       Replicate_Do_Domain_Ids: 

   Replicate_Ignore_Domain_Ids: 

                 Parallel_Mode: conservative

                     SQL_Delay: 0

           SQL_Remaining_Delay: NULL

       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

              Slave_DDL_Groups: 0

Slave_Non_Transactional_Groups: 0

    Slave_Transactional_Groups: 0

1 row in set (0.000 sec)

Agregar su nodo Hot Standby a ClusterControl

Si está utilizando ClusterControl, es fácil monitorear la salud de su servidor de base de datos. Para agregar esto como esclavo, seleccione el clúster de nodos de Galera que tiene y luego vaya al botón de selección como se muestra a continuación para Agregar esclavo de replicación:

Haga clic en Agregar esclavo de replicación y elija agregar un esclavo existente como se muestra a continuación,

Nuestra topología parece prometedora.

Como puede notar, nuestro nodo 172.32.31.2 actúa como nuestro modo de espera activo El nodo tiene un CIDR diferente que tiene el prefijo 172.32.% us-west-2 (Oregón), mientras que los otros nodos tienen un 172.31.% ubicado en us-east-2 (Ohio). Están totalmente en una región diferente, por lo que en caso de que se produzca una falla en la red en sus nodos de Galera, puede realizar la conmutación por error a su nodo de espera en caliente.

Conclusión

Crear un Hot Standby en Amazon AWS es fácil y directo. Todo lo que necesita es determinar sus requisitos de capacidad y su topología de red, seguridad y protocolos que deben configurarse.

Usar VPC Peering ayuda a acelerar la intercomunicación entre diferentes regiones sin tener que ir a la Internet pública, por lo que la conexión permanece dentro de la infraestructura de red de Amazon.

El uso de la replicación asíncrona con un esclavo, por supuesto, no es suficiente, pero este blog sirve como base sobre cómo puede iniciar esto. Ahora puede crear fácilmente otro clúster donde el esclavo asíncrono se replica y crear otra serie de clústeres de Galera que sirvan como sus nodos de recuperación ante desastres, o también puede usar la variable gmcast.segment en Galera para replicar sincrónicamente como lo que tenemos en este blog.