MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Protégez vos données avec ClusterControl

Dans les quatre derniers articles de la série de blogs, nous avons couvert le déploiement du clustering/réplication (MySQL/Galera, MySQL Replication, MongoDB &PostgreSQL), la gestion et la surveillance de vos bases de données et clusters existants, la surveillance des performances et de la santé et dans le dernier article, comment rendre votre configuration hautement disponible via HAProxy et ProxySQL.

Maintenant que vos bases de données sont opérationnelles et hautement disponibles, comment vous assurez-vous d'avoir des sauvegardes de vos données ?

Vous pouvez utiliser des sauvegardes pour plusieurs choses :reprise après sinistre, pour fournir des données de production à tester par rapport au développement ou même pour provisionner un nœud esclave. Ce dernier cas est déjà couvert par ClusterControl. Lorsque vous ajoutez un nouveau nœud (réplique) à votre configuration de réplication, ClusterControl créera une sauvegarde/instantané du nœud maître et l'utilisera pour créer la réplique. Il peut également utiliser une sauvegarde existante pour organiser la réplique, au cas où vous voudriez éviter cette charge supplémentaire sur le maître. Une fois la sauvegarde extraite, préparée et la base de données opérationnelle, ClusterControl configurera automatiquement la réplication.

Création d'une sauvegarde instantanée

Essentiellement, la création d'une sauvegarde est la même pour Galera, la réplication MySQL, PostgreSQL et MongoDB. Vous pouvez trouver la section de sauvegarde sous ClusterControl> Sauvegarde et par défaut, vous verrez une liste des sauvegardes créées du cluster (le cas échéant). Sinon, vous verriez un espace réservé pour créer une sauvegarde :

À partir de là, vous pouvez cliquer sur le bouton "Créer une sauvegarde" pour effectuer une sauvegarde instantanée ou planifier une nouvelle sauvegarde :

Toutes les sauvegardes créées peuvent également être téléchargées sur le cloud en basculant "Télécharger la sauvegarde sur le cloud", à condition que vous fournissiez des informations d'identification cloud fonctionnelles. Par défaut, toutes les sauvegardes de plus de 31 jours seront supprimées (configurable via les paramètres de rétention de sauvegarde) ou vous pouvez choisir de les conserver pour toujours ou de définir une période personnalisée.

"Créer une sauvegarde" et "Planifier une sauvegarde" partagent des options similaires, à l'exception de la partie planification et des options de sauvegarde incrémentielle pour cette dernière. Par conséquent, nous allons examiner plus en détail la fonctionnalité Créer une sauvegarde (c'est-à-dire une sauvegarde instantanée).

Comme toutes ces différentes bases de données ont des outils de sauvegarde différents, il y a évidemment une différence dans les options que vous pouvez choisir. Par exemple, avec MySQL, vous avez le choix entre mysqldump et xtrabackup (complet et incrémentiel). Pour MongoDB, ClusterControl prend en charge mongodump et mongodb-consistent-backup (beta) tandis que PostgreSQL, pg_dump et pg_basebackup sont pris en charge. En cas de doute sur lequel choisir pour MySQL, consultez ce blog sur les différences et les cas d'utilisation de mysqldump et xtrabackup.

Sauvegarder MySQL et Galera

Comme mentionné dans le paragraphe précédent, vous pouvez effectuer des sauvegardes MySQL en utilisant mysqldump ou xtrabackup (complet ou incrémentiel). Dans l'assistant "Créer une sauvegarde", vous pouvez choisir sur quel hôte vous souhaitez exécuter la sauvegarde, l'emplacement où vous souhaitez stocker les fichiers de sauvegarde, ainsi que son répertoire et ses schémas spécifiques (xtrabackup) ou schémas et tables (mysqldump).

Si le nœud que vous sauvegardez reçoit du trafic (de production) et que vous craignez que les écritures supplémentaires sur le disque ne deviennent intrusives, il est conseillé d'envoyer les sauvegardes à l'hôte ClusterControl en choisissant l'option "Store on Controller". Cela entraînera la sauvegarde pour diffuser les fichiers sur le réseau vers l'hôte ClusterControl et vous devez vous assurer qu'il y a suffisamment d'espace disponible sur ce nœud et que le port de diffusion est ouvert sur l'hôte ClusterControl.

Il existe également plusieurs autres options si vous souhaitez utiliser la compression et le niveau de compression. Plus le niveau de compression est élevé, plus la taille de la sauvegarde sera petite. Cependant, il nécessite une utilisation plus importante du processeur pour le processus de compression et de décompression.

