Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL - Amazon Relational Database Service
Analyse des paramètres qui contrôlent la réplicationDéfinition des paramètres qui contrôlent la mémoire partagée

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.

Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL

Comme indiqué dans Configuration de réplicas en lecture avec PostgreSQL, RDS pour PostgreSQL utilise le protocole de réplication en continu natif de PostgreSQL pour envoyer des données WAL à partir de l’instance de base de données source. Il envoie les données WAL source aux réplicas en lecture pour les réplicas en lecture dans la région et entre régions. Avec la version 9.4, PostgreSQL a introduit des emplacements de réplication physiques comme mécanisme de prise en charge du processus de réplication.

Un emplacement de réplication physique empêche une instance de base de données source de supprimer les données WAL avant qu'elles ne soient utilisées par tous les réplicas en lecture. Chaque réplica en lecture possède son propre emplacement physique sur l'instance de base de données source. L'emplacement permet de suivre le WAL le plus ancien (par numéro de séquence logique, LSN) qui pourrait être requis par le réplica. Une fois que tous les emplacements et les connexions à la base de données ont dépassé un WAL (LSN) donné, le LSN devient candidat à la suppression au point de contrôle suivant.

Amazon RDS utilise Amazon S3 pour archiver les données WAL. 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.

Le tableau suivant résume les différences entre les versions de PostgreSQL et les mécanismes de prise en charge pour la réplication dans la région et entre régions utilisée par RDS pour PostgreSQL.

Version Dans la région Entre régions
PostgreSQL 14.1 et versions ultérieures

  • Emplacements de réplication

  • Archive Amazon S3

  • Emplacements de réplication
PostgreSQL 13 et versions inférieures

  • Archive Amazon S3

  • Emplacements de réplication

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

Analyse des paramètres qui contrôlent la réplication PostgreSQL

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 varie selon les versions de RDS pour PostgreSQL :

  • Pour les versions 13, 14 et 15, la valeur par défaut est 20.

  • Pour les versions 16 et supérieures, la valeur par défaut est 35.

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

Note

max_wal_senders est un paramètre statique qui nécessite un redémarrage de l’instance de base de données pour que les modifications prennent effet.

wal_keep_segments

Le paramètre wal_keep_segments spécifie le nombre de fichiers WAL (write-ahead log) conservés par l'instance de base de données source dans le répertoire pg_wal. 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 récupération des données sur le réplica en lecture. Pour ce faire, il relit les données WAL archivées de l'instance de base de données source à partir d'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. Pour voir ce processus en action tel qu'il est capturé par le journal PostgreSQL, consultez Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication.

Note

Dans PostgreSQL version 13, le paramètre wal_keep_segments 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 PostgreSQL.

max_slot_wal_keep_size

Le paramètre max_slot_wal_keep_size contrôle la quantité de données WAL conservée par l’instance de base de données RDS pour PostgreSQL dans le répertoire pg_wal pour remplir 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 que la quantité de données WAL conservées sur l'instance de base de données source n'est pas limitée. Pour en savoir plus sur la surveillance de vos emplacements de réplication, consultez Surveillance des emplacements de réplication pour votre instance de base de données RDS pour PostgreSQL.

Pour plus d’informations sur ce paramètre, consultez max_slot_wal_keep_size dans la documentation PostgreSQL.

Chaque fois que le flux qui fournit les données WAL à un réplica en lecture est interrompu, PostgreSQL bascule en mode de récupération. Il restaure le réplica en lecture à l’aide des données WAL archivées d’Amazon S3 ou avec les données WAL associées à l’emplacement de réplication. Une fois ce processus terminé, PostgreSQL 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 instance de base de données RDS pour PostgreSQL exécutant PostgreSQL version 12.9 dans la Région AWS même base de données que la base de données source, de sorte que les emplacements de réplication ne sont pas utilisés. Le processus de récupération est le même pour les autres instances de base de données RDS pour PostgreSQL exécutant des versions de PostgreSQL antérieures à la version 14.1 avec des réplicas en lecture dans la région.

Lorsque le réplica 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 la forme d'un message FATAL: could not receive data from WAL stream, ainsi que ERROR: requested WAL segment ... has already been removed. Comme indiqué sur la ligne en gras, Amazon RDS récupère le réplica en relisant un fichier WAL archivé. 

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 relit un nombre suffisant de données WAL archivées sur le réplica pour qu'il rattrape son retard, le streaming vers le réplica en lecture reprend. Lorsque le streaming reprend, Amazon RDS écrit une entrée dans le fichier journal, semblable à ce qui suit.

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 transactions IDs, 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 sur le réplica sont inférieures aux valeurs des paramètres sur l'instance principale, Amazon RDS ajuste automatiquement les paramètres de réplica et redémarre 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 redémarrage des réplicas par RDS en raison d'un manque de mémoire, nous recommandons d'appliquer les modifications de paramètres à chaque réplica sous la forme d'un redémarrage progressif. 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.