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

La fonctionnalité de réplique en lecture vous permet de répliquer des données depuis un serveur flexible Azure Database pour PostgreSQL vers une réplique en lecture seule. Les réplicas sont mis à jour de façon 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 manière similaire à un serveur flexible Azure Database pour PostgreSQL standard. Pour chaque réplique en lecture, vous payez les ressources de calcul provisionnées en vCores ainsi que le stockage en Go, par mois.

Découvrez comment créer un réplica en lecture.

Quand utiliser un réplica en lecture

La fonctionnalité de réplique de lecture permet d’améliorer les performances et la mise à l’échelle des charges de travail à forte intensité de lecture. Vous pouvez isoler les charges de travail de lecture sur les réplicas, tandis que vous dirigez les charges de travail d’écriture vers le serveur principal. Vous pouvez également déployer des réplicas en lecture dans une autre région et les promouvoir vers un serveur en lecture-écriture si la 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.

Considérations

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 quasi en temps réel depuis l’instance principale pour la plupart des charges de travail, ce qui en fait une excellente solution pour les scénarios à forte dominante de 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 en heures dans certains scénarios à latence élevée ou avec une charge de travail intensive. En règle générale, les réplicas de lecture situés dans la même région que l’instance principale présentent moins de retard que les géoréplicas, car ces derniers subissent souvent 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.

Créer une réplique

Vous pouvez déployer un serveur principal pour Azure Database pour PostgreSQL serveur flexible dans n’importe quelle région qui prend en charge le service. Vous pouvez créer des réplicas du serveur principal au sein de la même région ou dans différentes régions de Azure globales où Azure Database pour PostgreSQL est disponible. Vous pouvez également créer des réplicas dans certaines régions d’Azure dans des clouds souverains. Pour obtenir la liste des régions cloud souveraines où vous pouvez créer des réplicas, consultez l’article sur la géoréplication .

Lorsque vous démarrez le workflow de création de réplica, le processus crée un serveur flexible Azure Database pour PostgreSQL vierge. Le nouveau serveur est rempli avec les données sur le serveur primaire. Pour la création de répliques dans la même région, le processus utilise une méthode basée sur des instantanés. Par conséquent, l’heure de création est indépendante de la taille des données. Les géoréplicas sont créés à l’aide de la sauvegarde de base de l’instance primaire, qui est ensuite transmise via le réseau. Par conséquent, le temps de création peut varier de quelques minutes à plusieurs heures, selon la taille initiale.

Un réplica est considéré comme étant correctement créé lorsque deux conditions sont remplies : la sauvegarde complète du réplica principal est copiée sur le réplica et les journaux des transactions se synchronisent sans plus d’un décalage de 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, évitez de créer des réplicas lors de la migration à partir d’autres sources vers un serveur flexible Azure Database pour PostgreSQL ou lors d’opérations de charge en bloc lourdes. Si vous migrez des données ou chargez de grandes quantités de données, terminez d’abord cette tâche. 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 si la taille du journal des transactions est retournée à 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 max_wal_size paramètre de votre serveur. Vous pouvez suivre l’empreinte de stockage du journal des transactions à l’aide de la métrique De stockage du journal des transactions utilisée, qui fournit des insights 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 se trouve dans la plage attendue et que le processus de création du réplica peut démarrer.

Découvrez comment créer un réplica en lecture.

Gestion de la configuration

Lorsque vous configurez des réplicas de lecture pour un serveur flexible Azure Database pour PostgreSQL, vous devez comprendre quelles configurations de serveur vous pouvez ajuster, quelles configurations sont héritées du serveur principal et quelles sont les limitations associées.

Configurations héritées

Lorsque vous créez un réplica en lecture, il hérite de certaines configurations du serveur principal. Vous pouvez modifier ces configurations pendant la création du réplica ou après avoir configuré le réplica. Toutefois, la réplique en lecture n’hérite pas de paramètres spécifiques, comme la sauvegarde géographique, du serveur principal.

Configurations lors de la création de réplica

