Description de la haute disponibilité et de la reprise après incident pour Databases for MySQL
La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. Pour les services, la disponibilité est définie dans l'accord de niveau de service. La disponibilité comprend à la fois les événements planifiés et non planifiés, tels que la maintenance, les pannes et les catastrophes. (HA) est la capacité d'un service à rester opérationnel et accessible en cas de défaillance inattendue. La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.
Databases for MySQL est un service régional qui remplit les objectifs de niveau de service(SLO) définis avec le plan standard. Pour plus d'informations, voir l'accord de niveau de service(SLA). IBM Cloud Pour plus d'informations sur les régions et les centres de données disponibles pour Databases for MySQL, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Databases for MySQL offre des fonctionnalités de réplication, de basculement et de haute disponibilité afin de protéger vos bases de données et vos données contre les opérations de maintenance de l'infrastructure, les mises à niveau et certaines pannes. Les déploiements comprennent un cluster composé de trois nœuds de données : un nœud principal et deux répliques. Les répliques sont mises à jour à l'aide d'une réplication asynchrone. Tous les membres contiennent une copie de vos données en utilisant Orchestrator pour traiter les basculements. Le leader et les répliques se trouvent toujours dans des zones différentes d'une région multizone. Si le leader devient inaccessible ou rencontre un problème critique, le service tente d'abord de récupérer automatiquement le leader existant. Si le leader ne peut pas être récupéré, un basculement est effectué et une réplique est promue au rang de leader, une nouvelle réplique rejoint le cluster en tant que réplique et votre cluster continue de fonctionner normalement. Si la réplique échoue, une nouvelle réplique est créée. Si la défaillance d'une zone entraîne la défaillance d'un membre, la nouvelle réplique est créée dans une zone survivante.
Vous pouvez étendre la haute disponibilité en fournissant des répliques en lecture seule pour le basculement interrégional ou le délestage de lecture.
Consultez la documentation d' MySQL sur les techniques de réplication pour comprendre les contraintes et les compromis associés à la réplication asynchrone.
Bien que la version 8.0 utilise une réplication semi-synchrone et que la version 8.4 introduise une technologie asynchrone, les comportements de base en matière de haute disponibilité et de reprise après sinistre restent fondamentalement inchangés.
Les charges de travail qui accèdent de manière programmatique à la grappe doivent suivre la logique de relance de la disponibilité du client pour maintenir la disponibilité.
Databases for MySQL effectue parfois des commutations contrôlées en fonctionnement normal. Ces basculements s'effectuent généralement sans perte de données et entraînent la réinitialisation des connexions actives. Il existe une période de 15 secondes maximum au cours de laquelle les reconnexions peuvent échouer. Il peut arriver que des basculements imprévus se produisent en raison d'événements imprévus dans l'environnement d'exploitation. Cela peut prendre jusqu'à 2 minutes, car l'instance peut mettre un certain temps à désigner un nœud opérationnel comme leader. La maintenance des services, par exemple, déclenche un basculement contrôlé.
Fonctionnalités de haute disponibilité
Databases for MySQL prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Comportement en cas de basculement | Standard sur tous les clusters et résilient en cas de défaillance d'une zone ou d'un seul membre. Si le leader devient inaccessible ou défaillant, le service tente de le rétablir automatiquement. Si le leader ne peut pas être récupéré, un basculement est effectué et une réplique est promue afin de restaurer la disponibilité en écriture. | Pour minimiser le décalage entre le leader et les répliques, suivez les meilleures pratiques, telles que la logique de réessai, la gestion des connexions et la mise en œuvre de clés primaires. |
| Nombre de membres | Un déploiement de trois membres. Un cluster à trois membres peut récupérer après une seule défaillance d'une instance ou d'une zone, avec un éventuel décalage des données pendant le processus de récupération. En cas de défaillance, un réplica est promu au rang de leader et le cluster continue à fonctionner normalement. | |
| Réplique en lecture seule | Les répliques en lecture seule peuvent fournir un accès local dans les régions éloignées, améliorant ainsi la disponibilité en cas de latence du réseau ou de problèmes de connectivité. | Toutes les demandes d'écriture doivent être adressées exclusivement à la grappe de lecture-écriture associée à la réplique de lecture. |
Architecture de reprise après sinistre
La stratégie générale de reprise après sinistre consiste à créer une nouvelle base de données, telle que la base de données Restore. Le contenu de la nouvelle base de données peut être une sauvegarde de la base de données source
créée avant le sinistre. Une nouvelle base de données peut être créée à l'aide de la fonction "point-in-time" si la base de données de production est disponible.
Fonctionnalités de reprise après sinistre
Databases for MySQL prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Restauration de la sauvegarde | Créer une base de données à partir d'une sauvegarde précédemment créée. Pour plus d'informations, voir Gestion des sauvegardes Cloud Databases. | Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
| Restauration avec point de cohérence | Créer une base de données à partir de la production en direct à l'aide de la récupération ponctuelle. | Cela n'est possible que si la base de données active est disponible et que le RPO (sinistre) se situe dans la fenêtre prise en charge. Elle n'est pas utile si le cluster de production n'est pas disponible. Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
| Promouvoir la réplique de lecture | Créez une réplique en lecture seule lorsque vous prévoyez un sinistre dans la même région ou dans une région éloignée. Promouvoir le réplica en lecture seule pour récupérer après un sinistre. | La réplique en lecture créée précédemment doit être disponible. Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
Planification de la reprise après incident
Les étapes de la reprise après sinistre doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.
| Echec | Résolution |
|---|---|
| Défaillance du matériel (point unique) | IBM fournit une base de données qui résiste à un seul point de défaillance matérielle au sein d'une zone - aucune configuration n'est requise. |
| défaillance de zone | Basculement (#mysql-haute-disponibilité). Les membres de la base de données sont répartis entre les zones. |
| Altération de données | Restauration de la sauvegarde. Utilisez la base de données restaurée en production ou comme source de données pour corriger la corruption dans la base de données restaurée.
Restauration ponctuelle. Utilisez la base de données restaurée en production ou comme source de données pour corriger la corruption dans la base de données restaurée. |
| Défaillance régionale | Restauration de la sauvegarde. Utiliser la base de données restaurée en production.
Promouvoir la réplique en lecture. Promouvoir un réplica en lecture seule vers une base de données en lecture/écriture. Utiliser la base de données restaurée en production |
Haute disponibilité au niveau de l'application
Les applications qui communiquent par le biais de réseaux et de services cloud sont sujettes à des pannes de connexion transitoires. Vous souhaitez concevoir vos applications de telle manière que les connexions soient relancées lorsque des erreurs se produisent à cause d'une perte temporaire de connectivité avec votre déploiement ou avec IBM Cloud.
Databases for MySQL étant un service géré, des mises à jour régulières et la maintenance de la base de données sont effectuées dans le cadre des opérations courantes. Si les deux répliques sont perdues, les écritures sur le leader sont bloquées, car le processus de réplication semi-synchrone ne dispose plus de suiveur. Pour plus d'informations, voir réplication semi-synchrone. Ce scénario entraîne parfois de brèves périodes pendant lesquelles votre base de données n'est pas disponible. Cela peut également provoquer une reprise en ligne gracieuse de la base de données, une nouvelle tentative et une reconnexion. Il faut peu de temps à la base de données pour déterminer quel membre est une réplique et quel membre est le maître, par conséquent, il se peut aussi que vous constatiez une courte interruption de connexion. Les basculements ne durent généralement pas plus de 30 secondes. Pour minimiser les interruptions, les mises à jour sont appliquées aux répliques en premier et au responsable en dernier.
Vos applications doivent être conçues pour gérer des interruptions temporaires de connexion à la base de données, implémenter le traitement d'erreurs pour les commandes de base de données qui échouent et implémenter une logique de relance pour effectuer une reprise après une interruption temporaire.
Une interruption de connexion ou une non-disponibilité de la base de données pendant plusieurs minutes n'est pas censée se produire. Si vous constatez des périodes de plus d'une minute sans connexion, veuillez ouvrir un ticket d'assistance en fournissant tous les détails afin que nous puissions examiner le problème.
limites de connexion
Databases for MySQL définit le nombre maximal de connexions à votre base de données MySQL vers 200. Laissez certaines connexions disponibles, car un certain nombre d'entre elles sont réservées à l'interne pour maintenir l'état et l'intégrité de votre base de données. Une fois la limite de connexions atteinte, toute tentative d'établissement d'une nouvelle connexion génère une erreur. Pour éviter de surcharger votre déploiement avec des connexions, utilisez le regroupement de connexions ou mettez à niveau votre déploiement et augmentez le nombre limite de connexions. Pour plus d'informations, voir Gestion des connexions MySQL.
Vos responsabilités en matière d'HA et de DR
Les informations suivantes peuvent vous aider à créer et à mettre en pratique en permanence votre plan pour l'AH et le DR.
Lors de la restauration d'une base de données à partir de sauvegardes ou d'une restauration ponctuelle, une nouvelle base de données est créée avec de nouvelles chaînes de connexion. Les charges de travail et les processus existants doivent être adaptés pour utiliser les nouvelles chaînes de connexion. La promotion d'un réplica en lecture dans un cluster aura un impact similaire, bien que les parties en lecture seule de la charge de travail ne soient pas affectées.
Une base de données restaurée peut également avoir besoin des mêmes dépendances créées par le client que la base de données sinistrée - assurez-vous que ces services et d'autres existent dans la région restaurée :
- IBM® Key Protect for IBM Cloud®
N'oubliez pas que la suppression d'une base de données entraîne également la suppression des sauvegardes qui lui sont associées. Toutefois, les bases de données supprimées peuvent être récupérées dans un délai limité. Reportez-vous à la FAQ sur les sauvegardes pour obtenir des détails spécifiques sur les procédures de récupération des bases de données.
Il n'est pas possible de copier des sauvegardes à partir du site IBM Cloud, il faut donc envisager d'utiliser les outils spécifiques à la base de données pour effectuer des sauvegardes supplémentaires. Il peut être nécessaire de récupérer une base de données malveillante supprimée, suivie d'une réclamation-suppression de la base de données. Une gestion rigoureuse de l'accès IAM aux bases de données peut contribuer à réduire l'exposition à ce problème.
La liste de contrôle suivante, associée à chaque caractéristique, peut vous aider à créer et à mettre en pratique votre plan.
- Restauration de la sauvegarde
- Vérifier que les sauvegardes sont disponibles à la fréquence souhaitée pour répondre aux exigences du RPO. Pour plus d'informations, voir Gestion des sauvegardes Cloud Databases. Envisagez un script utilisant IBM Cloud® Code Engine- Working with the Periodic timer(cron)event producer pour créer des sauvegardes supplémentaires à la demande afin d'améliorer le RPO si la criticité et la taille de la base de données le permettent. Toutefois, compte tenu des capacités de MySQL's PITR, il convient d'évaluer soigneusement la nécessité de disposer de sauvegardes supplémentaires.
- Il existe certaines restrictions sur les régions de restauration des bases de données - vérifiez que vos objectifs de restauration peuvent être atteints en lisant la rubrique gestion des sauvegardes du site Cloud Databases.
- Vérifiez que la durée de conservation des sauvegardes est conforme à vos exigences.
- Planifier régulièrement des restaurations de test pour vérifier que les temps de restauration réels respectent le RTO défini. N'oubliez pas que la taille de la base de données a un impact significatif sur le temps de restauration. Envisagez des stratégies pour réduire les temps de restauration, par exemple en divisant les grandes bases de données en unités plus petites et plus faciles à gérer et en purgeant les données inutilisées.
- Vérifiez le service Key Protect.
- Restauration avec point de cohérence
- Vérifier les procédures décrites précédemment.
- Vérifiez que la sauvegarde souhaitée se trouve dans la fenêtre.
- Promouvoir la réplique de lecture
- Vérifiez qu'un réplica en lecture existe dans la région de récupération.
- Pratiquez le processus de promotion - créez une réplique temporaire en lecture dans la région souhaitée. La réplique temporaire peut être promue en lecture/écriture et certains tests peuvent être effectués sans grand impact sur la production.
Pour en savoir plus sur la répartition des responsabilités entre le client et IBM Cloud pour l'utilisation de Databases for MySQL, voir Partage des responsabilités pour Cloud Databases.
Restez informé : IBM notifications
Les mises à jour affectant les charges de travail des clients sont communiquées par le biais de notifications à l'adresse IBM Cloud. Pour rester informé de la maintenance planifiée, des annonces et des notes de version relatives à ce service, consultez la page Notifications de surveillance et état d'avancement. En outre, consultez régulièrement la page Politique en matière de versions pour obtenir les dernières mises à jour sur les versions et les dates de fin de vie.