Comment sauvegarder et restaurer ClusterControl

ClusterControl 1.7.1 a introduit une nouvelle fonctionnalité qui vous permet de sauvegarder votre serveur ClusterControl et de le restaurer (avec les métadonnées sur vos bases de données gérées) sur un autre serveur. Il sauvegarde l'application ClusterControl ainsi que toutes ses données de configuration. La migration de ClusterControl vers un nouveau serveur était auparavant pénible, mais plus maintenant.

Ce billet de blog vous présente cette nouvelle fonctionnalité.

Nous allons migrer ClusterControl d'un serveur à un autre, en préservant toutes les configurations et tous les paramètres.

Nous vous montrerons également comment transférer la gestion d'un cluster d'une instance ClusterControl à une autre.

Notre exemple d'architecture a commencé avec deux clusters de production (illustrés dans la capture d'écran ci-dessous) :

• ID de cluster 1 :3 nœuds Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 nœuds)
• ID de cluster 2 :1 maître MySQL + 2 esclaves MySQL + 1 ProxySQL (4 nœuds)

Présentation

ClusterControl CLI (s9s) est un outil d'interface de ligne de commande pour interagir, contrôler et gérer les clusters de bases de données à l'aide de la plate-forme ClusterControl. À partir de la version 1.4.1, le script d'installation installera automatiquement ce package sur le nœud ClusterControl.

Il y a essentiellement 4 nouvelles options introduites sous la commande "s9s backup", qui peuvent être utilisées pour atteindre notre objectif :

Cet article de blog couvrira des exemples de cas d'utilisation sur la façon d'utiliser ces options. Pour le moment, ils sont en phase de release candidate et uniquement disponibles via l'outil CLI ClusterControl.

Sauvegarder ClusterControl

Pour ce faire, le serveur ClusterControl doit être au moins sur v1.7.1 et versions ultérieures. Pour sauvegarder le contrôleur ClusterControl, exécutez simplement la commande suivante sur le nœud ClusterControl en tant qu'utilisateur root (ou avec sudo) :

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