• Niveau, taille de stockage : pour l’opération de promotion vers le serveur principal , le niveau et la taille de stockage doivent correspondre au serveur principal. Pour l’opération de promotion vers un serveur indépendant et de suppression de la réplication, le niveau de service et la taille de stockage peuvent être identiques à ceux du serveur principal ou supérieurs.
• Niveau de performance (IOPS) : réglable.
• Chiffrement des données : ajustable, y compris le passage 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 : vous pouvez ajouter, supprimer ou modifier des règles.
• Niveau, taille de stockage : pour l’opération de promotion vers le serveur principal , le niveau et la taille de stockage doivent correspondre au serveur principal. Pour l’opération de promotion vers un serveur indépendant et de suppression de la réplication, le niveau de service et la capacité de stockage peuvent être identiques à ceux du serveur principal ou supérieurs.
• Niveau de performance (IOPS) : réglable.
• méthode Authentication : les options réglables incluent le passage de l’authentification PostgreSQL à Microsoft Entra.
• Paramètres : la plupart des paramètres sont réglables. Toutefois, ceux qui affectent la taille de la mémoire partagée doivent être alignés sur le serveur principal, en particulier dans la perspective d’une éventuelle promotion en serveur principal. Pour la promotion vers un serveur indépendant et la suppression de l’opération de réplication, ces paramètres doivent correspondre ou dépasser ceux sur le serveur principal.
• Planification de maintenance : réglable.

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

Les serveurs principaux prennent en charge certaines fonctionnalités que vous ne pouvez pas configurer sur les réplicas en lecture. Ces fonctionnalités sont les suivantes :

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

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

Créer des réplicas de lecture en cascade

Les réplicas de lecture en cascade peuvent aider à distribuer des charges de travail de lecture, ce qui réduit la charge sur le serveur principal. Le déploiement de réplicas en lecture dans différentes régions (réplicas en lecture interrégions) peut aider à distribuer le trafic de lecture plus près des utilisateurs dans différentes zones géographiques. Vous pouvez ajouter des réplicas de lecture en cascade au serveur Azure Database pour PostgreSQL. Cette fonctionnalité vous permet de créer de nouveaux réplicas en lecture à partir d’un réplica en lecture existant, celui-ci servant de source au niveau suivant.

Le réplica en lecture de premier niveau réplique de façon asynchrone les données à partir du serveur principal. Vous pouvez ensuite créer un réplica en lecture de second niveau à l’aide du réplica de premier niveau comme source, formant une hiérarchie de réplication à deux niveaux. Cette architecture améliore l’évolutivité et prend en charge jusqu’à 30 répliques en lecture : le serveur principal peut en prendre en charge jusqu’à cinq, et chacune de ces répliques peut à son tour en prendre en charge cinq supplémentaires. Pour ajouter un réplica en cascade à Azure Database pour PostgreSQL serveur flexible, sélectionnez le réplica en lecture existant (créé à partir du serveur principal), accédez à l’onglet Réplication, puis sélectionnez Créer un réplica.

Par exemple, votre serveur principal peut avoir jusqu’à cinq répliques de lecture (niveau 1). L’un d’entre eux, disons read-replica-1, sert de source à une autre réplique read-replica-2 qui intègre alors le niveau 2.

Considérations importantes

• Vous pouvez créer jusqu’à cinq réplicas en lecture par réplica source en lecture, avec prise en charge de jusqu’à deux niveaux de réplication.
• L’opération de basculement prend en charge les réplicas en lecture intermédiaires (source) et les réplicas en lecture en cascade.
• L’opération de promotion en primaire ne prend pas en charge les réplicas de lecture intermédiaires ayant des réplicas de lecture en cascade.
• Les points de terminaison virtuels ne sont pas pris en charge pour les répliques en cascade.
• Les réplicas en cascade sont pris en charge sur les réplicas intermédiaires avec PostgreSQL version 14 et ultérieure.

Se connecter à une réplique

Lorsque vous créez un réplica, il n’hérite pas des règles de pare-feu ou du point de terminaison de service de réseau virtuel du serveur principal. Vous pouvez définir ces règles lors de la création du réplica et les modifier ultérieurement.

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.

Vous pouvez utiliser deux méthodes pour vous connecter au réplica :

• Direct vers le réplica : 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 un serveur standard Azure Database pour PostgreSQL flexible. 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.

Pour faciliter le processus de connexion, le portail Azure fournit des chaînes de connexion prêtes à l’emploi. Vous trouverez ces chaînes de connexion dans la page Se connecter . Ils incluent à la fois les libpq variables et les chaînes de connexion adaptées aux consoles Bash.

• Via des points de terminaison virtuels : une autre méthode de connexion utilise des points de terminaison virtuels. Pour plus d’informations, consultez 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 toujours vers le réplica, quel que soit le serveur qui contient actuellement le rôle de réplica.

