Utilisation de répliques de lecture pour Amazon RDS pour Postgre SQL - Amazon Relational Database Service
Décodage logique sur une réplique lueLisez les limites des répliques avec Postgre SQLLire la configuration de la réplique avec Postgre SQLUtilisation de réplicas en lecture en cascadeCréation de répliques de lecture en cascade entre régionsComment fonctionne la réplication RDS pour différentes versions de Postgre SQLSurveillance et réglage du processus de réplicationRésolution des problèmes liés à RDS la réplication de SQL lecture de Postgre

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de répliques de lecture pour Amazon RDS pour Postgre SQL

Vous pouvez dimensionner les lectures pour vos SQL instances de base de données Amazon RDS for Postgre en ajoutant des répliques de lecture aux instances. Comme RDS pour les autres moteurs RDS de base de données Amazon, Postgre SQL utilise les mécanismes de réplication natifs de Postgre SQL pour maintenir les répliques de lecture à jour en fonction des modifications apportées à la base de données source. Pour des informations générales sur Read Replicas et AmazonRDS, consultezUtilisation des réplicas en lecture d'instance de base de données.

Vous trouverez ci-dessous des informations spécifiques à l'utilisation des répliques de lecture avec RDS SQL Postgre.

Décodage logique sur une réplique lue

RDSfor Postgre SQL prend en charge la réplication logique à partir de systèmes de secours avec Postgre16.1. SQL Cela vous permet de créer un décodage logique à partir d'un mode veille en lecture seule qui réduit la charge sur l'instance de base de données principale. Vous pouvez améliorer la disponibilité de vos applications qui doivent synchroniser les données entre plusieurs systèmes. Cette fonctionnalité améliore les performances de votre entrepôt de données et de vos analyses de données.

De plus, les emplacements de réplication d'un serveur de secours donné permettent de continuer à transformer ce serveur de secours en serveur principal. Cela signifie qu'en cas de basculement d'une instance de base de données principale ou de promotion d'une instance de secours en tant que nouvelle instance principale, les emplacements de réplication seront conservés et les anciens abonnés de secours ne seront pas affectés.

Pour créer un décodage logique sur une réplique lue

  1. Activer la réplication logique : pour créer un décodage logique en mode veille, vous devez activer la réplication logique sur votre instance de base de données source et sa réplique physique. Pour de plus amples informations, veuillez consulter Lire la configuration de la réplique avec Postgre SQL.

    • Pour activer la réplication logique pour une SQL instance de base de données nouvellement créée RDS pour Postgre, créez un nouveau groupe de paramètres personnalisés de base de données et définissez le paramètre rds.logical_replication statique sur. 1 Associez ensuite ce groupe de paramètres de base de données à l'instance de base de données source et à sa réplique de lecture physique. Pour de plus amples informations, veuillez consulter Associer un groupe de paramètres de base de données à une instance de base de données dans RDSAmazon.

    • Pour activer la réplication logique pour une SQL instance de base de données existante RDS pour Postgre, modifiez le groupe de paramètres personnalisés de base de données de l'instance de base de données source et sa réplique de lecture physique pour définir le paramètre statique rds.logical_replication sur1. Pour de plus amples informations, veuillez consulter Modification des paramètres d'un groupe de paramètres de base de données dans Amazon RDS.

    Note

    Vous devez redémarrer l'instance de base de données pour appliquer ces modifications de paramètres.

    Vous pouvez utiliser la requête suivante pour vérifier les valeurs pour wal_level et rds.logical_replication sur l'instance de base de données source et sa réplique de lecture physique.

    Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
            
 name                    | setting 
-------------------------+---------
 rds.logical_replication | on
 wal_level               | logical
(2 rows)

  2. Créez une table dans la base de données source : connectez-vous à la base de données dans votre instance de base de données source. Pour de plus amples informations, veuillez consulter Connexion à une instance de base de données exécutant le moteur de base de SQL données Postgre.

    Utilisez les requêtes suivantes pour créer une table dans votre base de données source et pour insérer des valeurs : 

    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
    Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000

  3. Créer une publication pour la table source : utilisez la requête suivante pour créer une publication pour la table sur l'instance de base de données source.

    Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION

    Utilisez une SELECT requête pour vérifier les détails de la publication créée à la fois sur l'instance de base de données source et sur l'instance physique de réplication en lecture.

    Postgres=>SELECT * from pg_publication;
             
oid    | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
 16429 | testpub |    16413 | f            | t         | t         | t         | t           | f
(1 row)

  4. Créer un abonnement à partir d'une instance de réplique logique : créez-en une autre RDS pour l'instance de SQL base de données Postgre en tant qu'instance de réplique logique. Assurez-vous qu'elle VPC est correctement configurée pour que cette instance de réplique logique puisse accéder à l'instance de réplique physique en lecture. Pour de plus amples informations, veuillez consulter Amazon VPC et Amazon RDS. Si votre instance de base de données source est inactive, des problèmes de connectivité peuvent survenir et le serveur principal n'envoie pas les données en veille.

    Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port 
                dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE:  created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE

    Utilisez une SELECT requête pour vérifier les détails de l'abonnement sur l'instance de réplique logique.

    Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
            
