Vue d’ensemble de la continuité d’activité avec le serveur flexible Azure Database pour MySQL

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur flexible

Azure Database pour MySQL serveur flexible permet des fonctionnalités de continuité d’activité qui protègent vos bases de données en cas de panne planifiée et non planifiée. Des fonctionnalités, telles que les sauvegardes automatisées et la haute disponibilité offrent plusieurs niveaux de protection contre les pannes, avec différents temps de récupération et risques de perte de données. Lorsque vous concevez des applications avec l’idée de les protéger contre les défaillances, vous devez tenir compte de l’objectif de délai de récupération (RTO) et de l’objectif de point de récupération (RPO) pour chaque application. L’objectif de délai de récupération est la tolérance aux temps d’arrêt, tandis que l’objectif de point de récupération est la tolérance à la perte de données après une disruption du service de base de données.

Le tableau suivant illustre les fonctionnalités qui Azure Database pour MySQL offres de serveur flexibles.

Fonctionnalité Description Restrictions
Sauvegarde et récupération Le service effectue automatiquement des sauvegardes quotidiennes de vos fichiers de base de données et sauvegarde en permanence les journaux des transactions. Les sauvegardes peuvent être conservées sur une période comprise entre 1 et 35 jours. Vous pouvez restaurer votre serveur de base de données à n’importe quel point dans le temps dans votre période de rétention de sauvegarde. Le temps de récupération dépend de la taille des données à restaurer + de l’heure d’exécution de la récupération des journaux. Pour plus d’informations, consultez Concepts – Sauvegarde et restauration. Les données de sauvegarde sont conservées dans la région
Sauvegarde localement redondante Les sauvegardes du service sont stockées de façon automatique et sécurisée dans un stockage localement redondant, au sein d’une région et dans la même zone de disponibilité. Les sauvegardes localement redondantes répliquent les fichiers de données de la sauvegarde serveur trois fois dans un même endroit physique au sein de la région primaire. Le stockage des sauvegardes localement redondantes offre une durabilité des objets d’au moins 99,999999999 % (11 « neuf ») sur une année donnée. Pour plus d’informations, consultez Concepts – Sauvegarde et restauration. Applicable dans toutes les régions
Sauvegarde géoredondante Les sauvegardes du service peuvent être configurées comme géoredondantes au moment de la création. L’activation de la géoredondance permet de répliquer les fichiers de données de sauvegarde du serveur dans la région principale jumelée pour fournir une résilience régionale. Le stockage des sauvegardes géoredondantes offre une durabilité des objets d’au moins 99,99999999999999 % (16 « neuf ») sur une année donnée. Pour plus d’informations, consultez Concepts – Sauvegarde et restauration. Disponible dans toutes les régions jumelées Azure
Haute disponibilité redondante interzone Le service peut être déployé en mode haute disponibilité, ce qui a pour effet de déployer le serveur principal et le serveur de secours dans deux zones de disponibilité différentes au sein d’une même région. La haute disponibilité redondante interzone protège contre les défaillances au niveau de la zone et permet également de réduire les temps d’arrêt de l’application pendant les événements de temps d’arrêt planifiés et non planifiés. Les données du serveur principal sont répliquées de façon synchrone sur le réplica de secours. Lors d’un événement de temps d’arrêt, le serveur de base de données est automatiquement basculé vers le réplica de secours. Pour plus d’informations, consultez Concepts – Haute disponibilité. Pris en charge dans les niveaux de calcul Usage général et Critique pour l'entreprise. Disponible uniquement dans les régions où plusieurs zones sont disponibles.
Partages de fichiers Premium Les fichiers de base de données sont stockés dans des partages de fichiers Azure Premium très robustes et fiables qui assurent la redondance des données au moyen de trois copies du réplica, stockées dans une zone de disponibilité à l’aide de fonctionnalités automatiques de récupération de données. Pour plus d’informations, consultez les Partages de fichiers Premium. Données stockées dans une zone de disponibilité

Réduction des temps d’arrêt planifiés

Voici quelques scénarios de maintenance planifiée qui subissent un temps d’arrêt :

