sql >> Base de Datos >  >> RDS >> Mysql

Cómo implementar Percona Server para MySQL para alta disponibilidad

Percona Server para MySQL 8.0 ofrece una serie de soluciones de agrupación en clúster para alta disponibilidad listas para usar:

  • Maestro único:
    • Replicación asíncrona
    • Replicación semisincrónica
  • Multimaestro:
    • Replicación de grupos
    • InnoDB Cluster (una combinación de MySQL Router, MySQL Shell y Percona Server con Group Replication)

La solución más popular, probada en batalla y altamente escalable es, por supuesto, la replicación asíncrona. En esta publicación de blog, implementaremos una configuración de replicación de Percona Server específicamente para alta disponibilidad. Las instrucciones descritas aquí se basan en CentOS 7.

Instalación del servidor Percona

Para una alta disponibilidad, necesitamos al menos dos nodos en una configuración de replicación maestro-esclavo simple:

  • db1 - maestro (192.168.0.61)
  • db2 - esclavo (192.168.0.62)

Los pasos descritos en esta sección deben realizarse en todos los nodos de la base de datos (db1 y db2). Comenzaremos instalando el paquete del repositorio de Percona:

$ yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

La última versión estable en este momento es Percona Server para MySQL 8.0, pero de manera predeterminada, el paquete del repositorio solo está configurado hasta la versión 5.7. El paquete percona-release contiene un script que puede habilitar repositorios adicionales para los productos más nuevos. Ejecutemos ese script y habilitemos los repositorios 8.0:

$ percona-release setup ps80

Luego, instale la versión más reciente de Percona Server y Percona Xtrabackup:

$ yum -y install percona-server-server percona-xtrabackup-80

En este momento, debe tener instalado un servidor Percona para MySQL 8.0.21. Todos los paquetes de dependencia se instalarán como paquetes de compatibilidad compartida, compartidos y de cliente. Luego podemos habilitar el servicio MySQL al inicio e iniciar el servicio:

$ systemctl enable mysql
$ systemctl start mysql

Se generará una nueva contraseña de root durante el primer inicio. Necesitamos recuperar la información de la contraseña raíz primero del registro de errores de MySQL (el valor predeterminado es /var/log/mysqld.log en sistemas basados ​​en RHEL):

$ cat /var/log/mysqld.log | grep temporary
2020-11-06T04:53:07.402040Z 6 [Note] [MY-010454] [Server] A temporary password is generated for [email protected]: o%(_M>t1)R-P

Como puede ver, la contraseña generada es "o%(_M>t1)R-P". A continuación, debemos realizar una tarea posterior a la instalación para asegurar la instalación del servidor MySQL. Ejecute el siguiente comando:

$ mysql_secure_installation

Securing the MySQL server deployment.

Enter password for user root:

The existing password for the user account root has expired. Please set a new password.


New password:
Re-enter new password:

The 'validate_password' component is installed on the server.
The subsequent steps will run with the existing configuration
of the component.

Using existing password for root.


