Partager via

Réplicas en lecture dans Azure Database pour PostgreSQL – Serveur flexible

  • Article

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

La fonctionnalité de réplica en lecture vous permet de répliquer les données d’une instance de serveur flexible Azure Database pour PostgreSQL vers un réplica en lecture seule. Les réplicas sont mis à jour de manière asynchrone à l’aide de la technologie de réplication physique native du moteur PostgreSQL. Le streaming de réplication à l’aide des slots de réplication est le mode de fonctionnement par défaut. Quand cela est nécessaire, la copie des journaux de transaction basée sur les fichiers permet de rattraper le retard. Vous pouvez effectuer la réplication à partir du serveur principal vers cinq réplicas au maximum.

Les réplicas sont de nouveaux serveurs que vous gérez de la même manière que les instances de serveur flexibles Azure Database pour PostgreSQL classiques. Pour chaque réplica en lecture, vous êtes facturé en fonction de la capacité de calcul provisionnée dans les vCores et du stockage provisionné en Go/mois.

Découvrez comment créer et gérer des réplicas.

Quand utiliser un réplica en lecture

La fonctionnalité de réplica en lecture contribue à améliorer les performances et la scalabilité des charges de travail nécessitant une lecture intensive. Les charges de travail de lecture peuvent être isolées sur les réplicas, tandis que les charges de travail d’écriture peuvent être dirigées vers le serveur principal. Les réplicas en lecture peuvent également être déployés dans une autre région, et peuvent être promus en tant que serveur en lecture-écriture si une récupération d’urgence est nécessaire.

Un scénario typique est d’avoir les charges de travail décisionnelles et analytiques qui utilisent le réplica en lecture comme source de données pour la création de rapports.

Dans la mesure où les réplicas sont en lecture seule, ils ne réduisent pas directement les charges relatives à la capacité d’écriture sur le serveur principal.

À propos de l’installation

Les réplicas en lecture sont principalement conçus pour des scénarios où les requêtes de déchargement sont bénéfiques et où un léger retard est gérable. Ils sont optimisés pour fournir des mises à jour en quasi-temps réel à partir du serveur principal pour la plupart des charges de travail, ce qui en fait une excellente solution pour les scénarios gourmands en lecture. Toutefois, il est important de noter qu’ils ne sont pas destinés aux scénarios de réplication synchrone nécessitant une exactitude des données à la minute près. Bien que les données sur le réplica deviennent finalement cohérentes avec le serveur principal, il peut y avoir un retard, s’échelonnant généralement de quelques secondes à quelques minutes, qui peut se prolonger pendant des heures dans certains scénarios à latence élevée ou avec une charge de travail intensive. En règle générale, les réplicas en lecture dans la même région que le primaire ont moins de décalage que les géoréplicas, car ces derniers sont souvent confrontés à une latence induite par la distance géographique. Pour plus d’informations sur les implications en matière de performances de la géoréplication, reportez-vous à l’article Géoréplication. Les données du réplica finissent par devenir cohérentes avec les données du serveur principal. Utilisez cette fonctionnalité pour les charges de travail pouvant s’adapter à ce délai.

Remarque

Pour la plupart des charges de travail, les réplicas en lecture offrent des mises à jour en quasi-temps réel à partir du serveur principal. Cependant, avec des charges de travail primaires persistantes, lourdes et à forte intensité d’écriture, le décalage de réplication pourrait continuer à augmenter et pourrait seulement être en mesure de rattraper le primaire. Cela peut également augmenter l’utilisation du stockage sur le primaire, car les fichiers WAL ne sont supprimés qu’une fois qu’ils sont reçus au niveau du réplica. Si cette situation persiste, en supprimant et en recréant le réplica en lecture une fois que les charges de travail à forte intensité d’écriture sont terminées, vous pouvez remettre le réplica dans un bon état pour le décalage. Les réplicas en lecture asynchrone ne conviennent pas à de telles charges de travail d’écriture intensives. Lors de l’évaluation des réplicas en lecture pour votre application, supervisez le décalage sur le réplica pendant un cycle complet de charge de travail de l’application lors de ses heures de pointe et ses heures creuses afin d’évaluer le décalage possible et le RTO/RPO attendu à différents points du cycle de charge de travail.