Surveiller la réplication

La fonctionnalité de réplica en lecture dans 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. Cet ajustement permet d’empêcher les réplicas de sortir de la synchronisation, car il évite de supprimer des segments WAL sur le serveur principal avant que les réplicas ne les reçoivent. L’inconvénient de cette approche est le risque d’épuisement de l’espace sur le serveur principal si l’emplacement de réplication reste inactif pendant une période prolongée. Dans de telles situations, le serveur principal accumule les fichiers WAL, ce qui entraîne une augmentation progressive de l’espace de stockage utilisé. Lorsque l’utilisation du stockage atteint 95% ou si la capacité disponible est inférieure à 5 Gio, le serveur bascule automatiquement en mode lecture seule pour éviter les erreurs associées aux situations complètes du disque.
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.

Définissez des règles d’alerte pour le stockage utilisé ou le pourcentage de stockage et, pour les retards de réplication, lorsqu’elles dépassent certains seuils afin que vous puissiez agir de manière proactive, augmenter la taille de 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 Espace de stockage utilisé du journal des transactions vous indique si l’accumulation des fichiers WAL est la principale raison de l’utilisation excessive de l’espace de stockage.

Surveillance des métriques

Azure Database pour PostgreSQL service fournit les métriques suivantes pour la surveillance de la réplication.

Vous pouvez utiliser des métriques améliorées pour surveiller et la réplication en lecture et générer des alertes.

Activation des métriques améliorées

• La plupart de ces nouvelles métriques sont désactivées par défaut. Toutefois, il existe quelques exceptions qui sont activées par défaut. La colonne la plus à droite dans les tableaux suivants indique si chaque métrique est activée par défaut ou non.
• Pour activer les métriques qui ne sont pas activées par défaut, définissez le paramètre metrics.collector_database_activity sur ON. Ce paramètre est dynamique et ne nécessite pas de redémarrage de l’instance.

Réplication logique

Réplication

Pour en savoir plus, consultez l’article de procédures sur les réplicas en lecture.

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 métrique est applicable et disponible uniquement sur le serveur principal et n’est disponible que si au moins 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 n’a lieu sur votre serveur principal et que la dernière transaction a été rejouée il y a 5 secondes, le retard de la réplique de lecture indique 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.

État de la réplication

Pour surveiller la progression et l’état de l’opération de réplication et de promotion, reportez-vous à la colonne 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 conteneur de propriétés replica.

Les valeurs possibles sont les suivantes :

Découvrez comment surveiller la réplication.

Considérations

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 : vous pouvez appliquer des opérations d’alimentation, y compris les actions de démarrage et d’arrêt , aux serveurs principaux et réplicas. Toutefois, pour préserver l’intégrité du système, suivez une séquence spécifique. Avant d’arrêter les réplicas en lecture, vérifiez d’abord que le serveur primaire est arrêté. 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 un serveur a des réplicas en lecture, supprimez d’abord les réplicas en lecture avant de supprimer le serveur principal.
• La mise à niveau majeure sur place d’un serveur flexible Azure Database pour PostgreSQL nécessite la suppression de toutes les répliques en lecture et des répliques en lecture en cascade configurées sur ce serveur. Une fois les réplicas supprimés, vous pouvez mettre à niveau le serveur principal 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.
  • Réinitialisation du 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 et la promotion d’une réplique dans la même requête ne sont pas prises en charge. Si vous souhaitez effectuer ces actions, commencez par promouvoir le serveur réplica, puis mettez à jour le mot de passe sur le serveur nouvellement promu séparément.

Nouveaux réplicas

Vous créez un réplica en lecture en tant que nouveau serveur flexible Azure Database pour PostgreSQL. Vous ne pouvez pas transformer un serveur existant en réplica.

Déplacement de ressource

Vous pouvez créer des réplicas en lecture dans un groupe de ressources différent de celui du serveur principal. 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. En outre, le déplacement de réplicas vers un autre abonnement n’est pas pris en charge. Il n’est pas possible de déplacer la réplique principale comportant des réplicas en lecture vers un autre groupe de ressources ou un autre abonnement.

Croissance automatique du stockage

Lorsque vous configurez des réplicas en lecture pour un serveur flexible Azure Database pour PostgreSQL, assurez-vous que le paramètre de croissance automatique de 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.

Sauvegarder et restaurer

