Mysql
 sql >> Base de données >  >> RDS >> Mysql

Automatisez le déploiement de votre cluster MySQL ou Postgres à partir d'une sauvegarde

ClusterControl 1.7.1 introduit une nouvelle fonctionnalité appelée Créer un cluster à partir d'une sauvegarde, qui vous permet de déployer un nouveau cluster basé sur MySQL ou Postgres et de restaurer des données dessus à partir d'une sauvegarde. Cet article de blog explique comment cette nouvelle fonctionnalité fonctionne et comment ce type d'automatisation peut apporter des améliorations aux opérations de votre infrastructure.

Présentation :Créer un cluster à partir d'une sauvegarde

La gestion des sauvegardes est la fonctionnalité la plus appréciée par nos utilisateurs, et nous venons de la porter au niveau supérieur. Cette nouvelle fonctionnalité semble simple - ClusterControl 1.7.1 est capable de déployer un nouveau cluster à partir d'une sauvegarde existante. Cependant, plusieurs procédures et vérifications sont nécessaires pour déployer un cluster de niveau production directement à partir d'une sauvegarde. La restauration elle-même comporte ses propres défis, tels que :

  • Conséquences d'une restauration complète ou partielle
  • Sauvegarde de base et sa commande de sauvegardes incrémentielles (pour la sauvegarde incrémentielle)
  • Déchiffrement de sauvegarde (si chiffré)
  • Options de l'outil de restauration
  • Décompression (si compressé)
  • Diffusion de sauvegarde de la source vers le serveur de destination
  • Utilisation de l'espace disque pendant et après la restauration
  • Rapports sur l'avancement de la restauration

Combinez ce qui précède avec la complexité et la répétitivité des tâches de déploiement de cluster de bases de données, vous pouvez gagner du temps et réduire les risques lors de l'exécution de procédures sujettes aux erreurs. La partie la plus difficile du point de vue de l'utilisateur est de choisir la sauvegarde à partir de laquelle restaurer. ClusterControl s'occupera de tout le gros du travail dans les coulisses et signalera le résultat final une fois terminé.

Les étapes sont fondamentalement simples :

  1. Configurez SSH sans mot de passe du nœud ClusterControl vers les nouveaux serveurs.
  2. Choisissez une sauvegarde logique dans la liste des sauvegardes ou créez-en une sous Sauvegardes -> Créer une sauvegarde .
  3. Cliquez sur Restaurer -> Créer un cluster à partir de la sauvegarde et suivez l'assistant de déploiement.

Cette fonctionnalité est spécifiquement conçue pour MySQL Galera Cluster et PostgreSQL pour le moment. Voici ce que vous verriez dans l'interface utilisateur après avoir cliqué sur "Restaurer" sur une sauvegarde existante :

L'option du bas est ce que nous recherchons. Vient ensuite la boîte de dialogue récapitulative sur la sauvegarde choisie avant la configuration du déploiement :

Ensuite, le même assistant de déploiement de cluster de base de données pour le cluster respectif (MySQL Galera Cluster ou PostgreSQL) s'affichera pour configurer un nouveau cluster :

Notez que vous devez spécifier le même nom d'utilisateur et mot de passe root/admin de la base de données que celui que vous avez dans la sauvegarde. Sinon, le déploiement échouerait à mi-chemin lors du démarrage du premier nœud. En général, les procédures de restauration et de déploiement se dérouleront dans l'ordre suivant :

  1. Installez les logiciels et les dépendances nécessaires sur tous les nœuds de base de données.
  2. Démarrez le premier nœud.
  3. Diffusion et restauration de la sauvegarde sur le premier nœud (avec indicateur de redémarrage automatique).
  4. Configurez et ajoutez le reste des nœuds.

Un nouveau cluster de base de données sera répertorié sous le tableau de bord du cluster ClusterControl une fois la tâche terminée.

Que pouvez-vous en tirer ?

Il y a un certain nombre de choses dont vous pourriez bénéficier de cette fonctionnalité, comme expliqué dans les sections suivantes.

Testez votre ensemble de données dans diverses conditions

Parfois, vous vous demandez peut-être si la nouvelle version de la base de données fonctionnerait ou fonctionnerait pour votre charge de travail de base de données et la tester est le seul moyen de le savoir. C'est là que cette fonctionnalité est utile. Il vous permet d'effectuer des tests et des analyses comparatives sur de nombreuses variables impliquées qui affecteraient la stabilité ou les performances de la base de données, par exemple, le matériel sous-jacent, la version du logiciel, le fournisseur et les charges de travail de la base de données ou de l'application.