oid    | subname | subenabled | subslotname | subpublications 
-------+---------+------------+-------------+-----------------
 16429 | testsub | t          | testsub     | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
 count 
-------
 10000
(1 row)

  5. Inspectez l'état du slot de réplication logique : vous ne pouvez voir que le slot de réplication physique sur votre instance de base de données source.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name                                    | slot_type | confirmed_flush_lsn 
---------------------------------------------+-----------+---------------------
 rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical  | 
(1 row)

    Toutefois, sur votre instance de réplication en lecture, vous pouvez voir le slot de réplication logique et la confirmed_flush_lsn valeur changer au fur et à mesure que l'application consomme activement des modifications logiques.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/500002F0
(1 row)
    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/5413F5C0
(1 row)

Lisez les limites des répliques avec Postgre SQL

Les limites des répliques de SQL lecture Postgre sont les suivantes :

Note

Une réplique en lecture RDS pour les instances de base de données Postgre SQL multi-AZ et mono-AZ exécutant Postgre SQL version 12 et antérieures, redémarre automatiquement pour appliquer la rotation des mots de passe pendant la période de maintenance de 60 à 90 jours. Si la connexion entre la réplique et la source est interrompue avant le redémarrage planifié, l'instance sera tout de même redémarrée pour que la réplication reprenne.

  • Les répliques en SQL lecture Postgre sont en lecture seule. Bien qu'une réplique en lecture ne soit pas une instance de base de données inscriptible, vous pouvez la promouvoir pour en faire une instance de base de données autonome RDS pour PostgreSQL. Toutefois, le processus n'est pas réversible.

  • Vous ne pouvez pas créer une réplique de lecture à partir d'une autre réplique de lecture si votre SQL instance de base de données RDS pour Postgre exécute une version de Postgre antérieure à SQL la version 14.1. RDSfor Postgre SQL prend en charge les répliques de lecture en cascade uniquement RDS pour les SQL versions 14.1 et supérieures de Postgre. Pour de plus amples informations, veuillez consulter Utilisation de répliques de lecture en cascade avec for Postgre RDS SQL.

  • Si vous promouvez une réplique en SQL lecture Postgre, elle devient une instance de base de données inscriptible. Elle cesse de recevoir les fichiers log (WAL) en écriture anticipée d'une instance de base de données source et n'est plus une instance en lecture seule. Vous pouvez créer de nouvelles répliques de lecture à partir de l'instance de base de données promue comme vous le faites RDS pour n'importe quelle instance de SQL base de données Postgre. Pour de plus amples informations, veuillez consulter Promotion d'un réplica en lecture en instance de bases de données autonome.

  • Si vous promouvez une réplique de SQL lecture Postgre depuis une chaîne de réplication (une série de répliques de lecture en cascade), toutes les répliques de lecture en aval existantes continuent de recevoir automatiquement WAL les fichiers de l'instance promue. Pour de plus amples informations, veuillez consulter Utilisation de répliques de lecture en cascade avec for Postgre RDS SQL.

  • Si aucune transaction utilisateur n'est en cours d'exécution sur l'instance de base de données source, la réplique de SQL lecture Postgre associée signale un délai de réplication pouvant aller jusqu'à cinq minutes. Le décalage de réplication est calculé comme currentTime - lastCommitedTransactionTimestamp suit : lorsqu'aucune transaction n'est traitée, la valeur du décalage de réplication augmente pendant un certain temps jusqu'à ce que le segment write-ahead log (WAL) change. RDSPar défaut, Postgre SQL change de WAL segment toutes les 5 minutes, ce qui se traduit par un enregistrement de transaction et une diminution du décalage signalé.

  • Vous ne pouvez pas activer les sauvegardes automatiques pour les répliques de SQL lecture Postgre RDS pour les SQL versions de Postgre antérieures à 14.1. Les sauvegardes automatisées pour les répliques en lecture ne sont prises en charge que RDS pour Postgre SQL 14.1 et les versions supérieures. RDSPour Postgre SQL 13 et les versions antérieures, créez un instantané à partir d'une réplique en lecture si vous souhaitez en faire une sauvegarde.

  • Point-in-time recovery (PITR) n'est pas pris en charge pour les répliques en lecture. Vous ne pouvez l'utiliser qu'PITRavec une instance principale (d'écriture), et non avec une réplique en lecture. Pour en savoir plus, consultez Restauration d'une instance de base de données à une heure spécifiée pour Amazon RDS.

Lire la configuration de la réplique avec Postgre SQL