Si vous choisissiez xtrabackup comme méthode de sauvegarde, cela ouvrirait des options supplémentaires :désynchronisation, verrous de sauvegarde, compression et threads parallèles xtrabackup/gzip. L'option desync n'est applicable que pour désynchroniser un nœud d'un cluster Galera. Les verrous de sauvegarde utilisent un nouveau type de verrou MDL pour bloquer les mises à jour des tables non transactionnelles et des instructions DDL pour toutes les tables, ce qui est plus efficace pour la charge de travail spécifique à InnoDB. Si vous utilisez Galera Cluster, il est recommandé d'activer cette option.

Après avoir planifié une sauvegarde instantanée, vous pouvez suivre la progression de la tâche de sauvegarde dans Activité > Tâches :

Une fois terminé, vous devriez pouvoir voir une nouvelle entrée sous la liste de sauvegarde.

Sauvegarder PostgreSQL

Semblable aux sauvegardes instantanées de MySQL, vous pouvez exécuter une sauvegarde sur votre base de données Postgres. Avec les sauvegardes Postgres, deux méthodes de sauvegarde sont prises en charge - pg_dumpall ou pg_basebackup. Notez que ClusterControl effectuera toujours une sauvegarde complète quelle que soit la méthode de sauvegarde choisie.

Nous avons couvert cet aspect dans ces détails dans Devenir un administrateur de base de données PostgreSQL - Sauvegardes PostgreSQL logiques et physiques.

Sauvegarder MongoDB

Pour MongoDB, ClusterControl prend en charge les sauvegardes standard mongodump et mongodb-consistent-backup développées par Percona. Ce dernier est toujours en version bêta qui fournit des sauvegardes ponctuelles cohérentes avec le cluster de MongoDB adaptées aux configurations de cluster fragmenté. Comme le cluster MongoDB partitionné se compose de plusieurs jeux de répliques, d'un jeu de répliques de configuration et de serveurs de partitions, il est très difficile d'effectuer une sauvegarde cohérente en utilisant uniquement mongodump.

Notez que dans l'assistant, vous n'avez pas besoin de choisir un nœud de base de données à sauvegarder. ClusterControl sélectionnera automatiquement le réplica secondaire le plus sain comme nœud de sauvegarde. Sinon, le primaire sera sélectionné. Lorsque la sauvegarde est en cours d'exécution, le nœud de sauvegarde sélectionné sera verrouillé jusqu'à la fin du processus de sauvegarde.

Planification des sauvegardes

Maintenant que nous avons joué avec la création de sauvegardes instantanées, nous pouvons maintenant étendre cela en planifiant les sauvegardes.

La planification est très facile à faire :vous pouvez sélectionner les jours où la sauvegarde doit être effectuée et à quelle heure elle doit s'exécuter.

Pour xtrabackup, il existe une fonctionnalité supplémentaire :les sauvegardes incrémentielles. Une sauvegarde incrémentielle sauvegardera uniquement les données modifiées depuis la dernière sauvegarde. Bien sûr, les sauvegardes incrémentales sont inutiles s'il n'y avait pas de sauvegarde complète comme point de départ. Entre deux sauvegardes complètes, vous pouvez avoir autant de sauvegardes incrémentales que vous le souhaitez. Mais les restaurer prendra plus de temps.

Une fois planifiées, les tâches devraient devenir visibles sous l'onglet "Sauvegarde planifiée" et vous pouvez les modifier en cliquant sur le bouton "Modifier". Comme avec les sauvegardes instantanées, ces tâches planifieront la création d'une sauvegarde et vous pourrez suivre la progression via l'onglet Activité.

Liste de sauvegarde

Vous pouvez trouver la liste de sauvegarde sous ClusterControl> Sauvegarde et cela vous donnera un aperçu au niveau du cluster de toutes les sauvegardes effectuées. Cliquer sur chaque entrée développera la ligne et affichera plus d'informations sur la sauvegarde :

Chaque sauvegarde est accompagnée d'un journal de sauvegarde lorsque ClusterControl a exécuté la tâche, qui est disponible sous le bouton "Plus d'actions".

Sauvegarde hors site dans le cloud

Étant donné que nous avons maintenant beaucoup de sauvegardes stockées sur les hôtes de base de données ou sur l'hôte ClusterControl, nous voulons également nous assurer qu'elles ne se perdent pas en cas de panne totale de l'infrastructure. (par exemple DC en feu ou inondé) Par conséquent, ClusterControl vous permet de stocker ou de copier vos sauvegardes hors site sur le cloud. Les plateformes cloud prises en charge sont Amazon S3, Google Cloud Storage et Azure Cloud Storage.

