MariaDB comenzando con 10.1.26

los mariabackup El método SST se lanzó por primera vez en MariaDB 10.1.26 y MariaDB 10.2.10.

los mariabackup El método SST utiliza la utilidad Mariabackup para realizar SST. Es uno de los métodos que no bloquea el nodo donante. Mariabackup se bifurcó originalmente de Percona XtraBackup, y de manera similar, el mariabackup El método SST se bifurcó originalmente de la xtrabackup-v2 Método SST.

Tenga en cuenta que si utiliza el mariabackup Método SST, entonces también necesita tener socat instalado en el servidor. Esto es necesario para transmitir la copia de seguridad desde el nodo donante al nodo de unión. Ésta es una limitación heredada de la xtrabackup-v2 Método SST.

Elección de Mariabackup para SST

Usar el mariabackup Método SST, debe configurar el wsrep_sst_method=mariabackup tanto en el nodo donante como en el de unión. Se puede cambiar dinámicamente con SET GLOBAL en el nodo que pretende ser donante de SST. Por ejemplo:

SETGLOBAL wsrep_sst_method='mariabackup';

Se puede configurar en un grupo de opciones del servidor en un archivo de opciones antes de iniciar un nodo:

[mariadb]...
wsrep_sst_method = mariabackup

Autenticación y privilegios

Usar el mariabackup Método SST, Mariabackup debe poder autenticarse localmente en el nodo donante, de modo que pueda crear una copia de seguridad para transmitir al usuario. Puede decirle al nodo donante qué nombre de usuario y contraseña usar configurando el wsrep_sst_auth variable de sistema. Se puede cambiar dinámicamente con SET GLOBAL en el nodo que pretende ser donante de SST. Por ejemplo:

SETGLOBAL wsrep_sst_auth ='mariabackup:mypassword';

También se puede configurar en un grupo de opciones del servidor en un archivo de opciones antes de iniciar un nodo:

[mariadb]...
wsrep_sst_auth = mariabackup:mypassword

Algunos complementos de autenticación no requieren contraseña. Por ejemplo, el unix_socket y gssapi los complementos de autenticación no requieren contraseña. Si está utilizando una cuenta de usuario que no requiere una contraseña para iniciar sesión, puede dejar el componente de contraseña de wsrep_sst_auth vacío. Por ejemplo:

[mariadb]...
wsrep_sst_auth = mariabackup:

La cuenta de usuario que realiza la copia de seguridad del SST debe tener los mismos privilegios que Mariabackup, que son los RELOAD , PROCESS, LOCK TABLES y REPLICATION CLIENTprivilegios globales. Para estar seguro, debe asegurarse de que estos privilegios estén configurados en cada nodo de su clúster. Mariabackup se conecta localmente en el nodo donante para realizar la copia de seguridad, por lo que el siguiente usuario debería ser suficiente:

CREATEUSER'mariabackup'@'localhost' IDENTIFIED BY'mypassword';GRANT RELOAD, PROCESS,LOCKTABLES,REPLICATION CLIENT ON*.*TO'mariabackup'@'localhost';

Autenticación sin contraseña – Unix Socket

Es posible utilizar el unix_socket complemento de autenticación para la cuenta de usuario que realiza SST. Esto proporcionaría la ventaja de no tener que configurar una contraseña de texto sin formato en wsrep_sst_auth.

La cuenta de usuario debe tener el mismo nombre que la cuenta de usuario del sistema operativo que ejecuta el mysqld proceso. En muchos sistemas, esta es la cuenta de usuario configurada como user opción, y tiende a ser predeterminada mysql.

Por ejemplo, si el unix_socket El complemento de autenticación ya está instalado, entonces puede ejecutar lo siguiente para crear la cuenta de usuario:

CREATEUSER'mysql'@'localhost' IDENTIFIED VIA unix_socket;GRANT RELOAD, PROCESS,LOCKTABLES,REPLICATION CLIENT ON*.*TO'mysql'@'localhost';

