Promouvoir des réplicas en lecture dans un serveur flexible 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.

Important

L’opération de promotion n’est pas automatique. Si une défaillance se produit sur le serveur principal, le système ne bascule pas vers le réplica en lecture de manière indépendante. Une action utilisateur est toujours requise pour l’opération de promotion.

Vous pouvez promouvoir des réplicas de deux façons 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, vous devez configurer un point de terminaison virtuel pour l’instance principale actuelle en tant que point de terminaison d’écriture, et pour la réplique destinée à la promotion en tant que point de terminaison de lecture. La promotion ne réussit que si le réplica ciblé est inclus dans la configuration du point de terminaison du lecteur. Un utilisateur disposant de l’autorisation Microsoft.DBforPostgreSQL/servers/write sur le serveur source peut effectuer l’opération de basculement.

Si le serveur principal comporte des réplicas défectueux, supprimez-les avant de lancer l'action de promotion en serveur principal. Pendant ce processus, le réplica de lecture est promu au statut de nouveau serveur principal. Cette opération peut entraîner un bref temps d’arrêt d’environ 1 à 3 minutes, en fonction du décalage de réplication au moment de la promotion (pour les promotions planifiées). Une fois la promotion terminée, le serveur principal précédent est reconfiguré pour fonctionner en tant que réplica en lecture.

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

Diagramme montrant l’opération de promotion du serveur primaire.

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. Bien que vous puissiez configurer des points de terminaison virtuels, il ne s’agit pas d’une nécessité 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. Mettez à jour la chaîne de connexion de votre application afin qu'elle pointe vers le réplica nouvellement promu si l'application doit s'y connecter.

Le diagramme suivant montre comment les serveurs sont configurés avant qu’ils ne soient promus et leur configuration après avoir réussi à devenir des serveurs indépendants.

Diagramme montrant la promotion en serveur indépendant et l’opération de suppression de la réplication.

Important

L’action Promouvoir en serveur indépendant et supprimer de la réplication est rétrocompatible avec la fonctionnalité de promotion précédente.

Important

Symétrie de serveurs : Pour qu’une opération de promotion en serveur primaire réussisse, les serveurs primaires et réplicas doivent avoir des niveaux et des tailles de stockage identiques. Par exemple, si le serveur principal a 2 vCores et que le réplica a 4 vCores, la seule option viable consiste à utiliser l’action « Promouvoir vers un serveur indépendant et supprimer de la réplication ». En outre, ils doivent partager les mêmes valeurs pour les paramètres qui allouent de la mémoire partagée.

Pour les deux méthodes de promotion, tenez compte des options suivantes :

  • 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 au moment où vous dissociez le réplica du serveur principal indique la quantité de données perdues.

Important

L’option de promotion forcée est conçue pour traiter les pannes régionales et, dans pareil cas, elle ignore toutes les vérifications, y compris l’exigence de symétrie de serveurs, et procède à la promotion. Cette priorité est la disponibilité immédiate du serveur pour gérer les scénarios d’urgence. Toutefois, l’utilisation de l’option « Forced » en dehors des scénarios de panne de région n’est pas autorisée si les exigences relatives aux réplicas en lecture spécifiées dans la documentation, en particulier l’exigence de symétrie des serveurs, ne sont pas respectées, car cela pourrait entraîner des problèmes tels qu’une rupture de la réplication.

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

Le plan de contrôle traite les réplicas en lecture comme des serveurs distincts ; vous gérez donc leurs configurations de manière indépendante. Cette approche offre une flexibilité pour les scénarios à l’échelle de la lecture. Toutefois, lorsque vous utilisez des répliques pour la reprise après sinistre, vous devez vous assurer que la configuration correspond bien à celle souhaitée.

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 vous avez activé PgBouncer sur le serveur principal, mais pas sur le réplica, il reste désactivé sur le réplica après la promotion. Pour utiliser 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. Vous ne pouvez activer la fonctionnalité que lors de la création du serveur standard (et non d’un réplica).
  • Paramètres : si leurs valeurs diffèrent entre le serveur principal et le réplica en lecture, elles ne changent pas lors de la promotion. Les paramètres qui influencent la taille de la mémoire partagée doivent avoir les mêmes valeurs sur le serveur principal et les réplicas. Cette exigence est détaillée dans la section Paramètres .
  • Microsoft Entra authentification : si l'authentification principale a Microsoft Entra configurée, mais que le réplica utilise l'authentification PostgreSQL, la promotion ne bascule pas automatiquement le réplica en Microsoft Entra authentification. La réplique conserve l’authentification PostgreSQL. Vous devez configurer manuellement l’authentification Microsoft Entra sur la réplique promue avant ou après le processus de promotion.
  • Haute disponibilité (HAUTE DISPONIBILITÉ) : si vous avez besoin d’une haute disponibilité après la promotion, vous devez la configurer sur le serveur principal fraîchement promu, en suivant 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, les serveurs (principaux et réplicas) doivent être 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.

Pendant ces pannes régionales, vous pouvez implémenter la méthode de promotion forcée, quel que soit l’état actuel du serveur principal. 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

Lorsque vous gérez plusieurs réplicas et que la région principale ne dispose pas d'une région appairée, des précautions particulières sont nécessaires. Si une panne régionale affecte le serveur principal, le réplica nouvellement promu ne reconnaît pas automatiquement les autres réplicas. Même si vous pouvez toujours diriger les applications vers le réplica promu afin d'assurer la continuité du service, les réplicas non reconnus restent déconnectés pendant la panne. Ces réplicas supplémentaires se réassocient et ne reprennent leurs rôles qu’une fois la région primaire d’origine restaurée.

Restauration à un instant dans le passé pendant la promotion

Dans les scénarios de promotion planifiée et forcée, les dernières sauvegardes automatisées doivent être disponibles pour s’assurer que les opérations de restauration dans le temps (PITR) réussissent. Un problème connu peut entraîner l'erreur suivante lors d'une opération PITR après des opérations de basculement et de rétablissement. La résolution de ce problème est prévue dans une version à venir. Pour garantir la réussite des opérations PITR jusqu'au dernier instant disponible, attendez la fin de la sauvegarde automatique 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 principal avec HA activée et un réplica en lecture, que je promeus le réplica puis que je rebascule vers le serveur principal d'origine, le serveur est-il toujours en HA ?

    Non. Le processus de promotion désactive la HA, car Azure Database pour PostgreSQL ne prend pas en charge les réplicas en lecture avec HA activée. Promouvoir un réplica en lecture en serveur principal signifie que le serveur principal 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

  • Last updated on