Obtenez des fichiers WAL à partir d'une instance AWS RDS PostgreSQL

Nous avons une instance Postgres RDS sur Amazon Web Services. Nous avons activé les sauvegardes automatiques et nous prenons des instantanés quotidiennement. Nous souhaitons générer une sauvegarde locale «à jour» de l'instance RDS que nous pouvons gérer nous-mêmes. L'exécution de pg_dump sur l'instance n'est pas suffisante car nous voulons pouvoir restaurer la base de données à tout moment. Nous préférerions avoir une sauvegarde locale de RDS et de tous les fichiers WAL depuis cette sauvegarde. Des questions:

1. Est-il possible d'accéder aux fichiers WAL et aux sauvegardes que RDS génère automatiquement dans sa routine de sauvegarde? Ce serait idéal. Je voudrais en télécharger une copie locale. Après enquête initiale, je pense que la réponse à cette question est «non». Il semble que RDS stocke ses fichiers WAL et ses sauvegardes dans S3, mais cela nous les rend inaccessibles. J'aimerais une confirmation.

2. Existe-t-il un autre moyen d'accéder aux transactions (fichiers WAL) qui se sont produites sur l'instance RDS? J'imagine que nous devrions pouvoir créer une base de données Postgres sur un EC2 et «alimenter» les transactions de notre instance RDS «en direct» principale dans cette instance EC2. Une fois notre instance EC2 mise à jour, nous pourrions extraire les fichiers WAL à partir de là. Quel mal de tête cependant: / Cette configuration est-elle possible? Quelle est la magie de «nourrir» notre instance RDS vers l'instance EC2 afin qu'elle soit toujours à jour?

Merci!

Mise à jour: j'ai posté à ce sujet sur les forums AWS - veuillez entrer carillon et demander là-bas .

Au moment de la rédaction, Amazon RDS ne prend pas en charge la réplication physique en dehors de RDS. Vous pouvez utiliser GRANTles REPLICATIONdroits à l'aide d'une rds_superuserconnexion, mais vous ne pouvez pas configurer les replicationentrées pour les adresses IP externes dans pg_hba.conf.

De plus, lorsque vous créez un groupe de paramètres DB dans RDS, certains paramètres clés sont affichés mais verrouillés, par exemple archive_command, qui est verrouillé sur /etc/rds/dbbin/pgscripts/rds_wal_archive %p. AWS RDS pour PostgreSQL ne semble pas exposer ces WAL pour un accès externe (par exemple via S3) comme il le faudrait si vous deviez utiliser la réplication WAL-shipping pour PITR externe.

Donc, à ce stade, si vous voulez Wal-Shipping, n'utilisez pas RDS. Il s'agit d'une base de données en conserve facile à utiliser, mais facile à utiliser signifie souvent qu'elle est également limitée, et c'est certainement le cas ici. Comme Joe Love le fait remarquer dans les commentaires, il fournit l'expédition WAL et le PITR dans RDS , mais vous ne pouvez pas accéder au WAL à partir de l' extérieur RDS.

Vous devez donc utiliser les propres installations de sauvegarde de RDS - les vidages, les instantanés et son propre PITR basé sur WAL.

Même si RDS vous permettait d'établir des connexions de réplication (pour pg_basebackupou pour la réplication en streaming) et vous permettait d'accéder au WAL archivé, vous ne pourriez peut-être pas réellement consommer ce WAL. RDS exécute un PostgreSQL corrigé, bien que personne ne sache à quel point il est fortement corrigé ou s'il modifie considérablement le format sur disque. Il fonctionne également sur l'architecture sélectionnée par Amazon, qui est probablement Linux x64, mais difficile à déterminer. Étant donné que PostgreSQL sur le format de disque et la réplication dépendent de l'architecture, vous ne pouvez répliquer que sur des hôtes avec la même architecture que celle utilisée par Amazon RDS, et uniquement si votre build PostgreSQL est compatible avec la leur.

Cela signifie, entre autres, que vous n'avez aucun moyen facile de migrer loin de RDS. Vous devez arrêter toutes les écritures dans la base de données assez longtemps pour en prendre une pg_dump, la restaurer et exécuter la nouvelle base de données. Les astuces habituelles avec la réplication et le basculement, avec rsync, etc., ne fonctionneront pas car vous n'avez pas d'accès direct à l'hôte DB.

Même si RDS exécutait un Amazon PostgreSQL non corrigé, vous ne voudriez probablement pas vous permettre de faire du streaming WAL dans RDS ou d'importer dans RDS en utilisant pg_basebackuppour des raisons de sécurité. PostgreSQL traite le répertoire de données comme du contenu de confiance, et si vous avez créé des fonctions intelligentes de «LANGUE c» qui accrochent les fonctionnalités internes ou ont fait quelque chose de compliqué, vous pourriez être en mesure d'exploiter le serveur pour obtenir un meilleur accès que vous êtes censé avoir. . Amazon n'autorisera donc pas le WAL entrant de si tôt.

Ils pourraient prendre en charge l'envoi WAL sortant, mais les problèmes ci-dessus concernant la compatibilité des formats, la liberté d'apporter des modifications, etc. s'appliquent toujours.

Au lieu de cela, vous devez utiliser un outil comme Londiste ou Bucardo.

Cela est désormais possible à l'aide de la réplication logique: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication

La réplication à l'aide de systèmes basés sur des déclencheurs comme Londiste et Bucardo dans et hors de RDS est désormais prise en charge à partir du 10 novembre 2014 , selon une réponse sur ce fil de discussion.

Annonce ici