Vue d’ensemble de la continuité d’activité avec Azure Database for MariaDB
Important
Azure Database for MariaDB est en voie de mise hors service. Nous vous recommandons vivement de migrer vers Azure Database pour MySQL. Pour plus d’informations sur la migration vers Azure Database pour MySQL, consultez Qu’est-ce qui se passe dans Azure Database for MariaDB ?.
Cet article décrit les fonctionnalités d’Azure Database for MariaDB en matière de continuité d’activité et de reprise d’activité après sinistre. Découvrez les options de reprise à la suite d’événements d’interruption susceptibles d’entraîner une perte de données ou une indisponibilité de votre base de données et de votre application. Découvrez ce qu’il faut faire lorsqu’une erreur utilisateur ou une erreur d’application affecte l’intégrité des données, qu’une région Azure a une panne ou que votre application a besoin de maintenance.
Fonctionnalités de continuité d’activité
À mesure que vous développez votre plan de continuité d’activité, vous devez comprendre vos éléments suivants :
- Objectif de temps de récupération (RTO) : délai maximal acceptable avant que l’application ne se rétablit complètement après un événement de perturbation.
- Objectif de point de récupération (RPO) : quantité maximale de mises à jour de données récentes (intervalle de temps) que l’application peut tolérer de perdre lorsqu’elle récupère après un événement perturbant.
Azure Database for MariaDB fournit des fonctionnalités de continuité d’activité et de récupération d’urgence qui incluent des sauvegardes géoredondantes avec la possibilité de lancer la géorestauration et de déployer des réplicas en lecture dans une autre région. Chacune de ces fonctionnalités présente des caractéristiques spécifiques concernant le temps de récupération et le risque de perte de données.
Avec la géorestauration, Azure Database for MariaDB crée un serveur à l’aide des données de sauvegarde répliquées à partir d’une autre région. Le temps global de restauration et de récupération dépend de la taille de la base de données et de la quantité de données de journal à récupérer. La durée totale d’établissement du serveur varie entre quelques minutes et quelques heures.
Avec les réplicas en lecture, les journaux des transactions de la base de données primaire sont transmis en continu de manière asynchrone vers un réplica. S’il existe une panne de base de données principale en raison d’une panne au niveau de la zone ou d’une erreur au niveau de la région, le basculement vers le réplica fournit un RTO plus court et une perte de données réduite.
Remarque
Le décalage entre la base de données primaire et le réplica dépend de la latence entre les sites, de la quantité de données à transmettre et (plus important) de la charge de travail d’écriture du serveur principal. Les charges de travail d’écriture lourdes peuvent générer un décalage significatif.
En raison de la nature asynchrone de la réplication utilisée pour les réplicas en lecture, ne considérez pas les réplicas en lecture comme une solution de haute disponibilité. Les retards plus élevés peuvent signifier un RTO et un RPO plus élevés. Les réplicas en lecture peuvent agir comme une alternative à haute disponibilité uniquement pour les charges de travail où le décalage reste plus petit par le pic et les heures creuses. Dans le cas contraire, les réplicas en lecture sont destinés à une véritable échelle de lecture pour les charges de travail lourdes et pour les scénarios de récupération d’urgence.
Le tableau suivant compare le RTO et le RPO dans un scénario de charge de travail classique :
| Fonctionnalité | De base | Usage général | Mémoire optimisée |
|---|---|---|---|
| Restauration à un point dans le temps à partir de la sauvegarde | N’importe quel point de restauration dans la période de rétention RTO varie Le RPO est inférieur à 15 minutes |
N’importe quel point de restauration dans la période de rétention RTO varie Le RPO est inférieur à 15 minutes |
N’importe quel point de restauration dans la période de rétention RTO varie Le RPO est inférieur à 15 minutes |
| Géo-restauration à partir de sauvegardes répliquées géographiquement | Non pris en charge | RTO varie Le RPO est supérieur à 24 heures |
RTO varie Le RPO est supérieur à 24 heures |
| Réplicas en lecture | RTO est minutes Le RPO est inférieur à 5 minutes |
RTO est minutes Le RPO est inférieur à 5 minutes |
RTO est minutes Le RPO est inférieur à 5 minutes |
RTO et RPO peuvent être beaucoup plus élevés dans certains cas, selon des facteurs tels que la latence entre les sites, la quantité de données à transmettre et la charge de travail d’écriture de la base de données primaire.
Récupération d’un serveur après une erreur d’utilisateur ou d’application
Vous pouvez vous servir des sauvegardes du service pour récupérer un serveur à la suite de plusieurs événements d’interruption. Par exemple, un utilisateur peut supprimer accidentellement certaines données, supprimer par inadvertance une table importante ou même supprimer une base de données entière. Une application peut remplacer accidentellement de bonnes données avec des données incorrectes en raison d’un défaut d’application.
Vous pouvez procéder à une restauration à un point dans le temps afin de créer une copie de votre serveur à un point dans le temps valide connu. Ce point dans le temps doit se trouver dans la période de rétention de sauvegarde que vous avez configurée pour votre serveur. Une fois les données restaurées sur le nouveau serveur, vous pouvez remplacer le serveur d’origine par le serveur nouvellement restauré ou copier les données nécessaires du serveur restauré vers le serveur d’origine.
Important
Vous ne pouvez restaurer les serveurs supprimés que dans les cinq jours suivant la suppression. Après cinq jours, les sauvegardes sont supprimées. Vous pouvez accéder à la sauvegarde et restaurer la base de données uniquement à partir de l’abonnement Azure qui héberge le serveur. Pour restaurer un serveur supprimé, reportez-vous aux étapes documentées. À l’issue du déploiement, pour protéger les ressources du serveur d’une suppression accidentelle ou de changements inattendus, les administrateurs peuvent utiliser des verrous de gestion.
Récupération à partir d’une panne de centre de données régionale Azure
Bien qu’il soit rare, un centre de données Azure peut avoir une panne. Lorsqu’une panne se produit, elle provoque une interruption de l’activité qui peut durer quelques minutes, mais peut durer pendant des heures.
Une option consiste à attendre que votre serveur revienne en ligne lorsque la panne du centre de données est terminée. Lorsque le centre de données a une panne, vous ne savez pas combien de temps la panne peut durer. Cette option fonctionne donc uniquement pour les applications qui peuvent se permettre d’avoir le serveur hors connexion pendant un certain temps (par exemple, un environnement de développement).
La géorestauration
La fonctionnalité de géorestauration restaure le serveur à l’aide de sauvegardes géoredondantes. Les sauvegardes sont hébergées dans la région appairée de votre serveur. Ces sauvegardes sont accessibles même lorsque la région où votre serveur est hébergé est hors connexion. Vous pouvez effectuer une restauration à partir de ces sauvegardes vers n’importe quelle autre région, puis remettre votre serveur en ligne. En savoir plus sur la géorestauration dans l’article sur les concepts de sauvegarde et de restauration.
Important
La géorestauration est possible uniquement si vous avez approvisionné le serveur avec un stockage de sauvegarde géoredondant. Si vous souhaitez passer d’une sauvegarde localement redondante à des sauvegardes géoredondantes pour un serveur existant, vous devez générer une sauvegarde de votre serveur existant à l’aide de mysqldump. Ensuite, restaurez sur un serveur nouvellement créé configuré avec des sauvegardes géoredondantes.
Réplicas en lecture inter-régions
Vous pouvez utiliser des réplicas en lecture inter-régions pour améliorer votre planification de la continuité d’activité et de la reprise d’activité. Les réplicas en lecture sont mis à jour de façon asynchrone via la technologie de réplication de MySQL pour les journaux binaires. En savoir plus sur les réplicas en lecture, les régions disponibles et la façon de basculer dans l’article sur les concepts de lecture du réplica.
FAQ
Où Azure Database for MariaDB stocke-t-il les données client ?
Par défaut, Azure Database for MariaDB ne déplace pas ou ne stocke pas les données client hors de la région où elle est déployée. Toutefois, vous pouvez choisir d’activer des sauvegardes géoredondantes ou de créer des réplicas en lecture inter-régions pour stocker des données dans une autre région.
Étapes suivantes
- Apprenez-en davantage sur les sauvegardes automatisées dans Azure Database pour MariaDB.
- Découvrez comment restaurer à l’aide du Portail Azure ou d’Azure CLI.
- Apprenez-en davantage sur les réplicas en lecture dans Azure Database pour MariaDB.