RDSfor Postgre SQL utilise la réplication de streaming SQL native de Postgre pour créer une copie en lecture seule d'une instance de base de données source. Cette instance de base de données de réplica en lecture est un réplica physique créé de façon asynchrone de l'instance de base de données source. Il est créé par une connexion spéciale qui transmet les données write ahead log (WAL) de l'instance de base de données source à la réplique en lecture. Pour plus d'informations, consultez Streaming Replication dans la SQL documentation Postgre.

Postgre diffuse de SQL manière asynchrone les modifications de base de données sur cette connexion sécurisée au fur et à mesure qu'elles sont effectuées sur l'instance de base de données source. Vous pouvez chiffrer les communications entre vos applications clientes et l'instance de base de données source ou tout autre réplica en lecture en définissant le paramètre ssl sur 1. Pour plus d'informations, consultez Utilisation SSL avec une instance de SQL base de données Postgre.

Postgre SQL utilise un rôle de réplication pour effectuer une réplication en continu. Ce rôle dispose de privilèges, mais vous ne pouvez pas l'utiliser pour modifier des données. Postgre SQL utilise un processus unique pour gérer la réplication.

Vous pouvez créer une réplique de SQL lecture Postgre sans affecter les opérations ou les utilisateurs de l'instance de base de données source. Amazon RDS définit les paramètres et les autorisations nécessaires pour vous, sur l'instance de base de données source et sur la réplique en lecture, sans affecter le service. Un instantané de l'instance de base de données source est pris, et est utilisé pour créer le réplica en lecture. Si vous supprimez le réplica en lecture à un moment donné dans le futur, aucune panne ne se produit.

Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données source au sein de la même région. À partir RDS de Postgre SQL 14.1, vous pouvez également créer jusqu'à trois niveaux de réplication de lecture dans une chaîne (cascade) à partir d'une instance de base de données source. Pour de plus amples informations, veuillez consulter Utilisation de répliques de lecture en cascade avec for Postgre RDS SQL. Dans tous les cas, les sauvegardes automatisées doivent être configurées sur l'instance de base de données source. Pour cela, vous devez définir la période de conservation des sauvegardes sur votre instance de base de données sur une valeur autre que 0. Pour de plus amples informations, veuillez consulter Création d'un réplica en lecture.

Vous pouvez créer des répliques de lecture RDS pour votre instance de base de données Postgre de la même manière Région AWS que pour votre SQL instance de base de données source. Cette procédure se nomme « réplication dans la région ». Vous pouvez également créer des répliques de lecture dans une instance différente Régions AWS de celle de la base de données source. Cette procédure se nomme « réplication entre régions ». Pour plus d'informations sur la configuration des réplicas en lecture entre régions, veuillez consulter Création d'une réplique de lecture dans un autre Région AWS. Les différents mécanismes prenant en charge le processus de réplication pour les versions intra-régionales et interrégionales diffèrent légèrement selon la SQL version RDS de Postgre, comme expliqué dans. Comment fonctionne la réplication en streaming RDS pour différentes versions de Postgre SQL

Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, veillez à le faire également pour les réplicas en lecture.

Amazon RDS annule tous les paramètres incompatibles d'une réplique en lecture s'ils empêchent le démarrage de la réplique en lecture. Par exemple, supposons que la valeur du paramètre max_connections est supérieure dans l'instance de base de données source à celle du réplica en lecture. Dans ce cas, Amazon RDS met à jour le paramètre de la réplique lue pour qu'il soit identique à celui de l'instance de base de données source.

RDSpour Postgre SQL read, les répliques ont accès à des bases de données externes disponibles via des wrappers de données étrangers (FDWs) sur l'instance de base de données source. Supposons, par exemple, que votre SQL instance de base de données RDS for Postgre utilise le mysql_fdw wrapper pour accéder aux données de RDS for My. SQL Si tel est le cas, vos réplicas en lecture peuvent également accéder à ces données. Les autres supports pris en charge FDWs incluent oracle_fdwpostgres_fdw, ettds_fdw. Pour de plus amples informations, veuillez consulter Utilisation des wrappers de données étrangers pris en charge pour SQL.

Utilisation RDS pour les répliques de SQL lecture Postgre avec des configurations multi-AZ

Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou Multi-AZ. Vous pouvez utiliser des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, avec un réplica de secours. Un réplica de secours est un réplica en lecture dédié qui peut assumer la charge de travail en cas de défaillance de la base de données source. Vous ne pouvez pas utiliser votre réplica de secours pour traiter le trafic en lecture. Vous pouvez toutefois créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Pour plus d'informations sur les déploiements Multi-AZ, veuillez consulter Déploiements d'instances de base de données multi-AZ pour Amazon RDS.

