Les sauvegardes sont une partie très importante de vos opérations de base de données, car votre entreprise doit être sécurisée en cas de catastrophe. Lorsque ce moment viendra (et il arrivera), votre objectif de point de récupération (RPO) et votre objectif de temps de récupération (RTO) doivent être prédéfinis, car il s'agit de la vitesse à laquelle vous pouvez récupérer de l'incident qui s'est produit.
La plupart des organisations varient leur approche des sauvegardes, en essayant d'avoir une combinaison de sauvegardes d'images de serveur (instantanés), de sauvegardes logiques et physiques. Ces sauvegardes sont ensuite stockées dans plusieurs emplacements, afin d'éviter tout sinistre local ou régional. Cela signifie également que les données peuvent être restaurées dans les plus brefs délais, évitant ainsi les temps d'arrêt majeurs qui peuvent avoir un impact sur les activités de votre entreprise.
L'hébergement de votre base de données avec un fournisseur de cloud, tel que Microsoft Azure (dont nous parlerons dans ce blog), n'est pas une exception, vous devez toujours préparer et définir votre politique de reprise après sinistre.
Comme d'autres offres de cloud public, Microsoft Azure (Azure) propose une approche des sauvegardes pratique, économique et conçue pour vous offrir des options de récupération. Les solutions de sauvegarde Microsoft Azure vous permettent de configurer et d'exploiter et sont facilement gérées à l'aide de leur sauvegarde Azure ou via le coffre-fort des services de restauration (si vous utilisez votre base de données à l'aide de machines virtuelles).
Si vous souhaitez une base de données gérée dans le cloud, Azure propose Azure Database pour MySQL. Cela ne doit être utilisé que si vous ne souhaitez pas exploiter et gérer vous-même la base de données MySQL. Ce service offre une solution de sauvegarde riche qui vous permet de créer une sauvegarde de votre instance de base de données, soit à partir d'une région locale, soit via un emplacement géo-redondant. Cela peut être utile pour la récupération de données. Vous pouvez même être en mesure de restaurer un nœud à partir d'une période spécifique, ce qui est utile pour réaliser une récupération ponctuelle. Cela peut être fait en un seul clic.
Dans ce blog, nous couvrirons tous ces scénarios de sauvegarde et de restauration à l'aide d'une base de données MySQL sur le cloud Microsoft Azure.
Exécuter des sauvegardes sur une machine virtuelle sur Azure
Malheureusement, Microsoft Azure n'offre pas de solution de type de sauvegarde spécifique à MySQL (par exemple, MySQL Enterprise Backup, Percona XtraBackup ou MariaDB's Mariabackup).
Lors de la création de votre machine virtuelle (à l'aide du portail), vous pouvez configurer un processus pour sauvegarder votre machine virtuelle à l'aide du coffre des services de restauration. Cela vous protégera de tout incident, désastre ou catastrophe et les données stockées sont cryptées par défaut. L'ajout de chiffrement est facultatif et, bien que recommandé par Azure, il a un prix. Vous pouvez consulter leur page de tarification Azure Backup pour plus de détails.
Pour créer et configurer une sauvegarde, accédez au panneau de gauche et cliquez sur Toutes les ressources → Calcul → Machine virtuelle. Définissez maintenant les paramètres requis dans les champs de texte. Une fois que vous êtes sur cette page, accédez à l'onglet Gestion et faites défiler vers le bas. Vous pourrez voir comment configurer ou créer la sauvegarde. Voir la capture d'écran ci-dessous :
Ensuite, configurez votre politique de sauvegarde en fonction de vos besoins en matière de sauvegarde. Cliquez simplement sur le lien Créer nouveau dans le champ de texte Politique de sauvegarde pour créer une nouvelle politique. Voir ci-dessous :
Vous pouvez configurer votre politique de sauvegarde avec une rétention hebdomadaire, mensuelle et annuelle .
Une fois que vous avez configuré votre sauvegarde, vous pouvez vérifier qu'une sauvegarde est activée sur cette machine virtuelle particulière que vous venez de créer. Voir la capture d'écran ci-dessous :
Restaurer et récupérer votre machine virtuelle sur Azure
La conception de votre récupération dans Azure dépend du type de stratégie et des exigences requises par votre application. Cela dépend également si le RTO et le RPO doivent être faibles ou invisibles pour l'utilisateur en cas d'incident ou pendant la maintenance. Vous pouvez configurer votre machine virtuelle avec un ensemble à haute disponibilité ou sur une zone de disponibilité différente pour obtenir un taux de récupération plus élevé.
Vous pouvez également configurer une reprise après sinistre pour votre machine virtuelle afin de répliquer vos machines virtuelles dans une autre région Azure pour les besoins de continuité des activités et de reprise après sinistre. Cependant, cela pourrait ne pas être une bonne idée pour votre organisation car cela a un coût élevé. S'il est en place, Azure vous offre une option pour restaurer ou créer une machine virtuelle à partir de la sauvegarde créée.
Par exemple, lors de la création de votre machine virtuelle, vous pouvez aller dans l'onglet Disques, puis aller dans Disques de données. Vous pouvez créer ou attacher un disque existant sur lequel vous pouvez attacher l'instantané dont vous disposez. Voir la capture d'écran ci-dessous pour laquelle vous pourrez choisir entre un instantané ou un blob de stockage :
Vous pouvez également restaurer à un moment précis, comme dans la capture d'écran ci-dessous :
La restauration dans Azure peut être effectuée de différentes manières, mais elle utilise la même ressources que vous avez déjà créées.
Par exemple, si vous avez créé un instantané ou une image disque stockée dans le blob Azure Storage, si vous créez une nouvelle machine virtuelle, vous pouvez utiliser cette ressource tant qu'elle est compatible et disponible. De plus, vous pourrez peut-être même effectuer une récupération de fichiers, en plus de restaurer une machine virtuelle, comme dans la capture d'écran ci-dessous :
Pendant la récupération de fichier, vous pourrez peut-être choisir un point de récupération spécifique , ainsi que télécharger un script pour parcourir et récupérer des fichiers. Ceci est très utile lorsque vous n'avez besoin que d'un fichier spécifique, mais pas de l'ensemble du système ou du volume de disque.
La restauration à partir d'une sauvegarde sur une machine virtuelle existante prend environ trois minutes. Cependant, la restauration à partir d'une sauvegarde pour générer une nouvelle machine virtuelle prend douze minutes. Toutefois, cela peut dépendre de la taille de votre machine virtuelle et de la bande passante réseau disponible dans Azure. La bonne chose est que, lors de la restauration, il vous fournira des détails sur ce qui a été terminé et sur le temps restant. Par exemple, voir la capture d'écran ci-dessous :
Sauvegardes pour la base de données Azure pour MySQL
Azure Database pour MySQL est un service de base de données entièrement géré par Microsoft Azure. Ce service offre un moyen très flexible et pratique de configurer vos capacités de sauvegarde et de restauration.
Lors de la création de votre instance de serveur MySQL, vous pouvez ensuite configurer la conservation des sauvegardes et créer vos options de redondance de sauvegarde ; soit localement redondant (région locale) soit géo-redondant (sur une région différente). Azure vous fournira le coût estimé qui vous serait facturé pour un mois. Voir un exemple de capture d'écran ci-dessous :
Gardez à l'esprit que les options de sauvegarde géo-redondantes ne sont disponibles qu'à usage général et les types de nœuds de calcul à mémoire optimisée. Il n'est pas disponible sur un nœud de calcul de base, mais vous pouvez avoir votre redondance dans la région locale (c'est-à-dire dans les zones de disponibilité disponibles).
Une fois que vous avez une configuration principale, il est facile de créer un réplica en accédant à Azure Database pour les serveurs MySQL → Sélectionnez votre instance MyQL → Réplication → et cliquez sur Ajouter un réplica. Votre réplique peut être utilisée comme source ou cible de restauration si nécessaire.
Gardez à l'esprit que dans Azure, lorsque vous arrêtez la réplication entre le maître et un réplica, cela sera définitif et irréversible car cela fait du réplica un serveur autonome. Une réplique créée à l'aide de Microsoft Azure est idéalement une instance gérée et vous pouvez arrêter et démarrer les threads de réplication comme vous le faites sur une réplication maître-esclave normale. Vous pouvez faire un redémarrage et c'est tout. Si vous avez créé la réplique manuellement, en restaurant à partir du maître ou d'une sauvegarde (par exemple, via une récupération ponctuelle), vous pourrez alors arrêter/démarrer les threads de réplication ou configurer un décalage esclave si nécessaire.
Restauration de votre base de données Azure pour MySQL à partir d'une sauvegarde
La restauration est très simple et rapide à l'aide du portail Azure. Vous pouvez simplement appuyer sur le bouton de restauration avec votre nœud d'instance MySQL et suivre simplement l'interface utilisateur comme indiqué dans la capture d'écran ci-dessous :
Ensuite, vous pouvez sélectionner une période de temps et créer/générer une nouvelle instance basé sur cette sauvegarde capturée :
Une fois que vous avez le nœud disponible, ce nœud ne sera pas une réplique de encore le maître. Vous devez le configurer manuellement en quelques étapes simples à l'aide de leurs procédures stockées disponibles :
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');où,
master_host :nom d'hôte du serveur maître
master_user :nom d'utilisateur pour le serveur maître
master_password :mot de passe pour le serveur maître
master_log_file :nom du fichier journal binaire de l'exécution de show master status
master_log_pos :position du journal binaire depuis l'exécution du show master status
master_ssl_ca :contexte du certificat CA. Si vous n'utilisez pas SSL, passez une chaîne vide.
Ensuite, le démarrage des threads MySQL est comme suit,
CALL mysql.az_replication_start;ou vous pouvez arrêter les threads de réplication comme suit,
CALL mysql.az_replication_stop;ou vous pouvez supprimer le maître en tant que,
CALL mysql.az_replication_remove_master;ou ignorer les erreurs de thread SQL comme,
CALL mysql.az_replication_skip_counter;Comme mentionné précédemment, lorsqu'un réplica est créé à l'aide de Microsoft Azure sous la fonctionnalité Ajouter un réplica sous une instance MySQL, ces procédures stockées spécifiques ne sont pas disponibles. Cependant, la procédure mysql.az_replication_restart sera disponible puisque vous n'êtes pas autorisé à arrêter ni démarrer les threads de réplication d'un réplica managé par Azure. Ainsi, l'exemple que nous avons ci-dessus a été restauré à partir d'un maître qui prend la copie complète du maître mais agit comme un nœud unique et nécessite une configuration manuelle pour être une réplique d'un maître existant.
De plus, lorsque vous avez une réplique manuelle que vous avez configurée, vous ne pourrez pas la voir sous Azure Database pour les serveurs MySQL → Sélectionnez votre instance MyQL → Réplication puisque vous avez créé ou configuré la réplication manuellement .
Solutions alternatives de sauvegarde dans le cloud et de restauration
Dans certains scénarios, vous souhaitez bénéficier d'un accès complet lors d'une sauvegarde complète de votre base de données MySQL dans le cloud. Pour ce faire, vous pouvez créer votre propre script ou utiliser des technologies open source. Avec ceux-ci, vous pouvez contrôler comment les données de votre base de données MySQL doivent être sauvegardées et précisément comment elles doivent être stockées.
Vous pouvez également tirer parti de l'interface de ligne de commande (CLI) Azure pour créer votre automatisation personnalisée. Par exemple, vous pouvez créer un instantané à l'aide de la commande suivante avec Azure CLI :
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupou créez votre réplique de serveur MySQL avec la commande suivante :
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupAlternativement, vous pouvez également tirer parti d'un outil d'entreprise qui propose des moyens d'effectuer votre sauvegarde avec des options de restauration. L'utilisation de technologies open source ou d'outils tiers nécessite des connaissances et des compétences pour exploiter et créer votre propre implémentation. Voici la liste que vous pouvez exploiter :
- ClusterControl - Bien que nous puissions être un peu biaisés, ClusterControl offre la possibilité de gérer les sauvegardes physiques et logiques de votre base de données MySQL à l'aide de technologies open source éprouvées (PXB, Mariabackup et mydumper). Il prend en charge les bases de données MySQL, Percona, MariaDB, Galera. Vous pouvez facilement créer notre politique de sauvegarde et stocker vos sauvegardes de base de données sur n'importe quel cloud (AWS, GCP ou Azure). Veuillez noter que la version gratuite de ClusterControl n'inclut pas les fonctionnalités de sauvegarde.
- Instantanés LVM - Vous pouvez utiliser LVM pour prendre un instantané de votre volume logique. Cela ne s'applique qu'à votre machine virtuelle, car elle nécessite un accès au stockage au niveau des blocs. L'utilisation de cet outil nécessite une mise en garde car il peut empêcher votre nœud de base de données de répondre pendant l'exécution de la sauvegarde.
- Percona XtraBackup (PXB) - Une technologie open source de Percona. Avec PXB, vous pouvez créer une copie de sauvegarde physique de votre base de données MySQL. Vous pouvez également effectuer une sauvegarde à chaud avec PXB pour le moteur de stockage InnoDB, mais il est recommandé de l'exécuter sur un serveur de base de données MySQL esclave ou non occupé. Cela ne s'applique qu'à votre instance de VM, car elle nécessite un accès binaire ou fichier au serveur de base de données lui-même.
- Mariabackup - Idem avec PXB, c'est une technologie open-source issue de PXB mais maintenue par MariaDB. Plus précisément, si votre base de données utilise MariaDB, vous devez utiliser Mariabackup afin d'éviter les problèmes d'incompatibilité avec les tablespaces.
- mon dumper/mon chargeur - Ces outils de sauvegarde créent des copies de sauvegarde logiques de votre base de données MySQL. Vous pouvez l'utiliser avec votre base de données Azure pour MySQL, bien que je n'aie pas encore testé le succès de votre procédure de sauvegarde et de restauration.
- mysqldump - c'est un outil de sauvegarde logique qui est très utile lorsque vous avez besoin de sauvegarder et de vider (ou de restaurer) une table ou une base de données spécifique vers une autre instance. Ceci est couramment utilisé par les DBA, mais vous devez faire attention à l'espace disque car les copies de sauvegarde logiques sont énormes par rapport aux sauvegardes physiques.
- Sauvegarde MySQL Enterprise - Il fournit des sauvegardes à chaud, en ligne et non bloquantes sur plusieurs plates-formes, notamment Linux, Windows, Mac et Solaris. Ce n'est pas un outil de sauvegarde gratuit, mais il offre de nombreuses fonctionnalités.
- rsync - C'est un outil de copie de fichiers rapide et extraordinairement polyvalent. Il peut copier localement, vers/depuis un autre hôte sur n'importe quel shell distant, ou vers/depuis un démon rsync distant. Il offre un grand nombre d'options qui contrôlent chaque aspect de son comportement et permettent une spécification très flexible de l'ensemble de fichiers à copier. Généralement dans les systèmes Linux, rsync est installé dans le cadre du package du système d'exploitation.
