Haute disponibilité dans Azure Database for MariaDB

  • Article

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 ?.

Le service Azure Database for MariaDB convient à l’exécution de bases de données stratégiques nécessitant une durée de fonctionnement élevée. Il fournit une haute disponibilité pendant les étapes suivantes :

  • Événements planifiés, tels que les opérations de calcul à l’échelle initiées par l’utilisateur.
  • Événements non planifiés, tels que le matériel sous-jacent, les logiciels ou les défaillances réseau.

Azure Database for MariaDB fournit un contrat de niveau de service soutenu financièrement pour le temps d’activité. Étant donné que le service est basé sur l’architecture Azure, vous pouvez tirer parti de ses fonctionnalités de haute disponibilité, de redondance et de résilience sans configurer de composants supplémentaires.

Composants d’Azure Database for MariaDB

Composant Description
Serveur de base de données MariaDB Azure Database for MariaDB offre des fonctionnalités et des dispositifs de sécurité, d’isolement, de protection des ressources et de redémarrage rapide pour les serveurs de base de données. Ces fonctionnalités facilitent les opérations telles que la mise à l’échelle et la récupération du serveur de base de données (en secondes) après une panne.
Les modifications de données dans le serveur de base de données se produisent généralement dans le contexte d’une transaction de base de données. Toutes les modifications de base de données sont enregistrées de manière synchrone sous la forme de journaux d’activité en écriture anticipée (fichiers ib_log) sur Stockage Azure, qui est attachée au serveur de base de données. Au cours de processus de point de contrôle de base de données, les pages de données de la mémoire du serveur de base de données sont également vidées dans le stockage.
Stockage étendu Tous les fichiers de données physiques et fichiers journaux MariaDB sont stockés sur Stockage Azure, qui stocke trois copies de données dans une région pour fournir la redondance, la disponibilité et la fiabilité des données. La couche de stockage est indépendante du serveur de base de données. Il peut être détaché d’un serveur de base de données défaillant et attaché à un nouveau serveur de base de données en quelques secondes.
Stockage Azure surveille en permanence les erreurs de stockage. S’il détecte une altération de bloc, il résout automatiquement le problème en instanciant une nouvelle copie de stockage.
Passerelle La passerelle agit en tant que proxy de base de données en acheminant toutes les connexions clientes vers le serveur de base de données.

Atténuation des temps d’arrêt planifiés

L’architecture d’Azure Database for MariaDB offre une haute disponibilité pendant les opérations de temps d’arrêt planifiées.

Diagram of elastic scaling in Azure Database for MariaDB.

Voici quelques scénarios de maintenance planifiée :

Scénario Description
Scale-up ou scale-down de calcul Lorsque vous effectuez une opération de scale-up ou de scale-down de calcul, Azure Database for MariaDB provisionne un nouveau serveur de base de données à l’aide de la configuration de calcul mise à l’échelle. Sur l’ancien serveur de base de données, le service permet aux case activée points actifs de terminer, de vider les connexions clientes et d’annuler les transactions non validées. Le service arrête ensuite l’ancien serveur de base de données. Il détache le stockage de l’ancien serveur de base de données et attache le stockage au nouveau serveur de base de données. Lorsque l’application cliente retente la connexion ou tente d’établir une nouvelle connexion, la passerelle dirige la demande de connexion vers le nouveau serveur de base de données.
Augmentation du stockage Le scale-up du stockage est une opération en ligne et n’interrompt pas le serveur de base de données.
Déploiement de nouveaux logiciels (Azure) Les déploiements de nouvelles fonctionnalités ou de correctifs de bogues se produisent automatiquement dans le cadre de la maintenance planifiée du service. Pour plus d’informations, consultez la documentation et case activée votre portail.
Mises à niveau de version secondaire Azure Database for MariaDB met automatiquement à jour les serveurs de base de données vers la version mineure qu’Azure détermine. La mise à jour corrective automatique se produit dans le cadre de la maintenance planifiée du service. Il entraîne un temps d’arrêt court en termes de 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 case activée votre portail.