Créer un réplica

Un serveur principal pour le serveur flexible Azure Database pour PostgreSQL peut être déployé dans n'importe quelle région prenant en charge le service. Vous pouvez créer des réplicas du serveur principal dans la même région ou dans différentes régions Azure mondiales où le serveur flexible Azure Database pour PostgreSQL est disponible. La possibilité de créer des réplicas s’étend désormais à certaines régions Azure spéciales. Consultez l’article Géoréplication pour obtenir une liste des régions spéciales dans lesquelles vous pouvez créer des réplicas.

Lorsque vous démarrez le workflow de création de réplica, une instance de serveur flexible Azure Database pour PostgreSQL vierge est créée. Le nouveau serveur est rempli avec les données sur le serveur primaire. Pour la création de réplicas dans la même région, une approche d’instantané est utilisée. Par conséquent, l’heure de création est indépendante de la taille des données. Les géo-réplicas sont créés à l’aide de la sauvegarde de base de l’instance primaire, qui est ensuite transmise sur le réseau. Par conséquent, l’heure de création peut varier entre quelques minutes et plusieurs heures, en fonction de la taille primaire.

Le réplica est considéré comme étant correctement créé lorsque deux conditions sont remplies : la sauvegarde complète du serveur principal doit être copiée sur le réplica, et les journaux des transactions doivent se synchroniser avec un décalage inférieur à 1 Go.

Pour réussir l’opération de création, évitez de créer des réplicas pendant les périodes de forte charge transactionnelle. Par exemple, vous devez éviter de créer des réplicas lors de migrations à partir d’autres sources vers le serveur flexible Azure Database pour PostgreSQL ou lors d’opérations de chargement en masse intensives. Si vous êtes en train de migrer des données ou de charger de grandes quantités de données, il est préférable de terminer cette tâche en premier. Une fois l’opération terminée, vous pouvez ensuite commencer à configurer les réplicas. Une fois l’opération de migration ou de chargement en bloc terminée, vérifiez que la taille du journal des transactions est revenue à sa taille normale. En règle générale, la taille du journal des transactions doit être proche de la valeur définie dans le paramètre serveur max_wal_size de votre instance. Vous pouvez suivre l’empreinte du stockage du journal des transactions à l’aide de la métrique Stockage des journaux des transactions utilisé qui fournit des informations sur la quantité de stockage utilisée par le journal des transactions. En surveillant cette métrique, vous pouvez vous assurer que la taille du journal des transactions est dans la plage attendue et que le processus de création de réplicas peut être démarré.

Important

Les réplicas en lecture sont actuellement pris en charge pour les niveaux de calcul des serveurs Usage général et Mémoire optimisée. Le niveau de calcul de serveur Burstable n’est pas pris en charge.

Important

Lorsque vous effectuez des opérations de création, de suppression et de promotion de réplicas, le serveur primaire entre dans un état de mise à jour. Pendant ce temps, les opérations de gestion du serveur telles que la modification des paramètres du serveur, la modification des options de haute disponibilité ou l’ajout ou la suppression de pare-feux ne sont pas disponibles. Il est important de noter que l’état de mise à jour affecte uniquement les opérations de gestion du serveur et n’affecte pas les opérations de plan de données. Cela signifie que votre serveur de base de données reste entièrement fonctionnel et capable d’accepter des connexions, ainsi que de gérer un trafic en lecture et en écriture.

Découvrez comment créer un réplica en lecture dans le portail Azure.

Gestion des configurations

Lors de la configuration de réplicas en lecture pour le serveur flexible Azure Database pour PostgreSQL, il est essentiel de comprendre les configurations de serveur qui peuvent être ajustées, celles héritées du serveur principal et toutes les limitations associées.