Le processus de téléchargement se produit juste après la création de la sauvegarde (si vous activez "Télécharger la sauvegarde sur le cloud") ou vous pouvez cliquer manuellement sur le bouton de l'icône du cloud de la liste de sauvegarde :

Choisissez les informations d'identification cloud et spécifiez l'emplacement de sauvegarde en conséquence :

Restaurer et/ou vérifier la sauvegarde

Depuis l'interface de la liste de sauvegarde, vous pouvez directement restaurer une sauvegarde sur un hôte du cluster en cliquant sur le bouton "Restaurer" pour la sauvegarde particulière ou en cliquant sur le bouton "Restaurer la sauvegarde" :

Une fonctionnalité intéressante est qu'il est capable de restaurer un nœud ou un cluster en utilisant les sauvegardes complètes et incrémentielles car il gardera une trace de la dernière sauvegarde complète effectuée et démarrera la sauvegarde incrémentielle à partir de là. Ensuite, il regroupera une sauvegarde complète avec toutes les sauvegardes incrémentielles jusqu'à la prochaine sauvegarde complète. Cela vous permet de restaurer à partir de la sauvegarde complète et d'appliquer les sauvegardes incrémentielles par-dessus.

ClusterControl prend en charge la restauration sur un nœud de base de données existant ou la restauration et la vérification sur un nouvel hôte autonome :

Ces deux options sont assez similaires, sauf que celle de vérification a des options supplémentaires pour les nouvelles informations d'hôte. Si vous suivez l'assistant de restauration, vous devrez spécifier un nouvel hôte. Si "Installer le logiciel de base de données" est activé, ClusterControl supprimera toute installation MySQL existante sur l'hôte cible et réinstallera le logiciel de base de données avec la même version que le serveur MySQL existant.

Une fois la sauvegarde restaurée et vérifiée, vous recevrez une notification sur l'état de la restauration et le nœud sera automatiquement arrêté.

Récupération ponctuelle

Pour MySQL, xtrabackup et mysqldump peuvent être utilisés pour effectuer une récupération ponctuelle et également pour provisionner un nouvel esclave de réplication pour la réplication maître-esclave ou Galera Cluster. Une sauvegarde compatible mysqldump PITR contient un seul fichier de vidage, avec les informations GTID, le fichier binlog et la position. Ainsi, seul le nœud de base de données qui produit le journal binaire aura l'option "Compatible PITR" disponible :

Lorsque l'option compatible PITR est activée, les champs de la base de données et de la table sont grisés car ClusterControl effectuera toujours une sauvegarde complète de toutes les bases de données, événements, déclencheurs et routines du serveur MySQL cible.

Restaurer maintenant la sauvegarde. Si la sauvegarde est compatible avec PITR, une option sera présentée pour effectuer une récupération ponctuelle. Vous aurez deux options pour cela - "Basé sur le temps" et "Basé sur la position". Pour "Time Based", vous pouvez simplement passer le jour et l'heure. Pour "Basé sur la position", vous pouvez transmettre la position exacte à l'endroit où vous souhaitez restaurer. Il s'agit d'une méthode de restauration plus précise, même si vous devrez peut-être obtenir la position de binlog à l'aide de l'utilitaire mysqlbinlog. Vous trouverez plus de détails sur la récupération ponctuelle dans ce blog.

Cryptage de sauvegarde

De manière universelle, ClusterControl prend en charge le chiffrement de sauvegarde pour MySQL, MongoDB et PostgreSQL. Les sauvegardes sont chiffrées au repos à l'aide de l'algorithme AES-256 CBC. Une clé générée automatiquement sera stockée dans le fichier de configuration du cluster sous /etc/cmon.d/cmon_X.cnf (où X est l'ID du cluster) :

$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='

Si la destination de sauvegarde n'est pas locale, les fichiers de sauvegarde sont transférés au format crypté. Cette fonctionnalité complète la sauvegarde hors site sur le cloud, où nous n'avons pas un accès complet au système de stockage sous-jacent.

Réflexions finales

Nous vous avons montré comment sauvegarder vos données et comment les stocker en toute sécurité hors site. La récupération est toujours une chose différente. ClusterControl peut récupérer automatiquement vos bases de données à partir des sauvegardes effectuées dans le passé qui sont stockées sur site ou recopiées depuis le cloud.

Évidemment, il y a plus à sécuriser vos données, en particulier du côté de la sécurisation de vos connexions. Nous en parlerons dans le prochain article de blog !