Pour un exemple simple, il y a une grande amélioration sur l'exécution DDL entre MySQL 5.6 et MySQL 5.7. L'opération DROP suivante sur une table de 10 millions de lignes le prouve :

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)
mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

Avoir un autre cluster avec lequel comparer nous permet en fait de mesurer l'amélioration et de justifier une migration.

Migration de base de données avec sauvegarde logique

Sauvegarde logique comme mysqldump et pg_dumpall est le moyen le plus sûr de mettre à niveau, rétrograder ou migrer vos données d'une version ou d'un fournisseur à un autre. Toutes les sauvegardes logiques peuvent être utilisées pour effectuer la migration de la base de données. Les étapes de mise à niveau de la base de données sont fondamentalement simples :

  1. Créer (ou programmer) une sauvegarde logique - mysqldump pour MySQL ou pg_dumpall pour PostgreSQL
  2. Configurez SSH sans mot de passe du nœud ClusterControl vers les nouveaux serveurs.
  3. Choisissez une sauvegarde logique créée dans la liste des sauvegardes.
  4. Cliquez sur Restaurer -> Créer un cluster à partir de la sauvegarde et suivez l'assistant de déploiement.
  5. Vérifiez la restauration des données sur le nouveau cluster.
  6. Faites pointer votre application vers le nouveau cluster.

Temps de récupération total du cluster plus rapide

Imaginez une panne catastrophique qui empêche votre cluster de fonctionner, comme par exemple une panne de stockage centralisé qui a affecté toutes les machines virtuelles qui s'y sont connectées, vous pourriez obtenir un cluster de remplacement presque immédiatement (à condition que les fichiers de sauvegarde soient stockés en dehors des nœuds de base de données défaillants , énonçant l'évidence). Cette fonctionnalité peut être automatisée via le client s9s, où vous pouvez déclencher une tâche via l'interface de ligne de commande, par exemple :

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

Une chose à noter lors de l'utilisation de cette fonctionnalité est d'utiliser le même nom d'utilisateur et mot de passe administrateur que ce qui est stocké dans la sauvegarde. De plus, le SSH sans mot de passe vers tous les nœuds de la base de données doit être configuré au préalable. Sinon, si vous préférez le configurer de manière interactive, utilisez simplement l'interface utilisateur Web.

Évoluez via la réplication asynchrone

Pour MySQL Galera Cluster, le cluster nouvellement créé a la possibilité d'être mis à l'échelle via la réplication asynchrone MySQL. Supposons que nous ayons déjà restauré un nouveau cluster au bureau sur la base de la dernière sauvegarde du cluster de production dans le centre de données, et que nous souhaitons que le cluster de bureau continue à se répliquer à partir du cluster de production, comme illustré dans le schéma suivant :

Vous pouvez ensuite configurer le lien de réplication asynchrone en utilisant la méthode suivante :

  1. Choisissez un nœud dans la production et activez la journalisation binaire (si désactivée). Allez dans Nœuds -> choisissez un nœud -> Actions de nœud -> Activer la journalisation binaire.

  2. Activez la journalisation binaire sur tous les nœuds pour le cluster Office. Cette action nécessite un redémarrage progressif qui sera effectué automatiquement si vous choisissez "Oui" dans la liste déroulante "Nœud de redémarrage automatique" :

    Sinon, vous pouvez effectuer cette opération sans temps d'arrêt en utilisant Gérer -> Mettre à niveau -> Redémarrage progressif (ou redémarrer manuellement un nœud à la fois).

  3. Créez un utilisateur de réplication sur le cluster de production en utilisant Gérer -> Schémas et utilisateurs -> Utilisateurs -> Créer un nouvel utilisateur :

  4. Ensuite, choisissez un nœud à répliquer sur le nœud maître du cluster de production et configurez le lien de réplication :

    mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

  5. Vérifiez si la réplication est en cours :

    mysql> SHOW SLAVE STATUS\G
    Assurez-vous que Slave_IO_Thread et Slave_SQL_thread signalent 'Oui'. Le cluster du bureau devrait commencer à rattraper le nœud maître s'il est à la traîne.

C'est tout pour le moment !