Configurations héritées

Lorsqu’un réplica en lecture est créé, il hérite des configurations de serveur spécifiques du serveur primaire. Ces configurations peuvent être modifiées lors de la création du réplica ou après sa configuration. Toutefois, les paramètres spécifiques, tels que la géosauvegarde, ne seront pas répliqués sur le réplica en lecture.

Configurations lors de la création de réplica

  • Niveau, taille de stockage : pour l’opération « promouvoir en serveur primaire », ils doivent être identiques à ceux du serveur primaire. Pour l’opération « Promouvoir en serveur indépendant et supprimer de la réplication », elle peut être identique ou supérieure au serveur primaire.
  • Niveau de performance (IOPS) : réglable.
  • Chiffrement des données : ajustable, y compris la transition de clés gérées par le service à des clés gérées par le client.

Configurations après la création

  • Règles de pare-feu : peuvent être ajoutées, supprimées ou modifiées.
  • Niveau, taille de stockage : pour l’opération « promouvoir en serveur primaire », ils doivent être identiques à ceux du serveur primaire. Pour l’opération « Promouvoir en serveur indépendant et supprimer de la réplication », elle peut être identique ou supérieure au serveur primaire.
  • Niveau de performance (IOPS) : réglable.
  • Méthode d’authentification : ajustable, les options incluent le passage de l’authentification PostgreSQL à Microsoft Entra.
  • Paramètres du serveur : la plupart sont réglables. Toutefois, ceux affectant la taille de la mémoire partagée doivent s’aligner sur le primaire, en particulier pour les scénarios potentiels de « promotion en serveur primaire ». Pour l’opération « Promouvoir en serveur indépendant et supprimer de la réplication », ces paramètres doivent être identiques ou supérieurs à ceux sur le primaire.
  • Planification de maintenance : réglable.

Fonctionnalités non prises en charge sur les réplicas en lecture

Certaines fonctionnalités sont limitées aux serveurs primaires et ne peuvent pas être configurées sur des réplicas en lecture. Il s’agit notamment des paramètres suivants :

  • Sauvegardes, y compris les géosauvegardes.
  • Haute disponibilité (HA)

Si votre instance de serveur flexible Azure Database pour PostgreSQL source est chiffrée avec des clés gérées par le client, consultez la documentation pour découvrir d’autres considérations.

Se connecter à un réplica

Lorsque vous créez un réplica, il hérite des règles de pare-feu ou du point de terminaison de service de réseau virtuel du serveur primaire. Ces règles peuvent être modifiées lors de la création de réplica et à tout moment ultérieur.

Le réplica hérite du compte Administrateur du serveur principal. Tous les comptes d’utilisateur sur le serveur principal sont répliqués sur les réplicas en lecture. Vous pouvez uniquement vous connecter à un réplica en lecture à l’aide des comptes d’utilisateur disponibles sur le serveur primaire.

Il existe deux méthodes pour se connecter au réplica :

  • Directement vers l'instance de réplication : Vous pouvez vous connecter au réplica à l’aide de son nom d’hôte et d’un compte d’utilisateur valide, comme vous le feriez sur une instance de serveur flexible Azure Database pour PostgreSQL standard. Sur un serveur nommé myreplica, à l’aide du nom d’utilisateur administrateur myadmin, vous pouvez vous connecter au réplica via psql :
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

À l’invite, entrez le mot de passe du compte d’utilisateur.

D’autre part, pour faciliter le processus de connexion, le portail Azure fournit des chaînes de connexion prêtes à l’emploi. Vous trouverez ces informations dans la page Se connecter. Elles comprennent les deux variables libpq et les chaînes de connexion adaptées aux consoles bash.

  • Via des points de terminaison virtuels : il existe une autre méthode de connexion à l’aide de points de terminaison virtuels, détaillée dans l’article Points de terminaison virtuels. En utilisant des points de terminaison virtuels, vous pouvez configurer le point de terminaison en lecture seule pour qu’il pointe systématiquement vers le réplica, quel que soit le serveur qui détient actuellement le rôle de réplica.