Scénario Processus
Mise à l’échelle du calcul (Utilisateur) Quand vous effectuez une opération de mise à l’échelle du calcul, un nouveau serveur flexible est provisionné en utilisant la configuration du calcul mis à l’échelle. Sur le serveur de base de données existant, les points de contrôle actifs sont autorisés à se produire, les connexions clientes sont purgées, toutes les transactions non validées sont annulées, puis le serveur est arrêté. Le stockage est ensuite attaché au nouveau serveur et la base de données est démarrée, ce qui effectue la récupération si nécessaire avant d’accepter les connexions clientes.
Déploiement de nouveaux logiciels (Azure) Le déploiement de nouvelles fonctionnalités ou les corrections de bogues se produisent automatiquement dans le cadre de la maintenance planifiée du service, et vous pouvez planifier le moment auquel ces activités se produisent. Pour plus d’informations, consultez la documentation et votre portail.
Mises à niveau de version mineure (Azure) Azure Database pour MySQL serveur flexible corrige automatiquement les serveurs de base de données vers la version mineure déterminée par Azure. Cela se produit dans le cadre de la maintenance planifiée du service. L’opération entraîne un bref temps d’arrêt de quelques secondes, et le serveur de base de données est automatiquement redémarré avec la nouvelle version mineure. Pour plus d’informations, consultez la documentation et votre portail.

Lorsque le serveur flexible est configuré avec la haute disponibilité redondante interzone, il effectue d’abord des opérations sur le serveur de secours et ensuite sur le serveur principal, sans basculement. Pour plus d’informations, consultez Concepts – Haute disponibilité.

Réduction des temps d’arrêt non planifiés

Des temps d’arrêt non planifiés peuvent se produire suite à des défaillances imprévues, telles qu’une panne matérielle sous-jacente, des problèmes réseau et des bogues logiciels. Si le serveur de base de données tombe en panne de façon inattendue et qu’il est configuré avec une haute disponibilité [HA], le réplica de secours est activé. Si ce n’est pas le cas, un nouveau serveur de base de données est automatiquement provisionné. Bien qu’il ne soit pas possible d’éviter un temps d’arrêt non planifié, le serveur flexible réduit ce temps d’arrêt en effectuant automatiquement des opérations de récupération au niveau du serveur de base de données et des couches de stockage, sans intervention humaine.

Temps d’arrêt non planifié : scénarios d’échec et récupération du service

Voici quelques scénarios d’échec non planifiés et le processus de récupération :

Scénario Processus de récupération [sans haute disponibilité] Processus de récupération [haute disponibilité]
Panne du serveur de base de données En cas d’arrêt du serveur de base de données en raison d’une erreur matérielle sous-jacente, les connexions actives sont abandonnées et toutes les transactions en cours interrompues. Azure tente de redémarrer le serveur de base de données. En cas de réussite, la récupération de la base de données est effectuée. Si le redémarrage échoue, le redémarrage du serveur de base de données est tenté sur un autre nœud physique.

Le temps de récupération (RTO) dépend de différents facteurs, notamment l’activité au moment de l’erreur, comme la transaction volumineuse et la quantité de récupération à effectuer pendant le processus de démarrage du serveur de base de données. Le RPO est égal à zéro, car aucune perte de données n’est attendue pour les transactions validées. Des applications utilisant les bases de données MySQL doivent être créées de manière à détecter et à retenter les connexions abandonnées et les transactions ayant échoué. Quand l’application effectue une nouvelle tentative, les connexions sont dirigées vers le serveur de base de données nouvellement créé.

Les autres options disponibles sont la restauration à partir d’une sauvegarde. Vous pouvez utiliser à la fois la restauration géographique ou à un instant dans le passé à partir de la région jumelée.
PITR : RTO : Varie, RPO=0sec
Restauration géographique : RTO : Variable, RPO <1 h.

Vous pouvez également utiliser le réplica en lecture comme solution de récupération d’urgence. Vous pouvez arrêter la réplication, ce qui rend le réplica en lecture-écriture (autonome, puis rediriger le trafic de l’application vers cette base de données). Le RTO dans la plupart des cas est de quelques minutes et RPO < 1 h. RTO et RPO peuvent être beaucoup plus élevés dans certains cas en fonction de différents facteurs, notamment la latence entre les sites, la quantité de données à transmettre, et surtout la charge de travail d’écriture de base de données principale.		 Si des erreurs de serveur de base de données ou non récupérables sont détectées, le serveur de base de données de secours est activé, ce qui réduit le temps d’arrêt. Pour plus d’informations, consultez la page concepts de haute disponibilité. Le RTO doit être compris entre 60 et 120 s, avec un RPO = 0.