Y luego configurar wsrep_sst_auth, puede configurar lo siguiente en un grupo de opciones de servidor en un archivo de opciones antes de iniciar un nodo:

[mariadb]...
wsrep_sst_auth = mysql:

Autenticación sin contraseña – GSSAPI

Es posible utilizar el gssapi complemento de autenticación para la cuenta de usuario que realiza SST. Esto proporcionaría la ventaja de no tener que configurar una contraseña de texto sin formato en wsrep_sst_auth.

Los siguientes pasos deben realizarse de antemano:

  • Necesitas un KDC en ejecución MIT Kerberos o Microsoft Active Directory.
  • Deberá crear un archivo de tabla de claves para el servidor MariaDB.
  • Deberá instalar el paquete que contiene el gssapi complemento de autenticación.
  • Deberá instalar el complemento en MariaDB, para que el gssapi El complemento de autenticación está disponible para su uso.
  • Deberá configurar el complemento.
  • Deberá crear una cuenta de usuario que se autentique con el gssapi complemento de autenticación, de modo que la cuenta de usuario se pueda utilizar para las SST. Esta cuenta de usuario deberá corresponder con una cuenta de usuario que exista en el KDC backend.

Por ejemplo, puede ejecutar lo siguiente para crear la cuenta de usuario en MariaDB:

CREATEUSER'mariabackup'@'localhost' IDENTIFIED VIA gssapi;GRANT RELOAD, PROCESS,LOCKTABLES,REPLICATION CLIENT ON*.*TO'mariabackup'@'localhost';

Y luego configurar wsrep_sst_auth, puede configurar lo siguiente en un grupo de opciones de servidor en un archivo de opciones antes de iniciar un nodo:

[mariadb]...
wsrep_sst_auth = mariabackup:

Dependencia de Socat

Durante el proceso de SST, el nodo donante utiliza socat para transmitir la copia de seguridad al nodo de unión. Luego, el nodo de unión prepara la copia de seguridad antes de restaurarla. La utilidad socat debe estar instalada tanto en el nodo donante como en el nodo de unión para que esto funcione. De lo contrario, el registro de errores de MariaDB contendrá un error como:

WSREP_SST: [ERROR] socat not found in path: /usr/sbin:/sbin:/usr//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin (20180122 14:55:32.993)

Instalación de Socat en RHEL / CentOS

En RHEL / CentOS, socat se puede instalar desde el Paquetes adicionales para Enterprise Linux (EPEL) repositorio.

TLS

Este método SST admite dos métodos TLS diferentes. El método específico se puede seleccionar configurando el encrypt opción en el [sst] sección del archivo de configuración de MariaDB. Las opciones son:

  • TLS con cifrado OpenSSL integrado en socat (encrypt=2)
  • TLS usando cifrado OpenSSL con certificados compatibles con Galera y keys (encrypt=3)

Tenga en cuenta que encrypt=1 se refiere a un método de cifrado TLS que ha quedado obsoleto y se ha eliminado. encrypt=4 se refiere a un método de cifrado TLS en xtrabackup-v2 que aún no ha sido portado a mariabackup. Ver MDEV-18050 sobre eso.

TLS con cifrado OpenSSL integrado en Socat

Para generar keys compatible con este método de cifrado, puede seguir estas direcciones.

Por ejemplo:

  • Primero, genere el keys y certificados: 
FILENAME=sst
openssl genrsa -out $FILENAME.key1024
openssl req -new -key $FILENAME.key-x509 -days 3653-out $FILENAME.crt
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
chmod 600 $FILENAME.key $FILENAME.pem
  • En algunos sistemas, es posible que también deba agregar dhparams al certificado: 
openssl dhparam -out dhparams.pem 2048
cat dhparams.pem >> sst.pem
  • Luego, copie el certificado y keys a todos los nodos del clúster.
  • Luego, configure lo siguiente en todos los nodos del clúster: 
[sst]
encrypt=2
tca=/etc/my.cnf.d/certificates/sst.crt
tcert=/etc/my.cnf.d/certificates/sst.pem

Pero reemplace las rutas con lo que sea relevante en su sistema.