Superviser la réplication

La fonctionnalité de réplica en lecture dans le serveur flexible Azure Database pour PostgreSQL repose sur le mécanisme des emplacements de réplication. Le principal avantage des emplacements de réplication est qu’ils ajustent automatiquement le nombre de journaux de transactions (segments WAL) requis par tous les serveurs de réplicas. Cela permet d’empêcher que les réplicas soient désynchronisés, car cela évite de supprimer des segments WAL sur le serveur principal avant qu’ils soient envoyés aux réplicas. L’inconvénient de cette approche est le risque de manquer d’espace sur le serveur primaire au cas où l’emplacement de réplication reste inactif pendant une période prolongée. Dans de telles situations, le serveur primaire accumule les fichiers WAL, ce qui entraîne une croissance incrémentielle de l’utilisation du stockage. Quand l’utilisation du stockage atteint 95 % ou quand la capacité disponible est inférieure à 5 Gio, le serveur passe automatiquement en mode Lecture seule pour éviter les erreurs associées à la saturation des disques.
Par conséquent, la surveillance du décalage de réplication et de l’état des emplacements de réplication est essentielle pour les réplicas en lecture.

Nous vous recommandons de définir des règles d’alerte pour le stockage utilisé ou le pourcentage de stockage, ainsi que pour les décalages de réplication lorsqu’ils dépassent certains seuils afin que vous puissiez agir de manière proactive, augmenter la taille du stockage et supprimer les réplicas en lecture en retard. Par exemple, vous pouvez définir une alerte si le pourcentage de stockage dépasse 80 % d'utilisation et si le délai de réplication est supérieur à 5 minutes. La métrique Stockage des journaux des transactions utilisé vous indique si l’accumulation de fichiers WAL est la principale raison de l’utilisation excessive du stockage.

Le serveur flexible Azure Database pour PostgreSQL fournit deux métriques pour surveiller la réplication. Les deux paramètres sont Retard de réplication physique maximal et Retard de réplica en lecture. Pour savoir comment afficher ces métriques, consultez la section Superviser un réplica section Créer et gérer des réplicas en lecture dans Azure Database pour PostgreSQL - serveur unique à partir du Portail Azure.

La métrique Retard de réplication physique maximal indique le retard en octets entre le serveur principal et le réplica le plus en retard. Cette mesure est applicable et disponible uniquement sur le serveur principal et sera disponible uniquement si au moins l’un des réplicas en lecture est connecté au serveur principal. Les informations de retard sont également présentes lorsque le réplica rattrape le réplica principal, lors de la création du réplica ou lorsque la réplication devient inactive.

La métrique Retard du réplica en lecture indique le temps écoulé depuis la dernière transaction réexécutée. Par exemple, si aucune transaction ne se produit sur votre serveur primaire et que la dernière transaction a été relue il y a 5 secondes, le décalage du réplica en lecture affiche un retard de 5 secondes. Cette métrique est applicable et disponible pour les réplicas uniquement.

Définissez une alerte qui vous informe quand le décalage du réplica atteint une valeur inacceptable pour votre charge de travail.

Pour plus d’informations, interrogez directement le serveur principal pour connaître le délai de réplication sur tous les réplicas.

Remarque

Si un serveur principal ou un réplica en lecture redémarre, le temps nécessaire pour redémarrer et rattraper le temps perdu est reflété par la métrique Retard du réplica.

État de la réplication

Pour surveiller la progression et l’état de la réplication et promouvoir l’opération, reportez-vous à la colonne État de la réplication dans le portail Azure. Cette colonne se trouve dans la page de réplication et affiche différents états qui fournissent des insights sur la condition actuelle des réplicas en lecture et leur lien vers le primaire. Pour les utilisateurs qui s’appuient sur l’API Azure Resource Manager, lors de l’appel de l’API GetReplica, l’état apparaît comme ReplicationState dans le jeu de propriétés replica.