Estimated strength of the password: 100
Change the password for root ? ((Press y|Y for Yes, any other key for No) : y

New password:

Re-enter new password:

Estimated strength of the password: 100

Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y

By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.

You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.

Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.

By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
 - Dropping test database...
Success.

 - Removing privileges on test database...
Success.

Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.

All done!

La contraseña raíz generada caducará inmediatamente después del primer inicio de sesión raíz. El script de ayuda anterior nos ayuda a configurar una nueva contraseña de root de MySQL, deshabilitar el inicio de sesión remoto para root, eliminar la base de datos de prueba y los usuarios anónimos y también recargar las tablas de privilegios.

Ahora estamos listos para configurar la función de alta disponibilidad para Percona Server 8.0.

Replicación semisincrónica

La replicación semisíncrona se encuentra entre la replicación asíncrona y la completamente síncrona. El origen espera hasta que al menos una réplica haya recibido y registrado los eventos y luego confirma la transacción. El origen no espera a que todas las réplicas acusen recibo, y solo requiere un reconocimiento de las réplicas, no que los eventos se hayan ejecutado y confirmado por completo en el lado de la réplica. La replicación semisíncrona, por lo tanto, garantiza que si la fuente falla, todas las transacciones que ha confirmado se han transmitido al menos a una réplica.

Para obtener la mejor integridad de replicación, elija la replicación semisincrónica. Para configurarlo, en el primer nodo, db1 (192.168.0.61), agregue las siguientes líneas dentro de /etc/my.cnf (debe estar debajo de la sección [mysqld]):

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 61 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.61 # IP address of this host
read_only = OFF # Set ON on slave
super_read_only = OFF # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

# Semi-sync
plugin_load_add = rpl_semi_sync_master=semisync_master.so
plugin_load_add = rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_timeout = 1000
rpl_semi_sync_slave_enabled = ON

En el segundo nodo, db2 (192.168.0.62), agregue las siguientes líneas dentro de /etc/my.cnf (debe estar debajo de la sección [mysqld]):

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 62 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.62 # IP address of this host
read_only = ON # Set ON on slave
super_read_only = ON # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

# Semi-sync
plugin_load_add = rpl_semi_sync_master=semisync_master.so
plugin_load_add = rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_timeout = 1000
rpl_semi_sync_slave_enabled = ON

Entonces podemos proceder a configurar el enlace de replicación como se describe en "Configuración del enlace de replicación" más abajo.

Replicación asíncrona

Para la replicación asincrónica, simplemente elimine todas las opciones relacionadas con la replicación semisincrónica y deberíamos estar bien. En el primer nodo, db1 (192.168.0.61), agregue las siguientes líneas dentro de /etc/my.cnf (debe estar debajo de la sección [mysqld]):

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 61 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.61 # IP address of this host
read_only = OFF # Set ON on slave
super_read_only = OFF # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

En el segundo nodo, db2 (192.168.0.62), agregue las siguientes líneas dentro de /etc/my.cnf (debe estar debajo de la sección [mysqld]):

# Compatibility
default-authentication-plugin = mysql_native_password

# Replication
server_id = 62 # must be distinct on all nodes in the cluster
binlog_format = ROW
log_bin = binlog
log_slave_updates = 1
gtid_mode = ON
enforce_gtid_consistency = 1
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
report_host = 192.168.0.62 # IP address of this host
read_only = ON # Set ON on slave
super_read_only = ON # Set ON on slave

# Replication safety
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

Entonces podemos proceder a configurar el enlace de replicación como se describe en "Configuración del enlace de replicación" a continuación.

Configuración del enlace de replicación

En el maestro (db1), cree un usuario esclavo y permita que el usuario se conecte desde todos los hosts de esta red (usando % comodín):

mysql> CREATE USER 'slave'@'192.168.0.%' IDENTIFIED WITH mysql_native_password BY '[email protected]&9';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'192.168.0.%';

En el esclavo (db2), restablezca los registros binarios, configure las credenciales de replicación e inicie el proceso de replicación:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.61', MASTER_USER = 'slave', MASTER_PASSWORD = '[email protected]&9', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Verifique el estado de la replicación:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.61
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000008
          Read_Master_Log_Pos: 912
               Relay_Log_File: db2-relay-bin.000007
                Relay_Log_Pos: 1081
        Relay_Master_Log_File: binlog.000008
             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: 912
              Relay_Log_Space: 1500
              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: 66
                  Master_UUID: f60cf793-1feb-11eb-af72-5254008afee6
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: f60cf793-1feb-11eb-af72-5254008afee6:5-7
            Executed_Gtid_Set: f60cf793-1feb-11eb-af72-5254008afee6:1-7
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:

Preste atención al siguiente estado importante para determinar si la replicación está configurada correctamente y el esclavo se ha puesto al día con el maestro:

  • Slave_IO_Running:Sí
  • Slave_SQL_Running:Sí
  • Seconds_Behind_Master:0

Si la replicación semisíncrona está habilitada, debería obtener el siguiente resultado en el maestro:

mysql> SHOW STATUS LIKE '%semi%status';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | ON    |
| Rpl_semi_sync_slave_status  | OFF   |
+-----------------------------+-------+

Mientras está en el esclavo, el estado es el siguiente:

mysql> SHOW STATUS LIKE '%semi%status';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | OFF   |
| Rpl_semi_sync_slave_status  | ON    |
+-----------------------------+-------+

Para la replicación asincrónica, la consulta anterior no devolverá nada (conjunto vacío), porque los complementos de replicación semisincrónica no están habilitados. En un conjunto de replicación, es posible tener una combinación de hosts esclavos replicando con replicación asincrónica y semisíncrona.

Implementación de Percona Server para MySQL usando ClusterControl

Es prácticamente fácil implementar una replicación de Percona Server maestro-esclavo con ClusterControl y, de manera predeterminada, ClusterControl configurará la implementación de la replicación con una replicación asíncrona. Simplemente prepare los nodos que desea implementar y, en este ejemplo, implementaremos un servidor Percona de tres nodos para MySQL 8.0 con replicación maestro-esclavo. Con ClusterControl entra en escena, debemos tener un nodo adicional para ClusterControl. Por lo tanto, nuestra configuración se ve así:

  • ClusterControl - cc (192.168.0.19)
  • Maestro - db1 (192.168.0.61)
  • Esclavo - db2 (192.168.0.62)
  • Esclavo - db3 (192.168.0.63)

En el servidor de ClusterControl, instale ClusterControl mediante el script de instalación. Como root, ejecute lo siguiente:

$ wget http://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc

Siga las instrucciones de instalación hasta que finalice. Luego, abra un navegador web y vaya a http://{ClusterControl_IP_address}/clustercontrol  y cree un usuario y una contraseña de administrador predeterminados. A continuación, debemos configurar SSH sin contraseña desde el servidor ClusterControl a todos los nodos de la base de datos. Como usuario raíz, primero debemos generar una clave SSH:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts

Luego, copie la clave pública SSH creada en todos los nodos de la base de datos:

$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db1
$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db2
$ ssh-copy-id -i ~/.ssh/id_rsa [email protected] # db3

Ahora estamos listos para comenzar la implementación del clúster. Vaya a ClusterControl -> Implementar -> MySQL Replication y especifique los detalles requeridos a continuación:

Luego, haga clic en "Continuar" para pasar al siguiente paso donde configuramos la especificación de instalación de MySQL:

Elija "Percona" como proveedor y 8.0 como versión. Mantenga el resto como predeterminado e ingrese la contraseña de root de MySQL. Haga clic en "Continuar" para continuar con la configuración del host y la topología:

Especifique la dirección IP o el nombre de host de los hosts de la base de datos uno por uno y haga asegúrese de obtener los iconos de marca verde después de cada inserción. Esto indica que ClusterControl puede llegar a los hosts correspondientes a través de SSH sin contraseña con el usuario y la clave de SSH proporcionados, tal como se define en el paso 1. Haga clic en el botón "Implementar" para iniciar la implementación.

Luego, ClusterControl desencadena un trabajo de implementación en el que puede monitorear el progreso de la implementación yendo a ClusterControl -> Actividad -> Trabajos -> Crear clúster -> Detalles completos del trabajo, como se muestra en la siguiente captura de pantalla:

Una vez que se completa el proceso, debería ver que el clúster aparece en el panel :

Eso es todo. La implementación ya está completa.