Géoréplication dans Azure Database pour PostgreSQL - Serveur flexible
S’APPLIQUE À : 
Azure Database pour PostgreSQL – Serveur flexible
Un réplica en lecture peut être créé dans la même région que le serveur primaire ou dans une autre région géographique. La géoréplication peut être utile pour des scénarios comme la planification de la récupération d’urgence ou la mise à disposition des données plus près de vos utilisateurs.
Vous pouvez avoir un serveur principal dans n’importe quel serveur région de serveur flexible Azure Database pour PostgreSQL. Un serveur principal peut également avoir des réplicas dans n’importe quelle région mondiale d’Azure prenant en charge le serveur flexible Azure Database pour PostgreSQL. En outre, nous prenons en charge des régions spéciales Azure Government et Microsoft Azure gérés par 21Vianet. Les régions spéciales désormais prises en charge sont :
Régions Azure Government :
- Gouvernement des États-Unis – Arizona
- Gouvernement des États-Unis – Texas
- Gouvernement américain - Virginie
Microsoft Azure géré par 21Vianet :
- Chine Nord 3
- Chine Est 3
- Chine Nord 2
- Chine orientale 2
Régions jumelées pour la récupération d’urgence
Bien que la création de réplicas dans n’importe quelle région prise en charge soit possible, il existe des avantages notables au fait de choisir des réplicas dans des régions jumelées, en particulier dans le cadre d’une architecture à des fins de récupération d’urgence :
Séquence de récupération régionale : en cas de panne à l’échelle d’une zone géographique, la récupération d’une région à partir de chaque ensemble jumelé est prioritaire, ce qui garantit que les applications dans les régions jumelées ont toujours une région dont la récupération est accélérée.
Mise à jour séquentielle : les mises à jour des régions jumelées sont échelonnées par ordre chronologique, ce qui minimise le risque de temps d’arrêt dû à des problèmes de mise à jour.
Isolation physique : une distance minimale de 300 miles (482,8 km) est maintenue entre les centres de données dans des régions jumelées, ce qui réduit le risque de pannes simultanées en cas d’événements importants.
Résidence des données : à quelques exceptions près, les régions d’un ensemble jumelé résident dans la même zone géographique, répondant aux exigences de résidence des données.
Performances : bien que les régions jumelées offrent généralement une faible latence du réseau, améliorant l’accessibilité des données et l’expérience utilisateur, elles ne sont peut-être pas toujours les régions où la latence est la plus faible. Si l’objectif premier est de rapprocher les données des utilisateurs plutôt que de donner la priorité à la récupération d’urgence, il est essentiel d’évaluer la latence de toutes les régions disponibles. Dans certains cas, une région non jumelée peut présenter la latence la plus faible. Pour une meilleure compréhension, vous pouvez vous référer aux chiffres de latence aller-retour d’Azure pour faire un choix éclairé.
Pour une compréhension plus approfondie des avantages des régions jumelées, reportez-vous à la documentation d’Azure sur la réplication inter-régions.
Défaillances régionales et récupération
Les installations Azure de différentes régions sont conçues pour être hautement fiables. Toutefois, dans de rares circonstances, une région entière peut devenir inaccessible pour des raisons allant de pannes de réseau à des scénarios graves tels que des catastrophes naturelles. Les fonctionnalités d’Azure permettent de créer des applications réparties entre plusieurs régions, ce qui garantit qu’une défaillance dans une région n’affecte pas les autres.
Se préparer aux sinistres régionaux
Être préparé pour les sinistres régionaux potentiels est critique pour garantir le fonctionnement ininterrompu de vos applications et services. Si vous envisagez un plan d’urgence robuste pour votre instance de serveur flexible Azure Database pour PostgreSQL, voici les étapes et considérations clés :
- Établissez un réplica en lecture géorépliqué : il est essentiel qu’un réplica en lecture soit configuré dans une région distincte de votre primaire. Cela permet d’assurer la continuité en cas de panne de la région primaire.
- Garantir la symétrie du serveur : l’action « Promouvoir en serveur primaire » est la plus recommandée pour la gestion des pannes régionales, mais elle est fournie avec une exigence de symétrie du serveur. Cela signifie que les serveurs principaux et réplicas doivent avoir des configurations identiques de paramètres spécifiques. Les avantages de cette action sont les suivants :
- Vous n’avez pas besoin de modifier les chaînes de connexion d’application si vous utilisez des points de terminaison virtuels.
- Il fournit un processus de récupération fluide où, une fois que la région affectée est de retour en ligne, le serveur primaire d’origine reprend automatiquement sa fonction, mais dans un nouveau rôle de réplica.
- Configurer des points de terminaison virtuels : les points de terminaison virtuels permettent une transition fluide de votre application vers une autre région en cas de panne. Ils éliminent la nécessité de modifier les chaînes de connexion de votre application.
- Configurez le réplica en lecture : tous les paramètres du serveur primaire ne sont pas répliqués sur le réplica en lecture. Il est essentiel de s’assurer que toutes les configurations et fonctionnalités nécessaires (par exemple PgBouncer) sont correctement configurées sur votre réplica en lecture. Pour plus d’informations, consultez la section Gestion de la configuration.
- Préparer la haute disponibilité (HA) : si votre configuration nécessite une haute disponibilité, elle n’est pas automatiquement activée sur un réplica promu. Soyez prêt à l’activer après la promotion. Envisagez d’automatiser cette étape pour réduire les temps d’arrêt.
- Tests réguliers : simuler régulièrement des scénarios de sinistres régionaux pour valider les cibles, configurations et seuils existants. Assurez-vous que votre application répond comme prévu pendant ces scénarios de test.
- Suivez l’aide générale d’Azure : Azure fournit une aide complète sur la fiabilité et la préparation aux désastres. Il est très utile de consulter ces ressources et d’intégrer les meilleures pratiques dans votre plan de préparation.
Le fait d’être proactif et de se préparer à l’avance aux sinistres régionaux garantit la résilience et la fiabilité de vos applications et de vos données.
Quand les pannes ont un impact sur votre contrat de niveau de service
En cas de panne prolongée du serveur flexible Azure Database pour PostgreSQL dans une région spécifique qui menace le contrat de niveau de service (SLA) de votre application, sachez que les deux actions décrites ci-dessous ne sont pas basées sur le service. L’intervention de l’utilisateur est nécessaire pour les deux. Il est recommandé d’automatiser l’ensemble du processus autant que possible et d’avoir une surveillance robuste en place. Pour en savoir plus sur les informations fournies lors d’une interruption de service, consultez la page Interruptions de service. Seule une promotion forcée est possible dans le cas d’une région en panne, ce qui signifie que la perte de données correspond à peu près au décalage actuel entre le réplica et le serveur primaire. Par conséquent, il est essentiel de surveiller le décalage. Prenez en considération les étapes suivantes :
Promouvoir en serveur primaire
Cette option ne nécessite pas la mise à jour des chaînes de connexion dans votre application, à condition que les points de terminaison virtuels soient configurés. Une fois activé, le point de terminaison de l’enregistreur pointera à nouveau vers le nouveau primaire dans une région différente et la colonne état de la réplication dans le portail Azure affichera « Reconfiguration ». Une fois la région affectée restaurée, l’ancien serveur primaire reprend automatiquement ses fonctions, mais désormais dans un rôle de réplica.
Promouvoir en serveur indépendant et supprimer de la réplication
Dans ce cas, il s’agit de la seule option viable. Après avoir promu le serveur, vous devez mettre à jour les chaînes de connexion de votre application. Une fois la région d’origine restaurée, l’ancien primaire peut redevenir actif. Veillez à le supprimer pour éviter d’entraîner des coûts inutiles. Si vous souhaitez conserver la topologie précédente, recréez le réplica en lecture.