Les valeurs possibles sont les suivantes :

État de la réplication Description Ordre de promotion Ordre de création de réplica en lecture
Reconfiguration En attente du démarrage du lien réplica-primaire. Il peut rester plus longtemps si le réplica ou sa région n’est pas disponible, par exemple en raison d’un sinistre. 1 N/A
Approvisionnement Le réplica en lecture est en cours d’approvisionnement et la réplication entre les deux serveurs n’a pas encore démarré. Tant que l’approvisionnement n’est pas terminé, vous ne pouvez pas vous connecter au réplica en lecture. N/A 1
Mise à jour La configuration du serveur est en cours de préparation après une action déclenchée telle qu’une promotion ou la création d’un réplica en lecture. 2 2
Rattrapage Les fichiers WAL sont appliqués sur le réplica. La durée de cette phase pendant la promotion dépend de l’option de synchronisation des données choisie (planifiée ou forcée). 3 3
Actif État sain, indiquant que le réplica en lecture a été correctement connecté au primaire. Si les serveurs sont arrêtés, mais qu’ils ont été connectés avec succès auparavant, le statut reste actif. 4 4
Arrêté État non sain, indiquant que l’opération de promotion peut avoir échoué ou que le réplica ne peut pas se connecter au primaire pour une raison quelconque. Veuillez supprimer le réplica et recréez le réplica pour résoudre ce problème. » N/A N/A

Découvrez comment surveiller la réplication.

À propos de l’installation

Cette section résume les considérations relatives à la fonctionnalité de réplica en lecture. Les considérations suivantes s’appliquent.

  • Opérations d’alimentation : les opérations d’alimentation, y compris les actions de démarrage et d’arrêt, peuvent être appliquées aux serveurs primaires et réplicas. Toutefois, pour préserver l’intégrité du système, une séquence spécifique doit être suivie. Avant d’arrêter les réplicas en lecture, vérifiez à ce que le serveur primaire soit arrêté en premier. Lors du démarrage des opérations, lancez l’action de démarrage sur les serveurs réplica avant de démarrer le serveur principal.
  • Si le serveur a des réplicas en lecture, ceux-ci doivent être supprimés avant le serveur principal.
  • La mise à niveau de version majeure sur place dans le serveur flexible Azure Database pour PostgreSQL nécessite la suppression de tous les réplicas en lecture actuellement activés sur le serveur. Après suppression des réplicas, le serveur principal peut être mis à niveau vers la version principale souhaitée. Une fois la mise à niveau terminée, vous pouvez recréer les réplicas pour reprendre le processus de réplication.
  • SSD Premium v2 : à partir de la version actuelle, si le serveur primaire utilise un disque SSD Premium v2 pour le stockage, la création de réplicas en lecture n’est pas prise en charge.
  • Réinitialiser le mot de passe administrateur : la réinitialisation du mot de passe administrateur sur le serveur réplica n’est actuellement pas prise en charge. En outre, la mise à jour du mot de passe administrateur en parallèle de la promotion de l’opération du réplica dans la même requête n’est également pas prise en charge. Si vous souhaitez effectuer cette opération, vous devez d’abord promouvoir le serveur de réplica, puis mettre à jour séparément le mot de passe sur le serveur récemment promu.

Nouveaux réplicas

Un réplica en lecture est créé en tant que nouvelle instance de serveur flexible Azure Database pour PostgreSQL. Un serveur existant ne peut pas être transformé en réplica. Vous ne pouvez pas créer de réplica d’un autre réplica en lecture, autrement dit, la réplication en cascade n’est pas prise en charge.

Déplacement de ressource

Les utilisateurs peuvent créer des réplicas en lecture dans un autre groupe de ressources que le primaire. Toutefois, le déplacement de réplicas en lecture vers un autre groupe de ressources après leur création n’est pas pris en charge. De plus, le déplacement de réplicas vers un autre abonnement, ainsi que le déplacement du serveur principal qui a des réplicas en lecture vers un autre groupe de ressources ou un autre abonnement, ne sont pas pris en charge.

