Description de la haute disponibilité et de la reprise après incident pour Databases for PostgreSQL
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 de la haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.
Databases for PostgreSQL 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 Accord de niveau de service(SLA). IBM Cloud Pour plus d'informations sur les régions et les centres de données disponibles pour site.data.keyword.databases-for-postgresql, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Databases for PostgreSQL offre des fonctions de réplication, de basculement et de haute disponibilité pour protéger vos bases de données et vos données de la maintenance de l'infrastructure, des mises à niveau et de certaines pannes. Les déploiements contiennent un cluster avec deux membres de données - le leader et le réplica. La réplique est maintenue à jour à l'aide d'une réplication asynchrone. Un mécanisme de consensus distribué est utilisé pour maintenir l'état de la grappe et gérer les basculements. Si le leader devient inaccessible, le cluster initie un basculement, la réplique est promue au rang de leader et une nouvelle réplique rejoint le cluster en tant que réplique. Le leader et la réplique se trouvent toujours dans des zones différentes d'une MZR. 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 sera créée dans une zone survivante.
Vous pouvez étendre la haute disponibilité en ajoutant des membres PostgreSQL au cluster pour une plus grande redondance dans la région, ou en fournissant des répliques en lecture seule pour le basculement interrégional ou le délestage de la lecture.
Consultez la documentation PostgreSQL sur les techniques de réplication pour comprendre les contraintes et les compromis associés à la stratégie de réplication asynchrone déployée par défaut.
Dans les scénarios où une base de données devient gravement malsaine, comme une panne de serveur sur le leader, Databases for PostgreSQL tente un basculement. Cette capacité de basculement automatique est plafonnée à 16 Mo de décalage de données entre le leader et la réplique (quelques lignes de données une fois, ce qui représente plus de PostgreSQL ) et n'est pas exécutée si le seuil de décalage est dépassé. Si la perte potentielle de 16 Mo de données est intolérable pour l'application, voir la réplication synchrone ci-dessous.
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é.
Le service effectuera parfois des bascules contrôlées dans le cadre de son fonctionnement normal. Ces basculements ne provoquent pas de perte de données mais 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. Parfois, des défaillances non planifiées peuvent se produire en raison d'événements imprévus dans l'environnement d'exploitation. Elles peuvent durer jusqu'à 45 secondes, mais généralement moins de 30. La maintenance des services, par exemple, déclenche un basculement contrôlé.
Fonctionnalités de haute disponibilité
Databases for PostgreSQL prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Basculement automatique | Standard sur tous les clusters et résilience en cas de défaillance d'une zone ou d'un seul membre | |
| Nombre de membres | Minimum - 2 membres. Par défaut, il s'agit d'un déploiement standard à deux membres. Un cluster à deux membres se rétablit automatiquement en cas de défaillance d'une seule instance ou d'une seule zone (avec une perte de données jusqu'au seuil de décalage). Pendant la synchronisation des données pour une nouvelle réplique, la grappe est exposée à une deuxième défaillance qui entraîne une perte de données. Un système à trois membres, voir l'ajout de membres sur PostgreSQL, est résistant à la défaillance de deux membres au cours de la même période de défaillance | Trois membres requis pour la réplication synchrone |
| réplication synchrone | Améliore le RPO en ajoutant la synchronisation des membres à distance au chemin d'écriture des données. Reportez-vous à la section Réplication synchrone ci-dessous. | Impact sur les performances et coût. |
| réplique accessible 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 dirigées exclusivement vers le cluster de lecture-écriture associé à la réplique de lecture |
Réplication synchrone Databases for PostgreSQL
Par défaut, la réplication en continu est asynchrone. Si le leader tombe en panne, certaines transactions engagées peuvent ne pas avoir été synchronisées avec la réplique, ce qui entraîne une perte de données. Cloud Databases garantit que
la perte de données est maintenue à un minimum substantiel; toutefois, la réplication synchrone offre la possibilité de confirmer que toutes les modifications apportées par une transaction ont été synchronisées avec une réplique. Cela
permet d'assurer la cohérence au sein d'un cluster. Cette cohérence provient de la confirmation que les écritures sont écrites sur un secondaire avant de retourner au client connecté avec success. Pour les variables concernant
la réplication synchrone, voir synchronous_commit sur la page Modification de la configuration.
La réplication synchrone apporte la disponibilité de la réplique dans le chemin d'écriture principal. S'il n'y a pas de réplique pour accuser réception d'une écriture, le système reste en suspens jusqu'à ce qu'une réplique soit disponible. Cela nécessite au moins trois membres de fonctionner de manière fiable, car la réplication synchrone n'est pas prise en charge sur les déploiements à deux membres. Vous devez passer horizontalement à au moins trois membres avant d'activer la réplication synchrone. Voir l'ajout de membres sur PostgreSQL.
Bien que cela soit peu probable, il est possible que plusieurs répliques deviennent indisponibles simultanément. Si cela se produit, la base de données principale ne pourra terminer aucune écriture tant qu'une réplique ne sera pas en ligne, bloquant ainsi tout le trafic en écriture sur votre base de données. Lorsque vous décidez d'utiliser la réplication synchrone, évaluez les coûts et avantages relatifs d'une plus grande durabilité des données par rapport aux problèmes de disponibilité potentiels.
La configuration de la réplication synchrone peut augmenter considérablement la latence d'écriture et réduire le débit global. Pour des performances optimales, il est recommandé de n'utiliser la réplication synchrone que pour des bases de données ou des charges de travail spécifiques qui requièrent le plus haut degré de durabilité des données.
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, comme la base de données Restore ci-dessous. 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 PostgreSQL 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 créée précédemment; 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 en utilisant 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 des répliques 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 automatique (#postgresql-haute-disponibilité). Les membres de la base de données sont répartis entre les zones. La configuration de trois membres permet d'accroître la résilience en cas de défaillance de plusieurs zones.
La réplication synchrone réduit le RPO au détriment de la performance. |
| 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.
Comme Databases for PostgreSQL est un service géré, les mises à jour régulières et la maintenance de la base de données font partie des opérations normales. Cela peut parfois entraîner de courts intervalles pendant lesquels votre base de données n'est pas disponible. Cela peut également provoquer le déclenchement d'une séquence normale de basculement, relance et reconnexion par la base de données. 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.
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. Ouvrez un dossier d'assistance avec des détails si vous avez des périodes de plus d'une minute sans connectivité afin que nous puissions enquêter.
limites de connexion
Databases for PostgreSQL définit le nombre maximal de connexions à votre base de données PostgreSQL vers 115. 15 connexions sont réservées au superutilisateur pour le maintien de l'état et de l'intégrité de votre base de données, et 100 connexions sont disponibles pour vous et vos applications. Une fois la limite de connexion atteinte, toute tentative d'établissement d'une nouvelle connexion aboutit à une erreur. Pour éviter de submerger votre déploiement de connexions, utilisez la mise en commun des connexions ou faites évoluer votre déploiement et augmentez sa limite de connexions. Voir la page Gestion des connexions PostgreSQL pour plus d'informations.
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®
- Hyper Protect Crypto Services
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 documentation pour obtenir des détails spécifiques sur les procédures de récupération de la base 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. La gestion des sauvegardes sur Cloud Databases documente la fréquence des sauvegardes. 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 PostgreSQL'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.
- Planifiez 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. Veuillez envisager des stratégies pour minimiser 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érifier 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 PostgreSQL, 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 consacrée à la politique en matière de versions pour connaître les dernières mises à jour concernant les versions et les dates de fin de vie.