Comparer les options de continuité d’activité et de reprise d’activité
Azure Database pour MySQL – Serveur flexible fournit des fonctionnalités de continuité d’activité pour protéger votre base de données en cas de pannes planifiées ou non. Pour traiter différents types de pannes, vous pouvez appliquer différents niveaux de protection contre les pannes avec différents délais de récupération ou risques de perte de données.
Exemples de temps d’arrêt
Nous vous présentons ci-dessous quelques exemples de scénarios pour les temps d’arrêt planifiés et non planifiés.
Scénarios de temps d’arrêt planifiés
Les deux scénarios de temps d’arrêt planifiés les plus courants sont la mise à l’échelle du calcul lancée par l’utilisateur et la maintenance planifiée effectuée par Azure.
Lorsque vous effectuez une opération de mise à l’échelle du calcul, Azure approvisionne un nouveau serveur flexible MySQL avec la configuration de calcul demandée. Le serveur existant permet aux points de contrôle actifs de terminer, vide les connexions existantes et annule les transactions non validées. Le serveur existant s’arrête ensuite. À ce stade, Azure attache le stockage du serveur existant au nouveau serveur et démarre la base de données. La base de données effectue ensuite toute récupération nécessaire avant de continuer à accepter les connexions clientes.
De nouvelles fonctionnalités et correctifs de bogues se produisent automatiquement dans le cadre de la maintenance planifiée du service. Les correctifs de mise à niveau de version mineure sont également appliqués pendant la maintenance planifiée, ce qui entraîne quelques secondes de temps d’arrêt. Vous pouvez planifier ces activités comme décrit dans la section suivante : « Temps d’arrêt planifié et fenêtres de maintenance ».
Temps d’arrêt non planifié
La base de données peut arrêter de fonctionner de manière inattendue pour plusieurs raisons, telles que :
- Défaillance matérielle de la base de données.
- Défaillance du lecteur de stockage.
- Erreurs d’application ou d’utilisateur (par exemple, suppression accidentelle de tables).
- Défaillance des zones de disponibilité et des régions.
Si la haute disponibilité n’est pas activée, Azure tente une récupération telle que la copie des données perdues, le redémarrage du serveur ou même le démarrage du serveur sur un autre nœud physique. L’activation de la haute disponibilité peut réduire ou même éliminer ces types de temps d’arrêt, comme indiqué dans la section suivante.
Haute disponibilité
Azure Database pour MySQL – Serveur flexible fournit une haute disponibilité avec basculement automatique, qui fournit une solution conçue pour ne jamais perdre les données validées et empêcher la base de données d’être un point de défaillance unique. Lorsque vous avez configuré la haute disponibilité, le serveur flexible MySQL approvisionne et gère automatiquement un réplica de secours.
Il existe deux types de haute disponibilité avec une tolérance de panne différente et des compromis de latence : redondant interzone et dans la même zone.
Haute disponibilité redondante interzone
La haute disponibilité redondante interzone fournit une redondance entre plusieurs zones de disponibilité, offrant le niveau de disponibilité le plus élevé avec la possibilité de récupérer même si une zone entière tombe en panne. L’utilisation d’une configuration haute disponibilité redondante interzone introduit une latence supplémentaire. Veillez donc à déterminer si cela est acceptable pour votre application. En outre, l’utilisation d’une configuration haute disponibilité redondante interzone nécessite également que les applications clientes de base de données soient redondantes interzone pour s’assurer que les opérations globales continuent.
Haute disponibilité dans la même zone
Dans une configuration haute disponibilité dans la même zone, les serveurs principaux et de secours résident dans la même zone de disponibilité, ce qui réduit la latence. Bien que la faible latence puisse être nécessaire dans certains cas d’usage, avec une configuration haute disponibilité dans la même zone, si la zone de disponibilité cesse de fonctionner, le temps d’arrêt résultant sera plus long en raison de la récupération du serveur flexible MySQL.
Contrairement à la haute disponibilité redondante interzone, la haute disponibilité dans la même zone est disponible dans toutes les régions qui prennent en charge Azure Database pour MySQL – Serveur flexible.
Sauvegarde et restauration
Les sauvegardes de serveur sont un composant crucial de toute stratégie de continuité d’activité. Azure Database pour MySQL – Serveur flexible crée automatiquement des sauvegardes stockées en toute sécurité dans un stockage localement redondant dans la région hébergeant la base de données. Vous pouvez utiliser ces sauvegardes pour restaurer la base de données à un point spécifique dans le temps, en cas de défaillance ou d’altération des données (par exemple, un bogue d’application ou une erreur de développement).
Il existe deux types de sauvegardes. Avec les sauvegardes automatisées, le serveur flexible MySQL prend des captures instantanées des fichiers de données de base de données ainsi que les journaux de transactions associés. Les sauvegardes de capture instantanée automatisées se produisent une fois par jour et les sauvegardes du journal des transactions toutes les cinq minutes. En cas d’échec d’une sauvegarde, le serveur réessaye toutes les 20 minutes jusqu’à ce que la sauvegarde réussisse.
Avec les sauvegardes à la demande, vous pouvez créer une sauvegarde de base de données à tout moment. Avec les deux types de sauvegardes, les fichiers de sauvegarde sont conservés pendant sept jours par défaut. Toutefois, en fonction des besoins de votre entreprise, vous pouvez configurer la valeur de la période de rétention de 1 à 35 jours.
Vous pouvez conserver des sauvegardes pendant 10 ans à l’aide de la fonctionnalité de conservation à long terme, actuellement en préversion publique. La solution de sauvegarde à long terme peut être utilisée séparément ou en plus des sauvegardes automatisées d’Azure Database pour MySQL. Les sauvegardes à long terme peuvent être effectuées selon une planification contrôlée par le client ou à la demande. Les sauvegardes sont stockées dans des comptes de stockage managé Sauvegarde Azure, dans des domaines de sécurité et d’erreur distincts.
Outre la sauvegarde de la base de données, vous pouvez exporter des fichiers de sauvegarde vers le Stockage Blob Azure, que vous pouvez ensuite utiliser pour les migrations, la récupération de données ou l’archivage. Les exportations à la demande sont actuellement en préversion publique et disponibles uniquement dans les régions de cloud public.
Pour stocker les fichiers de sauvegarde, vous pouvez sélectionner parmi plusieurs options de stockage :
Avec le stockage localement redondant (même centre de données, même zone), les fichiers de sauvegarde sont stockés dans le même centre de données que la base de données. Cette option fournit une durabilité de 99,999999999 % de durabilité pour les objets de sauvegarde sur une année. Par défaut, les serveurs sans haute disponibilité ou avec haute disponibilité dans la même zone utilisent un stockage localement redondant.
Avec le stockage de sauvegarde redondant interzone (zone différente, même région), les fichiers de sauvegarde sont stockés dans la zone de disponibilité du serveur et répliqués vers une autre zone de disponibilité dans la même région. Cette option fournit 99,9999999999 % de durabilité sur une année donnée. Le stockage redondant interzone est important pour la haute disponibilité redondante interzone et est nécessaire si les données doivent rester dans une seule région.
Avec le stockage de sauvegarde géoredondant (différentes régions), les fichiers de sauvegarde sont stockés dans la région du serveur, puis répliqués dans une autre région géo-jumelée. Cette option fournit 99,99999999999999 % de durabilité sur une année donnée. Le stockage géoredondant n’est pris en charge que dans les régions jumelées Azure.
Remarque : Avec Azure Database pour MySQL – Serveur flexible, un espace de sauvegarde pouvant correspondre à jusqu’à 100 % de l’espace de stockage approvisionné est disponible sans frais supplémentaires. Un stockage supplémentaire est facturé en Go par mois. Pour plus d’informations, consultez la documentation sur les tarifs.
Une fois que vous avez une sauvegarde, vous pouvez restaurer la sauvegarde sur un nouveau serveur flexible MySQL. Vous pouvez sélectionner la sauvegarde de trois façons : sélectionner manuellement une sauvegarde complète, sélectionner automatiquement le dernier point de restauration ou sélectionner automatiquement le point de restauration le plus rapide. Si vous avez des sauvegardes géoredondantes, vous pouvez également effectuer une restauration dans la région jumelée (la région croisée).
Temps d’arrêt planifié et fenêtres de maintenance
Une maintenance périodique est nécessaire pour maintenir le serveur managé stable, sécurisé et à jour. Pendant les fenêtres de maintenance, le service reçoit des déploiements de nouvelles fonctionnalités, mises à jour et correctifs. Normalement, les fenêtres de maintenance sont planifiées pour se produire au moins tous les 30 jours, mais les correctifs de sécurité critiques sont appliqués dans les sept jours ou moins.
Vous pouvez choisir une planification gérée par le système ou définir une planification personnalisée pour chaque serveur flexible MySQL dans votre abonnement Azure.
Vous pouvez recevoir des notifications de maintenance planifiée de plusieurs façons. Les notifications peuvent être :
- Envoyées par e-mail à une adresse spécifique ou à un rôle Azure Resource Manager.
- Envoyées par SMS.
- Envoyées (push) en tant que notification d’application Azure.
- Transmises par message vocal.
Fenêtres de maintenance personnalisées
Par défaut, avec une planification gérée par le système, le système sélectionne une fenêtre d’une heure entre 23 h et 7 h dans le fuseau horaire de la région du serveur flexible MySQL. Avec une planification personnalisée, vous pouvez spécifier votre fenêtre de maintenance pour le serveur en choisissant le jour de la semaine et une heure.
Maintenance avec temps d’arrêt proche de zéro pour les serveurs à haute disponibilité (préversion publique)
Les serveurs à haute disponibilité bénéficient d’une maintenance avec un temps d’arrêt proche de zéro. Cette nouvelle fonctionnalité réduit considérablement les temps d’arrêt pour maintenance. Le temps d’arrêt attendu est compris entre 40 et 60 secondes. La maintenance avec un temps d’arrêt proche de zéro est cruciale pour les applications présentant des exigences de haute disponibilité et nécessitant des interruptions minimales de la connectivité de base de données.
Replanifier la maintenance (préversion publique)
Vous pouvez replanifier la maintenance lors de l’utilisation des niveaux de service Usage général ou Critique pour l’entreprise. Dans la section Maintenance du Portail Azure, vous pouvez replanifier la prochaine maintenance planifiée à une autre date et heure. Vous pouvez également lancer la maintenance à la demande en sélectionnant Replanifier maintenant.