Croissance automatique de stockage

Lors de la configuration de réplicas en lecture pour une instance de serveur flexible Azure Database pour PostgreSQL, il est essentiel de garantir que le paramètre de croissance automatique du stockage sur les réplicas correspond à celui du serveur principal. La fonctionnalité de croissance automatique du stockage permet d’augmenter automatiquement le stockage de la base de données afin d’éviter de manquer d’espace, ce qui pourrait entraîner des pannes de la base de données. Voici comment gérer efficacement les paramètres de croissance automatique du stockage :

  • Vous pouvez activer la croissance automatique du stockage sur n’importe quel réplica, quel que soit le paramètre du serveur principal.
  • Si la croissance automatique du stockage est activée sur le serveur principal, elle doit également l’être sur les réplicas afin de garantir la cohérence des comportements de mise à l’échelle du stockage.
  • Pour activer la croissance automatique du stockage sur le serveur principal, vous devez d’abord l’activer sur les réplicas. Cet ordre d’opérations est essentiel pour maintenir l’intégrité de la réplication.
  • À l’inverse, si vous souhaitez désactiver la croissance automatique du stockage, commencez par la désactiver sur le serveur principal plutôt que sur les réplicas, afin d’éviter toute complication de réplication.

Sauvegarde et restauration

Lors de la gestion des sauvegardes et des restaurations de votre instance de serveur flexible Azure Database pour PostgreSQL, il est essentiel de garder à l'esprit le rôle actuel et précédent du serveur dans différents scénarios de promotion. Voici les points importants à retenir :

Promouvoir en serveur primaire

  1. Aucune sauvegarde n’est effectuée à partir de réplicas en lecture : les sauvegardes ne sont jamais extraites des serveurs de réplicas en lecture, quel que soit leur rôle passé.

  2. Conservation des sauvegardes passées : si un serveur était une fois un primaire et a des sauvegardes effectuées pendant cette période, ces sauvegardes sont conservées. Elles seront conservées jusqu’à la durée de rétention définie par l’utilisateur.

  3. Restrictions d’opération de restauration : même si des sauvegardes passées existent pour un serveur qui a effectué la transition vers un réplica en lecture, les opérations de restauration sont restreintes. Vous ne pouvez lancer une opération de restauration que lorsque le serveur a été promu vers le rôle primaire.

Pour plus de clarté, voici un tableau illustrant ces points :

Rôle serveur Sauvegarde effectuée Restauration autorisée
Principal Oui Oui
Réplica en lecture No No
Réplica en lecture promu en primaire Oui Oui

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

Tant que le serveur est un réplica en lecture, aucune sauvegarde n’est effectuée. Toutefois, une fois promu en serveur indépendant, le serveur promu et le serveur principal sont l’objet de sauvegardes, et les restaurations sont autorisées sur les deux.

Mise en réseau

Les réplicas en lecture prennent en charge toutes les options de mise en réseau prises en charge par Azure Database pour PostgreSQL - Serveur flexible.

Important

La communication bidirectionnelle entre le serveur principal et les réplicas en lecture est cruciale pour la configuration du serveur flexible Azure Database pour PostgreSQL. Il doit être possible d’envoyer et de recevoir du trafic sur le port de destination 5432 dans le sous-réseau du réseau virtuel Azure.

L’exigence ci-dessus facilite non seulement le processus de synchronisation, mais elle garantit également le bon fonctionnement du mécanisme de promotion où les réplicas peuvent avoir besoin de communiquer dans l’ordre inverse, du réplica au primaire, en particulier lors des opérations de promotion en primaire. De plus, les connexions au compte de stockage Azure qui stocke les archives WAL (Write-Ahead Logging) doivent être autorisées à maintenir la durabilité des données et à activer des processus de récupération efficaces.