Si l'instance de base de données source d'un déploiement multi-AZ bascule vers une instance de secours, les réplicas en lecture associés se mettent automatiquement à utiliser l'instance de secours (désormais principale) comme source de réplication. Les répliques de lecture devront peut-être redémarrer, selon la SQL version RDS de Postgre, comme suit :

  • Postgre SQL 13 et versions supérieures : le redémarrage n'est pas nécessaire. Les réplicas en lecture sont automatiquement synchronisés avec la nouvelle instance principale. Toutefois, dans certains cas, votre application cliente peut mettre en cache les détails du Domain Name Service (DNS) pour vos répliques de lecture. Si tel est le cas, définissez la valeur time-to-live (TTL) sur moins de 30 secondes. Cela empêche le réplica en lecture de conserver une adresse IP obsolète (et l'empêche ainsi de se synchroniser avec la nouvelle instance principale). Pour en savoir plus et pour obtenir d'autres bonnes pratiques, consultez Directives opérationnelles RDS de base d'Amazon.

  • Postgre SQL 12 et toutes les versions antérieures : les répliques de lecture redémarrent automatiquement après un basculement vers la réplique de secours, car la réplique de secours (désormais principale) possède une adresse IP et un nom d'instance différents. Le redémarrage synchronise le réplica en lecture avec la nouvelle instance principale.

Pour en savoir plus sur le basculement, consultez Défaillance d'une instance de base de données multi-AZ pour Amazon RDS. Pour plus d'informations sur le fonctionnement des réplicas en lecture dans un déploiement multi-AZ, veuillez consulter Utilisation des réplicas en lecture d'instance de base de données.

Pour prendre en charge le basculement d'une réplique en lecture, vous pouvez créer la réplique en lecture en tant qu'instance de base de données multi-AZ afin qu'Amazon RDS crée une instance de sauvegarde de votre réplique dans une autre zone de disponibilité (AZ). La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.

Utilisation de répliques de lecture en cascade avec for Postgre RDS SQL

Depuis la version 14.1, Postgre SQL supporte RDS les répliques de lecture en cascade. Avec les répliques de lecture en cascade, vous pouvez redimensionner les lectures sans surcharger votre source RDS pour l'instance de base de données SQL Postgre. Les mises à jour du WAL journal ne sont pas envoyées par l'instance de base de données source à chaque réplique lue. Au lieu de cela, chaque réplique de lecture d'une série en cascade envoie des mises à jour du WAL journal à la réplique de lecture suivante de la série. Cela réduit la charge pesant sur l'instance de base de données source.

Avec les répliques de lecture en cascade, votre SQL instance de base RDS de données Postgre envoie WAL des données à la première réplique de lecture de la chaîne. Cette réplique de lecture envoie ensuite WAL des données à la deuxième réplique de la chaîne, et ainsi de suite. Le résultat final est que toutes les répliques de lecture de la chaîne présentent les mêmes modifications que celles de l'SQLinstance RDS de base de données Postgre, mais sans la surcharge uniquement sur l'instance de base de données source.

Vous pouvez créer une série de trois répliques de lecture au maximum dans une chaîne à partir d'une source RDS pour une instance de SQL base de données Postgre. Supposons, par exemple, que vous disposiez d'une instance de base de données RDS pour Postgre SQL 14.1,. rpg-db-main Vous pouvez effectuer les actions suivantes :

  • À partir de rpg-db-main, créez le premier réplica en lecture de la chaîne, read-replica-1.

  • Ensuite, à partir de read-replica-1, créez le réplica en lecture suivant dans la chaîne, read-replica-2.

  • Enfin, à partir de read-replica-2, créez le troisième réplica en lecture de la chaîne, read-replica-3.

Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour rpg-db-main. Une série complète d'instances, depuis une instance de base de données SQL source RDS pour Postgre jusqu'à la fin d'une série de répliques de lecture en cascade, peut comprendre au maximum quatre instances de base de données.

Pour que les répliques de lecture en cascade fonctionnent, activez les sauvegardes automatiques sur votre RDS for Postgre. SQL Créez d'abord la réplique en lecture, puis activez les sauvegardes automatiques sur l'SQLinstance de base de données RDS pour Postgre. Le processus est le même que pour les autres moteurs de RDS base de données Amazon. Pour de plus amples informations, veuillez consulter Création d'un réplica en lecture.

Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d'une cascade. La promotion d'un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données rpg-db-main vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l'exemple, vous décidez de promouvoir read-replica-2. La chaîne est affectée comme suit :

  • La promotion de read-replica-2 le retire de la chaîne de réplication.

    • Il s'agit désormais d'une instance de base de données en lecture/écriture complète.

    • La réplication continue sur read-replica-3, tout comme avant la promotion.

  • Votre rpg-db-main continue la réplication sur read-replica-1.

Pour plus d'informations sur la promotion des réplicas en lecture, consultez Promotion d'un réplica en lecture en instance de bases de données autonome.

Note