Atténuation des temps d’arrêt non planifiés

Les temps d’arrêt non planifiés peuvent se produire suite à des défaillances imprévues, notamment des pannes matérielles sous-jacentes, des problèmes réseau et des bogues logiciels. Si le serveur de base de données tombe en panne de façon inattendue, un nouveau serveur de base de données est automatiquement approvisionné en quelques secondes. Le stockage étendu est automatiquement attaché au nouveau serveur de base de données.

Le moteur MariaDB effectue l’opération de récupération à l’aide du journal et des fichiers de base de données en écriture avant et ouvre le serveur de base de données pour permettre aux clients de se connecter. Les transactions non validées sont perdues et l’application doit les réessayer.

Bien que vous ne puissiez pas éviter les temps d’arrêt non planifiés, Azure Database for MariaDB l’atténue en effectuant automatiquement des opérations de récupération sur le serveur de base de données et les couches de stockage sans nécessiter d’intervention humaine.

Diagram of high availability in Azure Database for MariaDB.

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

Voici deux scénarios d’échec et comment Azure Database for MariaDB récupère automatiquement :

Scénario Récupération automatique
Échec du serveur de base de données Si le serveur de base de données est arrêté en raison d’une erreur matérielle sous-jacente, Azure Database for MariaDB supprime les connexions actives et annule les transactions en cours. Le service déploie automatiquement un nouveau serveur de base de données et attache le stockage de données distant au nouveau serveur de base de données. Une fois la récupération de la base de données terminée, les clients peuvent se connecter au nouveau serveur de base de données via la passerelle.
Les applications qui utilisent les bases de données MariaDB doivent être créées de manière à détecter et réessayer les connexions supprimées et les transactions ayant échoué. Lorsque l’application retente une connexion, la passerelle redirige de manière transparente la connexion vers le serveur de base de données nouvellement créé.
Échec de stockage Stockage problèmes connexes, tels qu’une défaillance de disque ou une altération de bloc physique, n’affectent pas les applications. Étant donné que les données sont stockées en trois copies, le stockage survivant sert la copie des données. Azure Database for MariaDB corrige automatiquement les altérations de blocage. Si une copie de données est perdue, le service crée automatiquement une nouvelle copie des données.

Voici les scénarios d’échec qui nécessitent une action utilisateur pour récupérer :

Scénario Plan de récupération
Défaillance de région Une défaillance de région est un événement rare. Toutefois, si vous avez besoin d’une protection contre une défaillance de région, vous pouvez configurer un ou plusieurs réplicas en lecture dans d’autres régions pour la récupération d’urgence. Pour plus d’informations, consultez cet article sur la création et la gestion des réplicas en lecture. Si une défaillance au niveau de la région se produit, vous pouvez promouvoir manuellement un réplica en lecture configuré dans une autre région pour être votre serveur de base de données de production.
Erreur logique/utilisateur La récupération à partir d’erreurs utilisateur, telles que des tables supprimées accidentellement ou des données incorrectement mises à jour, implique l’exécution d’une récupération à un point dans le temps. Cette action restaure et récupère les données jusqu’au moment où l’erreur s’est produite.
Si vous souhaitez restaurer uniquement un sous-ensemble de bases de données ou des tables spécifiques plutôt que toutes les bases de données du serveur de base de données, vous pouvez restaurer le serveur de base de données dans une nouvelle instance, exporter les tables via mysqldump, puis restaurer ces tables dans votre base de données.

Résumé

Azure Database for MariaDB offre des fonctionnalités de haute disponibilité inhérentes pour protéger vos bases de données contre les pannes courantes. Il offre une fonctionnalité de redémarrage rapide des serveurs de base de données, un stockage redondant et un routage efficace à partir de la passerelle. Pour une protection supplémentaire des données, vous pouvez configurer des sauvegardes pour qu’elles soient géorépliquées et déployer des réplicas en lecture dans d’autres régions.

Étapes suivantes