sql >> Base de Datos >  >> NoSQL >> MongoDB

Cómo hacer una copia de seguridad y restaurar ClusterControl

ClusterControl 1.7.1 introdujo una nueva función que le permite hacer una copia de seguridad de su servidor ClusterControl y restaurarlo (junto con los metadatos sobre sus bases de datos administradas) en otro servidor. Realiza una copia de seguridad de la aplicación ClusterControl, así como de todos sus datos de configuración. Migrar ClusterControl a un nuevo servidor solía ser una molestia, pero ya no.

Esta publicación de blog lo guía a través de esta nueva función.

Migraremos ClusterControl de un servidor a otro conservando todas las configuraciones y ajustes.

También le mostraremos cómo transferir la administración de un clúster de una instancia de ClusterControl a otra.

Nuestra arquitectura de ejemplo comenzó con dos clústeres de producción (que se muestran en la siguiente captura de pantalla):

  • ID de clúster 1:3 nodos Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 nodos)
  • ID de clúster 2:1 maestro MySQL + 2 esclavos MySQL + 1 ProxySQL (4 nodos)

Introducción

ClusterControl CLI (s9s) es una herramienta de interfaz de línea de comandos para interactuar, controlar y administrar clústeres de bases de datos utilizando la plataforma ClusterControl. A partir de la versión 1.4.1, la secuencia de comandos del instalador instalará automáticamente este paquete en el nodo ClusterControl.

Básicamente, hay 4 nuevas opciones introducidas bajo el comando "copia de seguridad s9s", que se pueden usar para lograr nuestro objetivo:

Bandera Descripción
--guardar-controlador Guarda el estado del controlador en un tarball.
--restaurar-controlador Restaura todo el controlador desde un tarball creado previamente (creado usando --save-controller
--save-cluster-info Guarda la información que tiene el controlador sobre un clúster.
--restore-cluster-info Restaura la información que tiene el controlador sobre un clúster a partir de un archivo de almacenamiento creado previamente.

Esta publicación de blog cubrirá casos de uso de ejemplo sobre cómo utilizar esas opciones. Por el momento, se encuentran en la etapa de versión candidata y solo están disponibles a través de la herramienta CLI de ClusterControl.

Copia de seguridad de ClusterControl

Para hacer esto, el servidor ClusterControl debe estar al menos en v1.7.1 y posterior. Para hacer una copia de seguridad del controlador ClusterControl, simplemente ejecute el siguiente comando en el nodo ClusterControl como usuario raíz (o con sudo):

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

El --output-file debe ser un nombre de archivo o una ruta física (si desea omitir el indicador --backup-directory), y el archivo no debe existir de antemano. ClusterControl no reemplazará el archivo de salida si ya existe. Al especificar --log, esperará hasta que se ejecute el trabajo y los registros del trabajo se mostrarán en la terminal. Se puede acceder a los mismos registros a través de la interfaz de usuario de ClusterControl en Actividad -> Trabajos -> Guardar controlador :

El trabajo 'Guardar controlador' básicamente realiza los siguientes procedimientos:

  1. Recuperar la configuración del controlador y exportarla a JSON
  2. Exportar base de datos CMON como archivo de volcado MySQL
  3. Para cada clúster de base de datos:
    1. Recuperar la configuración del clúster y exportarla a JSON

En el resultado, puede notar que el trabajo encontrado es N + 1 clúster, por ejemplo, "Se encontraron 3 clústeres para guardar", aunque solo tenemos dos clústeres de bases de datos. Esto incluye el ID de clúster 0, que tiene un significado especial en ClusterControl como el clúster inicializado global. Sin embargo, no pertenece al componente CmonCluster, que es el clúster de la base de datos bajo la administración de ClusterControl.

Restauración de ClusterControl en un nuevo servidor de ClusterControl

Supongamos que ClusterControl ya está instalado en el nuevo servidor, nos gustaría migrar los clústeres de la base de datos para que los administre el nuevo servidor. El siguiente diagrama ilustra nuestro ejercicio de migración:

En primer lugar, transfiera la copia de seguridad del servidor antiguo al servidor nuevo:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

Antes de realizar la restauración, debemos configurar SSH sin contraseña para todos los nodos desde el nuevo servidor ClusterControl:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

Luego, en el nuevo servidor, realice la restauración:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

Luego tenemos que sincronizar el clúster en la interfaz de usuario yendo a Configuración global -> Registros de clúster -> Sincronizar clúster . Luego, si regresa al tablero principal de ClusterControl, verá lo siguiente:

No entrar en pánico. La nueva interfaz de usuario de ClusterControl no puede recuperar los datos de supervisión y administración debido a un token de API de RPC incorrecto. Sólo tenemos que actualizarlo en consecuencia. Primero, recupere el valor de rpc_key para los clústeres respectivos:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

En la interfaz de usuario, haga clic en el enlace "aquí" al final de la línea "Cambiar el token de la API de RPC aquí". Aparecerá el siguiente cuadro de diálogo:

Pegue el valor rpc_key respectivo en el campo de texto y haga clic en Guardar. Repita para el siguiente grupo. Espere un momento y la lista de grupos debería actualizarse automáticamente.

El último paso es corregir los privilegios de usuario cmon de MySQL para los nuevos cambios de dirección IP de ClusterControl, 192.168.0.190. Inicie sesión en uno de los nodos PXC y ejecute lo siguiente:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Reemplace con la misma contraseña cmon MySQL que en el valor mysql_password dentro de /etc/cmon.cnf. Repita el mismo paso en el segundo clúster, la replicación de MySQL, pero solo ejecútelo una vez en el nodo principal.

Una vez que se configura el privilegio, debería ver que la lista de clústeres está en verde, similar a la anterior:

Vale la pena mencionar que, de manera predeterminada, ClusterControl deshabilitará la recuperación automática del clúster (como puede ver el ícono rojo junto a la palabra 'Cluster') para evitar la condición de carrera con otra instancia de ClusterControl. Se recomienda habilitar esta función (haciendo clic en el ícono verde) una vez que el servidor antiguo haya sido dado de baja.

Nuestra migración ya está completa. Todas las configuraciones y configuraciones del antiguo servidor se conservan y se transfieren al nuevo servidor.

Migración de la Gestión de un Cluster a Otro Servidor ClusterControl

Copia de seguridad de la información del clúster

Se trata de hacer una copia de seguridad de los metadatos y la información del clúster para que podamos transferirla a otro servidor de ClusterControl, también conocido como copia de seguridad parcial. De lo contrario, tenemos que realizar "Importar servidor/clúster existente" para volver a importarlos al nuevo ClusterControl, lo que significa que perderá los datos de monitoreo del servidor anterior. Si tiene balanceadores de carga o instancias esclavas asincrónicas, esto deberá importarse una vez que se importe el clúster, un nodo a la vez. Por lo tanto, es un poco complicado si tiene un conjunto completo de configuración de producción.

El ejercicio de migración del "administrador" del clúster se ilustra en el siguiente diagrama:

Básicamente, queremos migrar nuestra replicación de MySQL (ID de clúster:2) para que la administre otra instancia de ClusterControl. Vamos a utilizar las opciones --save-cluster-info y --restore-cluster-info para esta. La opción --save-cluster-info exportará la información del clúster correspondiente para guardarla en otro lugar. Exportemos nuestro clúster de replicación de MySQL (ID de clúster:2). En el servidor ClusterControl actual, haga:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Verá un montón de líneas nuevas impresas en la terminal, lo que indica que el trabajo de copia de seguridad se está ejecutando (también se puede acceder a la salida a través de ClusterControl -> Actividad -> Trabajos ):

Si observa detenidamente los registros del trabajo, notará que el trabajo intentaba exportar toda la información y los metadatos relacionados para el ID de clúster 2. El resultado se almacena como un archivo comprimido y se encuentra en la ruta que hemos especificado en usando --backup. -bandera de directorio. Si se ignora este indicador, ClusterControl guardará la salida en el directorio de copia de seguridad predeterminado, que es el directorio de inicio del usuario de SSH, en $HOME/backups.

Restauración de la información del clúster

Los pasos que se explican aquí son similares a los pasos de restauración para la copia de seguridad completa de ClusterControl. Transferir la copia de seguridad del servidor actual al otro servidor de ClusterControl:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Antes de realizar la restauración, debemos configurar SSH sin contraseña para todos los nodos desde el nuevo servidor ClusterControl:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Luego, en el nuevo servidor, realice la restauración de la información del clúster para nuestra replicación de MySQL:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Puede verificar el progreso en Actividad -> Trabajos -> Restaurar clúster :

Si observa detenidamente los mensajes de trabajo, puede ver que ClusterControl reasigna automáticamente el ID de clúster a 1 en esta nueva instancia (era el ID de clúster 2 en la instancia anterior).

Luego, sincronice el clúster en la interfaz de usuario yendo a Configuración global -> Registros de clúster -> Sincronizar clúster . Si vuelve al panel principal de ClusterControl, verá lo siguiente:

El error significa que la nueva interfaz de usuario de ClusterControl no puede recuperar los datos de supervisión y administración debido a un token de API de RPC incorrecto. Sólo tenemos que actualizarlo en consecuencia. En primer lugar, recupere el valor de rpc_key para nuestro ID de clúster 1:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

En la interfaz de usuario, haga clic en el enlace "aquí" al final de la línea "Cambiar el token de la API de RPC aquí". Aparecerá el siguiente cuadro de diálogo:

Pegue el valor rpc_key respectivo en el campo de texto y haga clic en Guardar. Espere un momento y la lista de grupos debería actualizarse automáticamente.

El último paso es corregir los privilegios de usuario cmon de MySQL para los nuevos cambios de dirección IP de ClusterControl, 192.168.0.190. Inicie sesión en el nodo maestro (192.168.0.31) y ejecute la siguiente instrucción:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Reemplace con la misma contraseña cmon MySQL que en el valor mysql_password dentro de /etc/cmon.cnf.

También puede revocar los privilegios del usuario anterior (la revocación no eliminará al usuario) o simplemente eliminar al usuario anterior:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Una vez que se configura el privilegio, debería ver que todo está en verde:

En este punto, nuestra arquitectura se parece a esto:

Nuestro ejercicio de migración ya está completo.

Reflexiones finales

Ahora es posible realizar copias de seguridad completas y parciales de sus instancias de ClusterControl y los clústeres que administran, lo que le permite moverlos libremente entre hosts con poco esfuerzo. Se aceptan sugerencias y comentarios.