Pour les répliques de lecture en cascade, RDS Postgre SQL prend en charge 15 répliques de lecture pour chaque instance de base de données source au premier niveau de réplication, et 5 répliques de lecture pour chaque instance de base de données source aux deuxième et troisième niveaux de réplication.

Création de répliques de lecture en cascade entre régions avec for Postgre RDS SQL

RDScar Postgre SQL prend en charge les répliques de lecture en cascade entre régions. Vous pouvez créer une réplique entre régions à partir de l'instance de base de données source, puis créer des répliques de même région à partir de celle-ci. Vous pouvez également créer une réplique de même région à partir de l'instance de base de données source, puis créer des répliques entre régions à partir de celle-ci.

Créez une réplique entre régions, puis créez des répliques correspondant à la même région

Vous pouvez utiliser une SQL instance RDS de base de données Postgre avec la version 14.1 ou supérieure pour effectuer rpg-db-main les opérations suivantes :

  1. Commencez par rpg-db-main (US- EAST -1), créez la première réplique de lecture interrégionale de la chaîne, read-replica-1 (US- WEST -2).

  2. À l'aide de la première région croisée read-replica-1 (US- WEST -2), créez la deuxième réplique de lecture de la chaîne read-replica-2 (US- WEST -2).

  3. En utilisantread-replica-2, créez la troisième réplique de lecture de la chaîne read-replica-3 (US- WEST -2).

Créez une réplique dans la même région, puis créez des répliques entre régions

Vous pouvez utiliser une SQL instance RDS de base de données Postgre avec la version 14.1 ou supérieure pour effectuer rpg-db-main les opérations suivantes :

  1. En commençant par rpg-db-main (US- EAST -1), créez la première réplique de lecture de la chaîne, read-replica-1 (US- EAST -1).

  2. À l'aide de read-replica-1 (US- EAST -1), créez la première réplique de lecture interrégionale de la chaîne, read-replica-2 (US- WEST -2).

  3. À l'aide de read-replica-2 (US- WEST -2), créez la troisième réplique de lecture de la chaîne, read-replica-3 (US- WEST -2).

Limitations liées à la création de répliques de lecture entre régions

  • Une chaîne en cascade interrégionale de répliques de bases de données peut couvrir au maximum deux régions, avec un maximum de quatre niveaux. Les quatre niveaux incluent la source de base de données et trois répliques de lecture.

Avantages de l'utilisation de répliques de lecture en cascade

  • Évolutivité de lecture améliorée : en répartissant les requêtes de lecture sur plusieurs répliques, la réplication en cascade permet d'équilibrer la charge. Cela améliore les performances, en particulier dans les applications nécessitant beaucoup de lecture, en réduisant la charge de travail de la base de données d'écriture.

  • Distribution géographique — Les répliques en cascade peuvent être situées dans différents emplacements géographiques. Cela réduit le temps de latence pour les utilisateurs éloignés de la base de données principale et fournit une réplique en lecture locale, améliorant ainsi les performances et l'expérience utilisateur.

  • Haute disponibilité et reprise après sinistre : en cas de panne d'un serveur principal, les répliques peuvent être promues au rang de serveur principal, ce qui garantit la continuité. La réplication en cascade améliore encore cela en proposant plusieurs niveaux d'options de basculement, améliorant ainsi la résilience globale du système.

  • Flexibilité et croissance modulaire — À mesure que le système se développe, de nouvelles répliques peuvent être ajoutées à différents niveaux sans reconfiguration majeure de la base de données principale. Cette approche modulaire permet une croissance évolutive et gérable de la configuration de réplication.

Pour plus d'informations sur les avantages de la réplication, consultez À propos de la réplication dans le cloud SQL.

Bonnes pratiques pour l'utilisation de répliques de lecture entre régions

  • Avant de promouvoir une réplique, créez des répliques supplémentaires. Cela permettra de gagner du temps et de gérer efficacement la charge de travail.

Comment fonctionne la réplication en streaming RDS pour différentes versions de Postgre SQL

Comme indiqué dansLire la configuration de la réplique avec Postgre SQL, RDS Postgre SQL utilise le protocole de réplication en streaming natif SQL de Postgre pour envoyer des WAL données depuis l'instance de base de données source. Il envoie WAL des données source pour lire des répliques de lecture à la fois régionales et interrégionales. Avec la version 9.4, Postgre SQL a introduit des emplacements de réplication physiques comme mécanisme de support pour le processus de réplication.

Un slot de réplication physique empêche une instance de base de données source de supprimer WAL des données avant qu'elles ne soient consommées par toutes les répliques en lecture. Chaque réplica en lecture possède son propre emplacement physique sur l'instance de base de données source. L'emplacement assure le suivi de la plus ancienne WAL (par numéro de séquence logiqueLSN) susceptible d'être nécessaire à la réplique. Une fois que tous les slots et connexions à la base de données ont dépassé une WAL valeur donnée (LSN), LSN celle-ci est susceptible d'être supprimée au point de contrôle suivant.