Esto debería permitir que sus SST estén encriptados.

TLS con cifrado OpenSSL con certificados y claves compatibles con Galera

Para generar keys compatible con este método de cifrado, puede seguir estas direcciones.

Por ejemplo:

  • Primero, genere el keys y certificados: 
# CA
openssl genrsa 2048> ca-key.pem
openssl req -new -x509 -nodes -days 365000 
-key ca-key.pem -out ca-cert.pem
 
# server1
openssl req -newkey rsa:2048-days 365000 
-nodes -keyout server1-key.pem -out server1-req.pem
openssl rsa -in server1-key.pem -out server1-key.pem
openssl x509 -req -in server1-req.pem -days 365000 
-CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 
-out server1-cert.pem
  • Luego, copie el certificado y keys a todos los nodos del clúster.
  • Luego, configure lo siguiente en todos los nodos del clúster: 
[sst]
encrypt=3
tkey=/etc/my.cnf.d/certificates/server1-key.pem
tcert=/etc/my.cnf.d/certificates/server1-cert.pem

Pero reemplace las rutas con lo que sea relevante en su sistema.

Esto debería permitir que sus SST estén encriptados.

Registros

los mariabackup El método SST tiene su propio registro fuera del registro del servidor MariaDB.

Registro en registros de SST

MariaDB comenzando con 10.1.38

Empezando con MariaDB 10.1.38, MariaDB 10.2.22, y MariaDB 10.3.13, registrando para mariabackup Los SST funcionan de la siguiente manera.

De forma predeterminada, en el nodo donante, se registra en mariabackup.backup.log. Este archivo de registro se encuentra en el datadir.

De forma predeterminada, en el nodo de unión, se registra en mariabackup.prepare.log y mariabackup.move.log Estos archivos de registro también se encuentran en la datadir.

De forma predeterminada, antes de que se inicie una nueva SST, mariabackup Los archivos de registro de SST se comprimen y se mueven a /tmp/sst_log_archive. Este comportamiento se puede deshabilitar configurando sst-log-archive=0 en el [sst]grupo de opciones en un archivo de opciones. De manera similar, el directorio de archivo se puede cambiar configurando sst-log-archive-dir. Por ejemplo:

[sst]
sst-log-archive=1
sst-log-archive-dir=/var/log/mysql/sst/

Ver MDEV-17973 para más información.

MariaDB hasta 10.1.38

Antes de MariaDB 10.1.38, MariaDB 10.2.22, y MariaDB 10.3.13, registrando para mariabackup Los SST funcionan de la siguiente manera.

De forma predeterminada, en el nodo donante, se registra en innobackup.backup.log. Este archivo de registro se encuentra en el datadir.

De forma predeterminada, en el nodo de unión, se registra en innobackup.prepare.log y innobackup.move.log. Estos archivos de registro se encuentran en el .sst directorio, que es un directorio oculto dentro del datadir.

Estos archivos de registro se sobrescriben con cada SST subsiguiente, por lo que si falla un SST, es mejor copiarlos en algún lugar seguro antes de iniciar otro SST, para que los archivos de registro puedan analizarse.

Iniciar sesión en Syslog

Puede redirigir los registros de SST al syslog configurando lo siguiente en el [sst]grupo de opciones en un archivo de opciones:

[sst]
sst-syslog=1

Realización de SST con direcciones IPv6

Si está realizando Mariabackup SST con direcciones IPv6, entonces el socat la utilidad necesita pasar el pf=ip6 opción. Esto se puede hacer configurando el sockopt opción en el [sst]grupo de opciones en un archivo de opciones. Por ejemplo:

[sst]
sockopt=",pf=ip6"

Ver MDEV-18797 para más información.

SST manual con Mariabackup

En algunos casos, si las SST automáticas de Galera Cluster fallan repetidamente, entonces puede ser útil realizar una “SST manual”. Consulte la siguiente página para saber cómo hacerlo:

  • SST manual del nodo Galera Cluster con Mariabackup

Ver también

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.