Lorsque vous gérez des sauvegardes et des restaurations pour votre serveur flexible Azure Database pour PostgreSQL, gardez à l’esprit le rôle actuel et précédent du serveur dans différents scénarios de promotion. N’oubliez pas ces points clés :

Promouvoir en serveur primaire

• Aucune sauvegarde de réplicas en lecture : le système n’effectue jamais de sauvegardes à partir de serveurs de réplicas en lecture, quel que soit leur rôle passé.
• Conservation des sauvegardes passées : si un serveur était une fois un serveur principal et que le système a effectué des sauvegardes pendant cette période, il conserve ces sauvegardes jusqu’à la période de rétention définie par l’utilisateur.
• Restrictions d’opération de restauration : même si des sauvegardes passées existent pour un serveur qui passe à 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 est promu vers le rôle principal.

Pour plus de clarté, le tableau suivant illustre ces points :

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

Bien que le serveur soit une réplique en lecture, le système n’effectue pas de sauvegardes. Toutefois, une fois que vous l’avez promu vers un serveur indépendant, le système effectue des sauvegardes pour le serveur promu et le serveur principal. Vous pouvez restaurer des sauvegardes sur les deux serveurs.

Networking

Les réplicas en lecture prennent en charge toutes les options de mise en réseau qui Azure Database pour PostgreSQL serveur flexible prend en charge.

Cette exigence facilite non seulement le processus de synchronisation, mais garantit également le bon fonctionnement du mécanisme de promotion. Les répliques peuvent avoir besoin de communiquer dans l’ordre inverse, de la réplique vers le serveur principal, en particulier lors des opérations de promotion en principal. En outre, vous devez autoriser les connexions au compte de stockage Azure qui stocke les archives de journalisation (WAL) Write-Ahead pour maintenir la durabilité des données et activer des processus de récupération efficaces.

Pour plus d’informations sur la façon de configurer l’accès privé (intégration au réseau virtuel) pour vos réplicas en lecture et de 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 l’article 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.

La maintenance de l’intégrité et des fonctionnalités du serveur principal est une priorité. Dans ce cas de périphérie, le serveur peut supprimer l’emplacement de réplication pour garantir que le serveur principal 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é.

Surveillez de près l’utilisation de l’espace de stockage et le retard de réplication, et prenez les mesures nécessaires pour atténuer les problèmes potentiels avant qu’ils ne s’aggravent.

Parameters

Lorsque vous créez une réplique en lecture, elle hérite des paramètres du serveur principal. Cet héritage garantit un point de départ cohérent et fiable. Toutefois, les modifications que vous effectuez aux paramètres du serveur principal après avoir créé la réplique en lecture ne sont pas répliquées automatiquement. 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 souplesse et des options de personnalisation, il nécessite également une gestion minutieuse et manuelle afin de maintenir la cohérence entre l’instance principale et sa réplique lorsqu’une uniformité des paramètres est requise.

Les administrateurs peuvent modifier les paramètres sur le serveur de réplication en lecture et définir des valeurs différentes de celles du serveur principal. 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 est transparente et qu’elle ne rencontre pas de limitations de mémoire partagée, définissez toujours ces paramètres particuliers sur des valeurs équivalentes ou supérieures à celles configurées sur le serveur principal. Avant de réduire les valeurs des paramètres sur un serveur de réplication en lecture, assurez-vous que le décalage de réplication est minimal ou que la réplication est entièrement synchronisée avec le serveur principal, afin d’éviter les problèmes potentiels de réplication ou de récupération.

Scale

Vous pouvez augmenter ou diminuer la capacité de calcul (vCores), passer du niveau de service Usage général à Mémoire optimisée (ou inversement), et augmenter la capacité de stockage. Toutefois, les avertissements suivants s’appliquent.

Pour une mise à l’échelle du calcul :

• Azure Database pour PostgreSQL nécessite que plusieurs paramètres sur les répliques soient supérieurs ou égaux à ceux du serveur principal pour s'assurer que la réplique ne manque pas de mémoire partagée pendant la récupération. Les paramètres affectés sont les suivants : max_connections, , max_prepared_transactionsmax_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 réplica principal doit toujours être égal ou inférieur au calcul sur le plus petit réplica.

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 réplica principal doit toujours être égale ou inférieure à la taille de stockage sur le plus petit réplica.

Contenu connexe

• Geo-replication dans Azure Database pour PostgreSQL.
• Promouvoir les réplicas en lecture 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.
• Replication entre les régions Azure et les réseaux virtuels avec mise en réseau privée.