Amazon RDS utilise Amazon S3 pour archiver WAL les données. Pour les réplicas en lecture dans la région, vous pouvez utiliser ces données archivées pour restaurer le réplica en lecture si nécessaire. Par exemple, vous pouvez le faire si la connexion entre la base de données source et le réplica en lecture est interrompue pour quelque raison que ce soit.

Dans le tableau suivant, vous trouverez un résumé des différences entre les versions de Postgre et SQL les mécanismes de support pour les versions intra-régionales et interrégionales utilisés par RDS Postgre. SQL

Version Dans la région Entre régions
Postgre SQL 14.1 et versions supérieures

  • Emplacements de réplication

  • Archive Amazon S3

  • Emplacements de réplication
SQLPostgre13 et versions antérieures

  • Archive Amazon S3

  • Emplacements de réplication

Pour de plus amples informations, veuillez consulter Surveillance et réglage du processus de réplication.

Comprendre les paramètres qui contrôlent la réplication Postgre SQL

Les paramètres suivants affectent le processus de réplication et déterminent dans quelle mesure les réplicas en lecture restent à jour avec l'instance de base de données source :

max_wal_senders

Le paramètre max_wal_senders spécifie le nombre maximal de connexions que l'instance de base de données source peut prendre en charge en même temps via le protocole de réplication en continu. La valeur par défaut RDS pour Postgre SQL 13 et versions supérieures est 20. Ce paramètre doit être défini sur une valeur légèrement supérieure au nombre réel de réplicas en lecture. Si la valeur est trop faible pour le nombre de réplicas en lecture, la réplication s'arrête.

Pour plus d'informations, consultez max_wal_senders dans la documentation Postgre. SQL

wal_keep_segments

Le wal_keep_segments paramètre spécifie le nombre de fichiers log (WAL) à écriture anticipée que l'instance de base de données source conserve dans le pg_wal répertoire. La valeur par défaut est 32.

Si la valeur de wal_keep_segments n'est pas suffisante pour votre déploiement, un réplica en lecture peut prendre un retard tel que la réplication en continu s'arrête. Dans ce cas, Amazon RDS génère une erreur de réplication et commence la restauration sur la réplique lue. Pour ce faire, il rejoue les WAL données archivées de l'instance de base de données source depuis Amazon S3. Ce processus de récupération se poursuit jusqu'à ce que le réplica en lecture ait rattrapé suffisamment de retard pour continuer la réplication en continu. Vous pouvez voir ce processus en action tel qu'il a été capturé par le SQL login Postgre. Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication

Note

Dans Postgre SQL version 13, le wal_keep_segments paramètre est nomméwal_keep_size. Il a le même objectif que wal_keep_segments, mais sa valeur par défaut est exprimée en mégaoctets (Mo) (2 048 Mo) plutôt qu'en nombre de fichiers. Pour plus d'informations, consultez wal_keep_segments et wal_keep_size dans la documentation Postgre. SQL

max_slot_wal_keep_size

Le max_slot_wal_keep_size paramètre contrôle la quantité de WAL données que l'SQLinstance de base de données RDS for Postgre conserve dans le pg_wal répertoire pour servir les emplacements. Ce paramètre est utilisé pour les configurations utilisant des emplacements de réplication. La valeur par défaut de ce paramètre est-1, ce qui signifie qu'il n'y a aucune limite quant à la quantité de WAL données conservée sur l'instance de base de données source. Pour en savoir plus sur la surveillance de vos emplacements de réplication, consultez Surveillance des emplacements de réplication RDS pour votre instance de SQL base de données Postgre.

Pour plus d'informations sur ce paramètre, consultez max_slot_wal_keep_size dans la documentation Postgre. SQL

Chaque fois que le flux qui fournit WAL des données à une réplique en lecture est interrompu, Postgre SQL passe en mode de restauration. Il restaure la réplique lue en utilisant WAL les données archivées depuis Amazon S3 ou en utilisant les WAL données associées au slot de réplication. Lorsque ce processus est terminé, Postgre SQL rétablit la réplication en continu.

Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication

L'exemple suivant fournit les détails du journal qui illustrent le processus de récupération d'un réplica en lecture. L'exemple provient d'une RDS SQL instance de base de données Postgre exécutant Postgre SQL version 12.9 dans la même base de données que la base de données source, de sorte Région AWS que les emplacements de réplication ne sont pas utilisés. Le processus de restauration est le même pour les autres RDS SQL instances de base de données Postgre exécutant Postgre SQL avant la version 14.1 avec des répliques de lecture locales.