Pour plus d’informations sur la configuration de l’accès privé (intégration de réseau virtuel) pour vos réplicas en lecture et pour comprendre les implications de la réplication entre les régions Azure et les réseaux virtuels dans un contexte de réseau privé, consultez la page Réplication entre les régions Azure et les réseaux virtuels avec réseau privé.

Atténuation des problèmes d’emplacement de réplication

Dans de rares cas, un décalage élevé dû aux emplacements de réplication peut entraîner une augmentation de l’utilisation du stockage sur le serveur primaire en raison de l’accumulation de fichiers WAL. Si l’utilisation du stockage atteint 95 % ou si la capacité disponible est inférieure à 5 Gio, le serveur passe automatiquement en mode lecture seule pour éviter les erreurs de remplissage du disque.

Étant donné que la maintenance de l’intégrité et des fonctionnalités du serveur primaire est une priorité, dans de tels cas de périphérie, l’emplacement de réplication peut être supprimé pour garantir que le serveur primaire reste opérationnel pour le trafic de lecture et d’écriture. Ainsi, la réplication passe en mode de copie des journaux de transaction basé sur les fichiers, ce qui peut entraîner un décalage de réplication plus élevé.

Il est essentiel de surveiller de près l’utilisation du stockage et le décalage de réplication, et de prendre les mesures nécessaires pour atténuer les problèmes potentiels avant qu’ils ne s’aggravent.

Paramètres de serveur

Lorsqu’un réplica en lecture est créé, il hérite des paramètres du serveur primaire. Cette opération permet de garantir un point de départ cohérent et fiable. Toutefois, les modifications apportées aux paramètres du serveur primaire après la création du réplica en lecture ne sont pas automatiquement répliquées. Ce comportement offre l’avantage d’un réglage individuel du réplica en lecture, comme l’amélioration de ses performances pour les opérations de lecture intensive sans modifier les paramètres du serveur primaire. Bien que ce comportement offre une certaine flexibilité et des options de personnalisation, il nécessite également une gestion minutieuse et manuelle pour maintenir la cohérence entre le serveur primaire et son réplica lorsque l'uniformité des paramètres du serveur est requise.

Les administrateurs peuvent modifier les paramètres du serveur sur le serveur de réplica en lecture et définir des valeurs différentes de celles du serveur primaire. La seule exception concerne les paramètres susceptibles d’affecter la récupération du réplica, mentionnés également dans la section « Mise à l’échelle » ci-dessous : max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. Pour garantir que la récupération du réplica en lecture s’effectue sans heurt et qu’elle ne rencontre pas de limites de mémoire partagée, ces paramètres particuliers doivent toujours être définis à des valeurs équivalentes ou supérieures à celles configurées sur le serveur primaire.

Scale

Vous êtes libre d’effectuer un scale-up ou scale down du calcul (cœurs virtuels), de changer le niveau de service de Usage général à Mémoire optimisée (ou inversement) et de mettre à l’échelle le stockage, mais les mises en garde suivantes s’appliquent.

Pour une mise à l’échelle du calcul :

  • Le serveur flexible Azure Database pour PostgreSQL nécessite que plusieurs paramètres sur les réplicas soient supérieurs ou égaux au paramètre sur le réplica principal pour garantir que le réplica ne manque pas de mémoire partagée lors de la récupération. Les paramètres affectés sont : max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

  • Scale-up : Effectuez tout d’abord un scale-up du calcul d’un réplica, puis du serveur principal.

  • Scale-down : Effectuez tout d’abord un scale-down du calcul du serveur principal, puis du réplica.

  • Le calcul sur le serveur principal doit toujours être égal ou inférieur au calcul sur le réplica le plus petit.

Pour une mise à l’échelle du stockage :

  • Scale-up : effectuez tout d’abord un scale-up du stockage du réplica, puis du serveur principal.

  • La taille de stockage sur le serveur principal doit toujours être égale ou inférieure à la taille de stockage sur le plus petit réplica.

Contenu connexe