Remarque : Les options du processus de récupération [non haute disponibilité] sont également applicables ici.
Échec de stockage Les applications ne détectent aucun impact des problèmes liés au stockage, tels qu’une défaillance de disque ou une corruption de bloc physique. Les données étant stockées dans trois copies, leur copie est servie par le stockage survivant. Les altérations de bloc sont corrigées automatiquement. En cas de perte d’une copie des données, une nouvelle est automatiquement créée.

Dans un scénario rare, qui serait le pire des scénarios, où toutes les copies sont endommagées, nous pouvons utiliser la restauration à partir de la restauration géographique (région jumelée). Le RPO durerait <1 h et le RTO varierait.

Vous pouvez également utiliser la solution de réplica en lecture comme solution de récupération d’urgence, comme indiqué ci-dessus.		 Pour ce scénario, les options sont les mêmes que pour le processus de récupération [sans haute disponibilité].
Erreurs logiques/de l’utilisateur La récupération d’erreurs de l’utilisateur, telles qu’une suppression accidentelle de tables ou une mise à jour incorrecte de données, implique l’exécution d’une récupération jusqu’à une date et heure (PITR), en restaurant et récupérant les données jusqu’au moment où l’erreur s’est produite.

Vous pouvez récupérer une ressource de serveur flexible supprimée dans un délai de cinq jours à compter de la suppression du serveur. Pour obtenir un guide détaillé sur la restauration d’un serveur supprimé, [consultez les étapes documentées] (../flexible-server/how-to-restore-dropped-server.md). Pour protéger les ressources serveur après le déploiement contre la suppression accidentelle ou les modifications inattendues, les administrateurs peuvent utiliser des verrous de gestion.		 Ces erreurs d’utilisateur ne sont pas protégées avec une haute disponibilité, car toutes les opérations utilisateur sont également répliquées en mode veille. Pour ce scénario, les options sont les mêmes que pour le processus de récupération [sans haute disponibilité]
Défaillance de zone de disponibilité Bien qu’il s’agisse d’un événement rare, si vous souhaitez effectuer une récupération après une défaillance au niveau de la zone, vous pouvez effectuer une restauration géographique à partir de/vers une région jumelée. Le RPO durerait <1 h et le RTO varierait.

Vous pouvez également utiliser la solution de réplica en lecture comme solution de récupération d’urgence en créant un réplica dans une autre zone de disponibilité. RTO\RPO est semblable à ce qui est décrit ci-dessus.		 Si vous avez activé la haute disponibilité redondante interzone, le serveur flexible effectue un basculement automatique vers le site de secours. Pour plus d’informations, consultez la page Concepts de haute disponibilité. Le RTO doit être compris entre 60 et 120 s, avec un RPO = 0.

Les autres options disponibles sont la restauration à partir d’une sauvegarde. Vous pouvez utiliser à la fois la restauration géographique ou à un instant dans le passé à partir de la région jumelée.
PITR : RTO : Varie, RPO=0 s
Géorestauration : RTO : Varie, RPO <1 h

Remarque :si vous avez activé la haute disponibilité dans la même zone, les options sont les mêmes que pour le processus de récupération [non haute disponibilité].
Panne de région Bien qu’il s’agisse d’un événement rare, si vous souhaitez récupérer après une défaillance au niveau de la région, vous pouvez effectuer une récupération de base de données en créant un serveur à l’aide de la dernière sauvegarde géoredondante disponible dans le même abonnement pour accéder aux données les plus récentes. Un nouveau serveur flexible est déployé dans la région sélectionnée. Le temps que prend la restauration dépend de la sauvegarde précédente et du nombre des journaux des transactions à récupérer. Dans la plupart des cas, le RPO est de <1 h et le RTO peut varier. Pour ce scénario, les options sont les mêmes que pour le processus de récupération [sans haute disponibilité].

Limitations et exigences

Résidence des données dans une région

Par défaut, Azure Database pour MySQL serveur flexible ne déplace pas ou ne stocke pas les données client hors de la région dans laquelle il est déployé. Toutefois, les clients peuvent éventuellement choisir d’activer des sauvegardes géoredondantes ou de configurer la réplication interrégion pour stocker des données dans une autre région.

Étapes suivantes