Partage via

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

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL - Serveur flexible

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

Important

L’opération de promotion n’est pas automatique. En cas de défaillance d’un serveur primaire, le système ne basculera pas vers le réplica en lecture de manière indépendante. Une action utilisateur est toujours requise pour l’opération de promotion.

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 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.

Diagramme montrant la promotion du fonctionnement 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. 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. Par conséquent, 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 se connecter à celle-ci.

Le diagramme montre la façon dont les serveurs sont configurés avant leur promotion et configuration, après être devenus 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 du serveur : pour qu’une opération de promotion en serveur primaire soit réussie, les serveurs primaires et réplicas doivent avoir des niveaux et des tailles de stockage identiques. Par exemple, si le primaire a 2vCores et que le réplica a 4vCores, la seule option viable consiste à utiliser l’action « Promouvoir en serveur indépendant et supprimer de la réplication ». De plus, ils doivent partager les mêmes valeurs de paramètres de serveur qui allouent de la mémoire partagée.

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 réplica et le serveur primaire indique la quantité de données perdues.

Important

L’option de promotion forcée est spécifiquement conçue pour traiter les pannes régionales et, dans ce cas, elle ignore toutes les vérifications (y compris l’exigence de symétrie du serveur) et procède à la promotion. En effet, elle classe par ordre de priorité la disponibilité immédiate des serveurs pour faire face aux scénarios de catastrophe. Toutefois, l'utilisation de l'option forcée en dehors des scénarios de descente de région n'est pas autorisée si les exigences relatives aux réplicas en lecture spécifiés dans la documentation, en particulier l'exigence de symétrie du serveur, ne sont pas respectées, car cela pourrait entraîner des problèmes tels qu'une réplication interrompue.

Découvrez comment promouvoir un réplica en primaire et promouvoir en serveur indépendant et supprimer de la réplication.

Gestion des configurations

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 est conforme à leurs souhaits.

L’opération de promotion ne reprend pas les paramètres et configurations spécifiques. Voici quelques-uns des 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 primaire, mais pas sur le réplica, il reste désactivé sur le 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 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 du serveur standard (pas d'une réplique).
  • Paramètres du serveur : si leurs valeurs diffèrent sur le serveur primaire et le réplica en lecture, elles ne sont pas modifiées 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 les principaux et les réplicas. Cette exigence est détaillée dans la section Paramètres du 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 HA après la promotion, elle doit être configurée sur le serveur primaire fraîchement promu, après l’inversion du rôle.

À propos de l’installation

États du serveur lors de la promotion

Dans les scénarios de promotion planifiée et forcée, il est nécessaire que les serveurs (primaires et réplicas) soient dans un état « Disponible ». Si l'état d'un serveur n'est pas « Disponible » (comme « En cours de mise à jour » ou « En cours de redémarrage »), la promotion ne peut généralement pas se dérouler 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 contrôles normaux de la disponibilité des serveurs.

Notez que 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

Dans le cas de plusieurs réplicas et si la région primaire n’a pas de région jumelée, une considération particulière doit être prise en compte. En cas de panne régionale affectant le primaire, d’autres réplicas ne seront pas automatiquement reconnus par le réplica nouvellement promu. Bien que les applications puissent toujours ê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.

Forum aux questions

  • Puis-je promouvoir un réplica si mon serveur primaire dispose d’une haute disponibilité (HA) activée ?

    Oui, que votre serveur primaire soit ou non compatible HA, vous pouvez promouvoir son réplica en lecture. La possibilité de promouvoir une réplique en lecture vers un serveur primaire est indépendante de la configuration HA du serveur primaire.

  • Si j’ai un réplica principal avec haute disponibilité et un réplica en lecture et que je promeus le réplica, puis que je reviens au réplica principal d’origine, le serveur sera-t-il toujours en 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 activés avec une haute disponibilité. La promotion d'un réplica en lecture en tant que primaire signifie que le 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