Au cœur de ClusterControl se trouve son automatisation, tout comme la garantie que vos données sont sauvegardées en toute sécurité et prêtes à être restaurées en cas de problème. Disposer d'une stratégie de sauvegarde et d'un plan de reprise après sinistre efficaces est la clé du succès de toute application ou de tout environnement.
Dans notre dernière version, ClusterControl 1.5, nous avons introduit un certain nombre d'améliorations pour la sauvegarde des systèmes basés sur MySQL et MariaDB.
L'une des principales améliorations est la possibilité de sauvegarder de ClusterControl vers le fournisseur de cloud de votre choix. Les fournisseurs de cloud comme Google Cloud Services et Amazon S3 offrent chacun un stockage pratiquement illimité, réduisant ainsi les besoins en espace local. Cela vous permet de conserver vos fichiers de sauvegarde plus longtemps, aussi longtemps que vous le souhaitez et de ne pas vous soucier de l'espace disque local.
Explorons toutes les nouvelles fonctionnalités de sauvegarde passionnantes pour ClusterControl 1.5...
Refonte de l'assistant de sauvegarde/restauration
Tout d'abord, vous remarquerez que les assistants de sauvegarde et de restauration ont été repensés pour améliorer l'expérience utilisateur. Il va maintenant se charger en tant que menu latéral à droite de l'écran :
La liste de sauvegarde reçoit également une modification mineure où les détails de la sauvegarde sont affichés lorsque vous cliquez sur la sauvegarde particulière :
Vous pourrez voir l'emplacement de la sauvegarde et les bases de données qui se trouvent dans la sauvegarde. Il existe également des options pour restaurer la sauvegarde ou la télécharger dans le cloud.
Sauvegarde compatible PITR
ClusterControl effectue la sauvegarde mysqldump standard avec des vidages de schéma et de données séparés. Cela facilite la restauration de sauvegardes partielles. Cependant, il rompt la cohérence de la sauvegarde (le schéma et les données sont vidés dans deux sessions distinctes), il ne peut donc pas être utilisé pour provisionner un esclave ou une récupération ponctuelle.
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, comme indiqué dans la capture d'écran ci-dessous :
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 la sauvegarde de toutes les bases de données, événements, déclencheurs et routines du serveur MySQL cible.
Les lignes suivantes apparaîtront dans les ~50 premières lignes du fichier de vidage terminé :
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...Les informations peuvent être utilisées pour créer des esclaves à partir d'une sauvegarde ou effectuer une récupération ponctuelle avec des journaux binaires, où vous pouvez démarrer la récupération à partir de MASTER_LOG_FILE et MASTER_LOG_POS signalés dans le fichier de vidage à l'aide de l'utilitaire "mysqlbinlog". Notez que les journaux binaires ne sont pas sauvegardés par ClusterControl.
Construire des esclaves à partir d'une sauvegarde Une autre fonctionnalité est la possibilité de créer un esclave directement à partir d'une sauvegarde compatible PITR, au lieu de le faire à partir d'un maître choisi. C'est un énorme avantage car cela décharge le serveur maître. Cette option peut être utilisée avec MySQL Replication ou Galera Cluster. Une sauvegarde existante peut être utilisée pour reconstruire un esclave de réplication existant ou pour ajouter un nouvel esclave de réplication pendant la phase intermédiaire, comme illustré dans la capture d'écran suivante :
Une fois la mise en scène terminée, l'esclave se connectera au maître choisi et commencera à rattraper son retard. Auparavant, ClusterControl effectuait une sauvegarde en continu directement à partir du maître choisi à l'aide de Percona Xtrabackup. Cela peut avoir un impact sur les performances du maître lors de la mise à l'échelle d'un grand ensemble de données, même si l'opération n'est pas bloquante sur le maître. Avec la nouvelle option, si la sauvegarde est stockée sur ClusterControl, seuls ces hôtes (ClusterControl + l'esclave) seront occupés lors du staging des données sur l'esclave.
Sauvegarde dans le cloud
Les sauvegardes peuvent désormais être téléchargées automatiquement dans le cloud. Cela nécessite l'installation d'un module ClusterControl, appelé clustercontrol-cloud (Module d'intégration Cloud) et clustercontrol-clud (Cloud download/upload CLI) qui sont disponibles dans la v1.5 et les versions ultérieures. Les instructions de mise à niveau ont été incluses avec ces packages et elles sont fournies sans aucune configuration supplémentaire. Pour le moment, les plates-formes cloud prises en charge sont Amazon Web Services et Google Cloud Platform. Les identifiants cloud sont configurés sous ClusterControl -> Paramètres -> Intégrations -> Fournisseurs cloud.
Lors de la création ou de la planification d'une sauvegarde, vous devriez voir les options supplémentaires suivantes lorsque "Télécharger la sauvegarde sur le cloud" est activé :
La fonctionnalité permet un téléchargement unique ou de programmer des sauvegardes à télécharger après l'achèvement (Amazon S3 ou Google Cloud Storage). Vous pouvez ensuite télécharger et restaurer les sauvegardes selon vos besoins.
Compression personnalisée pour mysqldump
Cette fonctionnalité a en fait été introduite pour la première fois avec ClusterControl v1.4.2 après sa sortie. Nous avons ajouté un niveau de compression de sauvegarde basé sur gzip. Auparavant, ClusterControl utilisait la compression de sauvegarde par défaut (niveau 6) si la destination de la sauvegarde se trouvait sur le nœud du contrôleur. La compression la plus faible (niveau 1 - la plus rapide, moins de compression) a été utilisée si la destination de la sauvegarde se trouvait sur l'hôte de la base de données lui-même, afin de garantir un impact minimal sur la base de données lors de l'opération de compression.
Dans cette version, nous avons peaufiné l'aspect compression et vous pouvez désormais personnaliser le niveau de compression, quelle que soit la destination de la sauvegarde. Lors de la mise à niveau de votre instance ClusterControl, toutes les sauvegardes planifiées seront automatiquement converties pour utiliser le niveau 6, sauf si vous les modifiez explicitement dans la v1.5.
La compression des sauvegardes est vitale lorsque votre jeu de données est volumineux, combiné à une longue politique de conservation des sauvegardes, alors que l'espace de stockage est limité. Mysqldump, qui est basé sur du texte, peut bénéficier de la compression avec des économies allant jusqu'à 60 % de l'espace disque de la taille du fichier d'origine. À certaines occasions, le taux de compression le plus élevé est la meilleure option, même si cela se fait au prix d'une décompression plus longue lors de la restauration.
Fonctionnalité bonus :vérification automatique des sauvegardes
Comme le disent les anciens administrateurs système - Une sauvegarde n'est pas une sauvegarde si elle n'est pas restaurable. La vérification des sauvegardes est quelque chose qui est généralement négligé par beaucoup. Certains administrateurs système ont développé des routines internes pour cela, généralement plus manuelles qu'automatisées. L'automatisation est difficile, principalement en raison de la complexité de l'opération dans son ensemble - à partir du provisionnement de l'hôte, de l'installation et de la préparation de MySQL, du transfert des fichiers de sauvegarde, de la décompression, de l'opération de restauration, des procédures de vérification et enfin du nettoyage du système après le processus. Tous ces tracas font que les gens négligent un aspect si important d'une sauvegarde fiable. En général, un test de restauration de sauvegarde doit être effectué au moins une fois par mois, ou en cas de modifications importantes de la taille des données ou de la structure de la base de données. Trouvez un horaire qui vous convient et formalisez-le avec un événement planifié.
ClusterControl peut automatiser la vérification de la sauvegarde en effectuant la restauration sur un nouvel hôte, sans compromettre aucune des procédures de vérification mentionnées ci-dessus. Cela peut être fait après un certain délai ou juste après la fin de la sauvegarde. Il signalera l'état de la sauvegarde en fonction du code de sortie de l'opération de restauration, effectuera un arrêt automatique si la sauvegarde est vérifiée ou laissera simplement l'hôte restauré s'exécuter afin que vous effectuiez des vérifications manuelles supplémentaires sur les données.
Lors de la création ou de la planification d'une sauvegarde, vous disposerez d'options supplémentaires si "Vérifier la sauvegarde" est activé :
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. Sinon, si vous avez une configuration spécifique pour l'hôte restauré, vous pouvez ignorer cette option. Les autres options sont explicites.
Fonctionnalité bonus :n'oubliez pas PostgreSQL
En plus de toutes ces excellentes fonctionnalités pour MySQL et MariaDB, ClusterControl 1.5 fournit également à PostgreSQL une méthode de sauvegarde supplémentaire (pg_basebackup) qui peut être utilisée pour les sauvegardes binaires en ligne. Les sauvegardes effectuées avec pg_basebackup peuvent être utilisées ultérieurement pour une restauration ponctuelle et comme point de départ pour un envoi de journaux ou des serveurs de secours de réplication en continu.
C'est tout pour le moment. Essayez ClusterControl v1.5, jouez avec les nouvelles fonctionnalités et dites-nous ce que vous en pensez.