Lorsque la réplique en lecture a perdu le contact avec l'instance de base de données source, Amazon RDS enregistre le problème dans le journal sous forme de FATAL: could not receive data from WAL stream message, avec leERROR: requested WAL segment ... has already been removed. Comme le montre la ligne en gras, Amazon RDS récupère la réplique en rejouant un fichier archivéWAL. 

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Lorsqu'Amazon RDS rejoue suffisamment de WAL données archivées sur la réplique pour rattraper le retard, le streaming vers la réplique lue recommence. Lorsque le streaming reprend, Amazon RDS écrit une entrée dans le fichier journal similaire à la suivante.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

Définition des paramètres qui contrôlent la mémoire partagée

Les paramètres que vous définissez déterminent la taille de la mémoire partagée pour le suivi des transactionsIDs, des verrous et des transactions préparées. La structure de mémoire partagée d'une instance de secours doit être égale ou supérieure à celle d'une instance principale. Cela garantit que la première ne viendra pas à manquer de mémoire partagée lors de la récupération. Si les valeurs des paramètres de la réplique sont inférieures aux valeurs des paramètres de la réplique principale, Amazon RDS ajustera automatiquement les paramètres de la réplique et redémarrera le moteur.

Les paramètres concernés sont les suivants :

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Pour éviter le RDS redémarrage des répliques en raison d'un manque de mémoire, nous recommandons d'appliquer les modifications de paramètres sous la forme d'un redémarrage progressif à chaque réplique. Vous devez appliquer les règles suivantes lorsque vous définissez les paramètres :

  • Augmentation des valeurs des paramètres :

    • Vous devez toujours d'abord augmenter les valeurs des paramètres de tous les réplicas lus, puis effectuer un redémarrage progressif de tous les réplicas. Appliquez ensuite les modifications de paramètres sur l'instance principale et redémarrez.

  • Diminution des valeurs des paramètres :

    • Vous devez d'abord diminuer les valeurs des paramètres de l'instance principale, puis effectuer un redémarrage. Appliquez ensuite les modifications des paramètres à tous les réplicas de lecture associés et effectuez un redémarrage progressif.

Surveillance et réglage du processus de réplication

Nous vous recommandons vivement de surveiller régulièrement votre SQL instance de base RDS de données Postgre et de lire les répliques. Vous devez vous assurer que vos réplicas en lecture suivent le rythme des modifications apportées à l'instance de base de données source. Amazon récupère de RDS manière transparente vos répliques lues en cas d'interruption du processus de réplication. Cependant, il est préférable d'éviter toute récupération. La récupération à l'aide d'emplacements de réplication est plus rapide que l'utilisation de l'archive Amazon S3, mais tout processus de récupération peut affecter les performances de lecture.

Pour déterminer dans quelle mesure vos réplicas en lecture suivent le rythme de l'instance de base de données source, vous pouvez effectuer les opérations suivantes :

  • Vérifiez la valeur de ReplicaLag entre l'instance de base de données source et les réplicas. Le retard du réplica correspond au retard en secondes qu'accuse un réplica en lecture par rapport à son instance de base de données source. Cette métrique renvoie le résultat de la requête suivante.

    SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";

    Le délai de réplication indique dans quelle mesure un réplica en lecture suit le rythme de l'instance de base de données source. Il s'agit de la latence entre l'instance de base de données source et une instance de lecture spécifique. Une valeur de délai de réplication élevée peut indiquer une non-correspondance entre les classes d'instance de base de données et/ou les types de stockages utilisés par l'instance de base de données source et ses réplicas en lecture. La classe d'instance de base de données et les types de stockages pour l'instance de base de données source et tous les réplicas en lecture doivent être identiques.

    Le délai de réplication peut également être issu de problèmes de connexion intermittents. Vous pouvez surveiller le délai de réplication sur Amazon CloudWatch en consultant la RDS ReplicaLag métrique Amazon. Pour en savoir plus sur les statistiques d'Amazon ReplicaLag et sur d'autres RDS sujets, consultez CloudWatch Métriques Amazon pour Amazon RDS.

  • Consultez le SQL journal Postgre pour obtenir des informations que vous pouvez utiliser pour ajuster vos paramètres. À chaque point de contrôle, le SQL journal Postgre enregistre le nombre de fichiers journaux de transactions recyclés, comme le montre l'exemple suivant.

    2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s

    Vous pouvez utiliser ces informations pour déterminer le nombre de fichiers de transactions qui sont recyclés au cours d'une période donnée. Vous pouvez ensuite modifier la valeur de wal_keep_segments si nécessaire. Supposons, par exemple, que le SQL journal Postgre s'checkpoint completeaffiche 35 recycled pendant un intervalle de 5 minutes. Dans ce cas, la valeur par défaut de wal_keep_segments (32) n'est pas suffisante pour suivre le rythme de l'activité de streaming. Nous vous recommandons ainsi d'augmenter la valeur de ce paramètre.

  • Utilisez Amazon CloudWatch pour surveiller les indicateurs permettant de prévoir les problèmes de réplication. Plutôt que d'analyser directement le SQL journal Postgre, vous pouvez utiliser Amazon CloudWatch pour vérifier les métriques collectées. Par exemple, vous pouvez vérifier la valeur de la TransactionLogsGeneration métrique pour connaître la quantité de WAL données générée par l'instance de base de données source. Dans certains cas, la charge de travail de votre instance de base de données peut générer une grande quantité de WAL données. Si tel est le cas, vous devrez peut-être modifier la classe de votre instance de base de données source et de vos réplicas en lecture. L'utilisation d'une classe d'instance avec des performances réseau élevées (10 Gbit/s) peut réduire le délai de réplication.