Le --output-file doit être un nom de fichier ou un chemin physique (si vous voulez omettre l'indicateur --backup-directory), et le fichier ne doit pas exister auparavant. ClusterControl ne remplacera pas le fichier de sortie s'il existe déjà. En spécifiant --log, il attendra que le travail soit exécuté et les journaux du travail seront affichés dans le terminal. Les mêmes journaux sont accessibles via l'interface utilisateur de ClusterControl sous Activity -> Jobs -> Save Controller :

La tâche "Enregistrer le contrôleur" effectue essentiellement les procédures suivantes :

1. Récupérer la configuration du contrôleur et l'exporter vers JSON
2. Exporter la base de données CMON en tant que fichier de vidage MySQL
3. Pour chaque cluster de base de données :
   1. Récupérer la configuration du cluster et l'exporter vers JSON

Dans la sortie, vous remarquerez peut-être que le travail trouvé est N + 1 cluster, par exemple "Found 3 cluster(s) to save" même si nous n'avons que deux clusters de bases de données. Cela inclut l'ID de cluster 0, qui a une signification particulière dans ClusterControl en tant que cluster initialisé global. Cependant, il n'appartient pas au composant CmonCluster, qui est le cluster de base de données sous la gestion de ClusterControl.

Restauration de ClusterControl sur un nouveau serveur ClusterControl

Supposons que ClusterControl soit déjà installé sur le nouveau serveur, nous aimerions migrer les clusters de bases de données à gérer par le nouveau serveur. Le schéma suivant illustre notre exercice de migration :

Tout d'abord, transférez la sauvegarde de l'ancien serveur vers le nouveau serveur :

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

Avant d'effectuer la restauration, nous devons configurer SSH sans mot de passe sur tous les nœuds du nouveau serveur 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

Ensuite, sur le nouveau serveur, effectuez la restauration :

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

Ensuite, nous devons synchroniser le cluster dans l'interface utilisateur en allant dans Paramètres globaux -> Enregistrements de cluster -> Synchroniser le cluster . Ensuite, si vous revenez au tableau de bord principal de ClusterControl, vous verrez ce qui suit :

Ne pas paniquer. La nouvelle interface utilisateur ClusterControl n'est pas en mesure de récupérer les données de surveillance et de gestion en raison d'un jeton d'API RPC incorrect. Nous avons juste besoin de le mettre à jour en conséquence. Tout d'abord, récupérez la valeur rpc_key pour les clusters respectifs :

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

Dans l'interface utilisateur, cliquez sur le lien "ici" à la suite de la ligne "Modifier le jeton d'API RPC ici". La boîte de dialogue suivante s'affichera :

Collez la valeur rpc_key respective dans le champ de texte et cliquez sur Enregistrer. Répétez l'opération pour le groupe suivant. Attendez un instant et la liste des clusters devrait être actualisée automatiquement.

La dernière étape consiste à corriger les privilèges utilisateur MySQL cmon pour les nouvelles modifications d'adresse IP ClusterControl, 192.168.0.190. Connectez-vous à l'un des nœuds PXC et exécutez ce qui suit :

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

** Remplacez par un mot de passe cmon MySQL identique à celui de la valeur mysql_password dans /etc/cmon.cnf. Répétez la même étape sur le deuxième cluster, la réplication MySQL, mais ne l'exécutez qu'une seule fois sur le nœud maître.

Une fois le privilège configuré, vous devriez voir que la liste des clusters est en vert, similaire à l'ancienne :

Il convient de mentionner que par défaut, ClusterControl désactivera la récupération automatique du cluster (comme vous pouvez voir l'icône rouge à côté du mot "Cluster") pour éviter les conditions de concurrence avec une autre instance de ClusterControl. Il est recommandé d'activer cette fonctionnalité (en cliquant sur l'icône verte) une fois que l'ancien serveur a été mis hors service.

Notre migration est maintenant terminée. Toutes les configurations et tous les paramètres de l'ancien serveur sont conservés et transférés vers le nouveau serveur.

Migration de la gestion d'un cluster vers un autre serveur ClusterControl

Sauvegarde des informations de cluster

Il s'agit de sauvegarder les métadonnées et les informations du cluster afin que nous puissions les transférer vers un autre serveur ClusterControl, également appelé sauvegarde partielle. Sinon, nous devons effectuer "Importer un serveur/un cluster existant" pour les réimporter dans le nouveau ClusterControl, ce qui signifie que vous perdriez les données de surveillance de l'ancien serveur. Si vous avez des équilibreurs de charge ou des instances esclaves asynchrones, cela devra être importé une fois le cluster importé, un nœud à la fois. C'est donc un peu compliqué si vous disposez d'un ensemble complet de configuration de production.

L'exercice de migration du "gestionnaire" de cluster est illustré dans le schéma suivant :

Fondamentalement, nous voulons migrer notre réplication MySQL (cluster ID :2) pour qu'elle soit gérée par une autre instance ClusterControl. Nous allons utiliser les options --save-cluster-info et --restore-cluster-info pour celui-ci. L'option --save-cluster-info exportera les informations de cluster correspondantes pour les enregistrer ailleurs. Exportons notre cluster de réplication MySQL (ID de cluster : 2). Sur le serveur ClusterControl actuel, faites :

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

Vous verrez un tas de nouvelles lignes imprimées dans le terminal, indiquant que la tâche de sauvegarde est en cours (la sortie est également accessible via ClusterControl -> Activity -> Jobs ):

Si vous regardez attentivement les journaux de travail, vous remarquerez que le travail essayait d'exporter toutes les informations et métadonnées associées pour l'ID de cluster 2. La sortie est stockée sous forme de fichier compressé et située sous le chemin que nous avons spécifié sous using --backup -indicateur de répertoire. Si cet indicateur est ignoré, ClusterControl enregistrera la sortie dans le répertoire de sauvegarde par défaut qui est le répertoire personnel de l'utilisateur SSH, sous $HOME/backups.

Restauration des informations de cluster

Les étapes expliquées ici sont similaires aux étapes de restauration pour la sauvegarde complète de ClusterControl. Transférez la sauvegarde du serveur actuel vers l'autre serveur ClusterControl :

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

Avant d'effectuer la restauration, nous devons configurer SSH sans mot de passe sur tous les nœuds du nouveau serveur 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

Ensuite, sur le nouveau serveur, effectuez la restauration des informations du cluster pour notre réplication MySQL :

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

Vous pouvez vérifier la progression sous Activité -> Tâches -> Restaurer le cluster :

Si vous regardez attentivement les messages de travail, vous pouvez voir que ClusterControl réattribue automatiquement l'ID de cluster à 1 sur cette nouvelle instance (c'était l'ID de cluster 2 sur l'ancienne instance).

Synchronisez ensuite le cluster dans l'interface utilisateur en accédant à Paramètres globaux -> Enregistrements de cluster -> Synchroniser le cluster . Si vous revenez au tableau de bord principal de ClusterControl, vous verrez ce qui suit :

L'erreur signifie que la nouvelle interface utilisateur ClusterControl n'est pas en mesure de récupérer les données de surveillance et de gestion en raison d'un jeton d'API RPC incorrect. Nous avons juste besoin de le mettre à jour en conséquence. Tout d'abord, récupérez la valeur rpc_key pour notre cluster ID 1 :

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

Dans l'interface utilisateur, cliquez sur le lien "ici" à la suite de la ligne "Modifier le jeton d'API RPC ici". La boîte de dialogue suivante s'affichera :

Collez la valeur rpc_key respective dans le champ de texte et cliquez sur Enregistrer. Attendez un instant et la liste des clusters devrait être actualisée automatiquement.

La dernière étape consiste à corriger les privilèges utilisateur MySQL cmon pour les nouvelles modifications d'adresse IP ClusterControl, 192.168.0.190. Connectez-vous au nœud maître (192.168.0.31) et exécutez l'instruction suivante :

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

** Remplacez par un mot de passe cmon MySQL identique à celui de la valeur mysql_password dans /etc/cmon.cnf.

Vous pouvez également révoquer les anciens privilèges d'utilisateur (la révocation ne supprimera pas l'utilisateur) ou simplement supprimer l'ancien utilisateur :

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

Une fois le privilège mis en place, vous devriez voir que tout est vert :

À ce stade, notre architecture ressemble à ceci :

Notre exercice de migration est maintenant terminé.

Réflexions finales

Il est désormais possible d'effectuer une sauvegarde complète et partielle de vos instances ClusterControl et des clusters qu'elles gèrent, vous permettant de les déplacer librement entre les hôtes avec peu d'efforts. Les suggestions et les commentaires sont les bienvenus.