Promouvoir les réplicas en lecture dans Azure Database pour PostgreSQL

Promouvoir désigne le processus par lequel un réplica reçoit l’ordre de mettre fin à son mode de réplica et de passer à des opérations de lecture-écriture complètes.

La promotion des réplicas peut être effectuée de deux manières distinctes :

Promouvoir en serveur primaire

Cette action élève un réplica au rôle du serveur primaire. Dans le processus, le serveur primaire actuel est rétrogradé vers un rôle de réplica, ce qui entraîne une permutation des rôles. Pour une promotion réussie, il est nécessaire d’avoir un point de terminaison virtuel configuré pour le serveur primaire actuel comme point de terminaison de l’enregistreur (writer) et le réplica destiné à la promotion en tant que point de terminaison du lecteur (reader). La promotion ne réussit que si le réplica ciblé est inclus dans la configuration du point de terminaison du lecteur.

Le diagramme illustre la configuration des serveurs avant la promotion et l’état résultant une fois l’opération de promotion terminée.

Promouvoir en serveur indépendant et supprimer de la réplication

Lorsque vous choisissez cette option, le réplica est promu pour devenir un serveur indépendant et est supprimé du processus de réplication. Par conséquent, le serveur primaire et le serveur promu fonctionnent en tant que deux serveurs en lecture-écriture indépendants. Il convient de noter que même si les points de terminaison virtuels peuvent être configurés, ils ne sont pas nécessaires pour cette opération. Le serveur nouvellement promu ne fait plus partie des points de terminaison virtuels existants, même si le point de terminaison du lecteur pointait vers celui-ci. C’est pourquoi il est essentiel de mettre à jour la chaîne de connexion de votre application pour diriger vers le réplica nouvellement promu si l’application doit s’y connecter.

Le diagramme montre la façon dont les serveurs sont configurés avant leur promotion et leur configuration après être devenus des serveurs indépendants.

Pour les deux méthodes de promotion, il existe d’autres options à prendre en compte :

• Planifiée : cette option garantit que les données sont synchronisées avant la promotion. Elle applique tous les journaux en attente pour garantir la cohérence des données avant d’accepter les connexions clientes.

• Forcée : cette option est conçue pour une récupération rapide dans des scénarios tels que des pannes régionales. Au lieu d’attendre de synchroniser toutes les données du serveur primaire, le serveur devient opérationnel une fois qu’il traite les fichiers WAL nécessaires pour atteindre l’état cohérent le plus proche. Si vous promouvez le réplica à l’aide de cette option, le décalage qui existe au moment où vous supprimez la liaison entre le serveur réplica et le serveur primaire indique la quantité de données perdues.

Découvrez comment Basculer le réplica en lecture vers le serveur principal et le promouvoir en serveur indépendant, puis le supprimer de la réplication.

Gestion de la configuration

Les réplicas en lecture sont traités comme des serveurs distincts en termes de configurations de plan de contrôle. Cette approche offre une flexibilité pour les scénarios à l’échelle de la lecture. Toutefois, lors de l’utilisation de réplicas à des fins de récupération d’urgence, les utilisateurs doivent s’assurer que la configuration correspond à ce qu’ils veulent.

L’opération de promotion ne reprend pas les paramètres et configurations spécifiques. En voici quelques-uns parmi les plus importants :

• PgBouncer : les paramètres et l’état du pooler de connexions du PgBouncer intégré ne sont pas répliqués pendant le processus de promotion. Si PgBouncer a été activé sur le serveur primaire, mais pas sur le serveur réplica, il reste désactivé sur le serveur réplica après la promotion. Si vous souhaitez avoir PgBouncer sur le serveur nouvellement promu, vous devez l’activer avant ou après l’action de promotion.
• Stockage de sauvegarde géoredondant : Les paramètres de géosauvegarde ne sont pas transférés. Étant donné que vous ne pouvez pas activer la géosauvegarde sur des réplicas, le serveur primaire promu (anciennement le serveur réplica) n’en est pas doté après la promotion. La fonctionnalité ne peut être activée qu’au moment de la création d’un serveur standard (pas un serveur réplica).
• Paramètres de serveur : Si leurs valeurs diffèrent sur le serveur primaire et le réplica en lecture, ils ne sont pas modifiés lors de la promotion. Il est essentiel de noter que les paramètres qui influencent la taille de mémoire partagée doivent avoir les mêmes valeurs sur le serveur primaire et les réplicas. Cette obligation est détaillée dans la section Paramètres de serveur.
• Authentification Microsoft Entra : si l’authentification Microsoft Entra était configurée sur le primaire, mais que le réplica était configuré avec l’authentification PostgreSQL, après la promotion, le réplica ne passera pas automatiquement à l’authentification Microsoft Entra. Il conserve l’authentification PostgreSQL. Les utilisateurs doivent configurer manuellement l’authentification Microsoft Entra sur le réplica promu avant ou après le processus de promotion.
• Haute disponibilité (HA) : Si vous avez besoin d’une haute disponibilité après la promotion, vous devez la configurer sur le serveur primaire fraîchement promu, après l’inversion du rôle.