Surveillance des emplacements de réplication RDS pour votre instance de SQL base de données Postgre

Toutes les versions de RDS for Postgre SQL utilisent des emplacements de réplication pour les répliques de lecture entre régions. RDSpour Postgre SQL 14.1 et versions supérieures, utilisez des emplacements de réplication pour les répliques de lecture internes à la région. Les répliques de lecture locales utilisent également Amazon S3 pour archiver WAL les données. En d'autres termes, si votre instance de base de données et vos répliques de lecture exécutent Postgre SQL 14.1 ou une version ultérieure, les emplacements de réplication et les archives Amazon S3 sont tous deux disponibles pour récupérer la réplique en lecture. La récupération d'un réplica en lecture à l'aide de son emplacement de réplication est plus rapide que la récupération à partir d'une archive Amazon S3. Nous vous recommandons donc de surveiller les emplacements de réplication et les métriques associées.

Vous pouvez afficher les emplacements de réplication sur vos SQL instances RDS de base de données Postgre en interrogeant la pg_replication_slots vue, comme suit.

postgres=> SELECT * FROM pg_replication_slots;
slot_name                  | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 |        | physical  |        |          | f         | t      |      13194 |      |              | 23/D8000060 |                     | reserved   |               | f
(1 row)

La reserved valeur wal_status of signifie que la quantité de WAL données détenue par le slot est comprise dans les limites du max_wal_size paramètre. En d'autres termes, la taille de l'emplacement de réplication est correcte. Les autres valeurs de statut possibles sont les suivantes :

  • extended— Le slot dépasse le max_wal_size réglage, mais les WAL données sont conservées.

  • unreserved— Le slot ne contient plus toutes les WAL données requises. Une partie sera supprimée au prochain point de contrôle.

  • lost— Certaines WAL données obligatoires ont été supprimées. L'emplacement n'est plus utilisable.

Les lost états unreserved et ne wal_status sont visibles que lorsqu'ils ne max_slot_wal_keep_size sont pas négatifs.

La vue pg_replication_slots affiche l'état actuel de vos emplacements de réplication. Pour évaluer les performances de vos emplacements de réplication, vous pouvez utiliser Amazon CloudWatch et surveiller les indicateurs suivants :

  • OldestReplicationSlotLag : répertorie l'emplacement qui a le plus de latence, c'est-à-dire celui qui est le plus éloigné du réplica principal. Cette latence peut être associée au réplica en lecture mais également à la connexion.

  • TransactionLogsDiskUsage— Indique la quantité de stockage utilisée pour les WAL données. Lorsqu'un réplica en lecture est significativement en retard, la valeur de cette métrique peut augmenter considérablement.

Pour en savoir plus sur l'utilisation d'Amazon CloudWatch et de ses statistiques RDS pour PostgreSQL, consultezSurveillance des métriques RDS avec Amazon CloudWatch. Pour plus d'informations sur la surveillance de la réplication en streaming sur vos RDS SQL instances de base de données Postgre, consultez les meilleures pratiques pour la SQL réplication Amazon RDS Postgre sur le blog de AWS base de données.

Résolution des problèmes liés à RDS la réplication de SQL lecture de Postgre

Vous trouverez ci-dessous des idées pour résoudre certains problèmes courants liés RDS aux répliques de SQL lecture de Postgre.

Mettre fin à la requête à l'origine du décalage de lecture de la réplique

Les transactions actives ou inactives lorsqu'elles sont exécutées pendant une longue période dans la base de données peuvent interférer avec le processus de WAL réplication, augmentant ainsi le délai de réplication. Veillez donc à surveiller le temps d'exécution de ces transactions avec la SQL pg_stat_activity vue Postgre.

Exécutez une requête similaire à la suivante sur l'instance principale pour trouver l'ID de processus (PID) de la requête exécutée depuis longtemps : 


SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
                        
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,* 
FROM  pg_stat_activity 
WHERE state  = 'idle in transaction'
AND   xact_start is not null
ORDER BY 1 DESC;

Après avoir identifié PID la requête, vous pouvez choisir de terminer la requête.

Exécutez une requête sur l'instance principale similaire à la suivante pour mettre fin à la requête en cours d'exécution depuis longtemps :

SELECT pg_terminate_backend(PID);