Considérations

États des serveurs lors de la promotion

Dans les scénarios de promotion planifiée et forcée, il est nécessaire que les serveurs (à la fois principal et réplica) soient dans un état « Prêt ». Si l’état d’un serveur est autre que « Prêt » (par exemple, « Mise à jour » ou « Redémarrage »), la promotion ne peut généralement pas continuer sans problème. Toutefois, une exception est faite dans le cas de pannes régionales.

Lors de ces pannes régionales, la méthode de promotion forcée peut être mise en œuvre quel que soit l'état actuel du serveur primaire. Cette approche permet d’agir rapidement en réponse à d'éventuelles catastrophes régionales, en contournant les vérifications normales de la disponibilité des serveurs.

Si l’ancien serveur primaire échoue au-delà de la récupération pendant la promotion de son réplica, la seule solution consiste à supprimer l’ancien serveur primaire et de recréer le serveur réplica.

Visibilité de plusieurs réplicas pendant la promotion dans les régions non jumelées

Si vous avez plusieurs réplicas et si la région primaire n’a pas de région jumelée, vous devez accorder un examen particulier à ce cas. Si une panne régionale affectant le serveur principal se produit, les autres réplicas ne sont pas automatiquement reconnus par le réplica nouvellement promu. Bien que les applications puissent quand même être dirigées vers le réplica promu pour continuer à fonctionner, les réplicas non reconnus restent déconnectés pendant la panne. Ces réplicas supplémentaires ne se ré-associeront et ne reprendront leur rôle qu’une fois que la région primaire d’origine aura été restaurée.

Restauration à un instant dans le passé pendant une promotion

Dans les scénarios de promotion Planifiée et Forcée, il faut que les dernières sauvegardes automatisées soient disponibles pour veiller à la réussite des opérations de restauration à un instant dans le passé. Nous connaissons le problème où l’opération de restauration à un instant dans le passé peut rencontrer l’erreur suivante après des opérations de basculement et de restauration automatique. La résolution de ce problème est prévue dans une version à venir. Pour veiller à la réussite des opérations de restauration à un instant dans le passé jusqu’au dernier moment, vous pouvez attendre la fin de la sauvegarde automatisée après une opération de promotion.

Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.

Questions fréquemment posées

• Puis-je promouvoir un réplica si la haute disponibilité (HA) est activée sur mon serveur primaire ?

  Oui, que la haute disponibilité soit activée ou non sur votre serveur primaire, vous pouvez promouvoir son réplica en lecture. La possibilité de promouvoir un réplica en lecture en serveur primaire est indépendante de la configuration de la haute disponibilité du serveur primaire.

• Si j’ai un serveur primaire où la haute disponibilité est activée et un réplica en lecture et que je promeus le réplica, puis que je reviens au serveur primaire d’origine, le serveur aura-t-il toujours la haute disponibilité ?

  Non. Nous désactivons la haute disponibilité pendant la promotion initiale, car nous ne prenons pas en charge les réplicas en lecture où la haute disponibilité est activée. La promotion d’un réplica en lecture en serveur primaire signifie que le serveur primaire d'origine change de rôle et devient un réplica. Si vous revenez en arrière, vous devez activer la haute disponibilité sur votre serveur primaire d’origine.

Contenu connexe

• Réplicas en lecture dans Azure Database pour PostgreSQL.
• Géoréplication dans Azure Database pour PostgreSQL.
• Points de terminaison virtuels pour les réplicas en lecture dans Azure Database pour PostgreSQL.
• Créer un réplica en lecture.
• Réplication entre les régions Azure et les réseaux virtuels avec réseau privé.