Получить файлы WAL из экземпляра AWS RDS PostgreSQL

У нас есть экземпляр Postgres RDS в Amazon Web Services. У нас включено автоматическое резервное копирование, и мы делаем снимки ежедневно. Мы хотели бы создать локальную «актуальную» резервную копию экземпляра RDS, которой мы можем управлять сами. Запуск pg_dump для экземпляра недостаточен, потому что мы хотим иметь возможность восстановить базу данных в любой момент времени. Мы бы предпочли иметь локальную резервную копию RDS и всех файлов WAL с момента ее создания. Вопросов:

1. Можно ли получить доступ к файлам и резервным копиям WAL, которые RDS автоматически создает в своей процедуре резервного копирования? Это было бы идеально. Я хотел бы скачать их локальную копию. После первоначального расследования я чувствую, что ответ на этот вопрос «нет». Похоже, RDS хранит свои файлы WAL и резервные копии в S3, но делает их недоступными для нас. Я бы с удовольствием подтвердил.

2. Есть ли другой способ доступа к транзакциям (файлам WAL), которые произошли в экземпляре RDS? Я предполагаю, что мы сможем создать базу данных Postgres на EC2 и «подать» транзакции из нашего основного «живого» экземпляра RDS в этот экземпляр EC2. Как только наш экземпляр EC2 будет обновлен, мы сможем извлечь файлы WAL оттуда. Что за головная боль, однако: / Возможна ли такая настройка? Какое волшебство «подать» из нашего экземпляра RDS в экземпляр EC2, чтобы оно всегда было актуальным?

Благодарность!

Обновление. Я уже писал об этом на форумах AWS. Пожалуйста, зайдите и спросите об этом там .

На момент написания Amazon RDS не поддерживает физическую репликацию вне RDS. Вы можете GRANTиспользовать REPLICATIONправа пользователей, используя rds_superuserлогин, но вы не можете настроить replicationзаписи для внешних IP-адресов в pg_hba.conf.

Кроме того, когда вы создаете группу параметров БД в RDS, некоторые ключевые параметры показываются, но блокируются, например archive_command, которые заблокированы /etc/rds/dbbin/pgscripts/rds_wal_archive %p. AWS RDS для PostgreSQL, по-видимому, не предоставляет эти WAL для внешнего доступа (скажем, через S3), как это было бы необходимо, если бы вы использовали репликацию WAL-shipping для внешнего PITR.

Таким образом, на данный момент, если вы хотите, чтобы Wal-Shipping, не используйте RDS. Это консервированная простая в использовании база данных, но простая в использовании часто означает, что она также ограничена, и это, безусловно, имеет место в данном случае. Как отмечает Джо Лав в комментариях, он обеспечивает доставку WAL и PITR в RDS , но вы не можете получить доступ к WAL для этого из- за пределов RDS.

Поэтому вам нужно использовать собственные средства резервного копирования RDS - дампы, снимки и собственный PITR на основе WAL.

Даже если RDS разрешил вам устанавливать соединения репликации (для pg_basebackupрепликации или потоковой репликации) и позволил вам получить доступ к заархивированному WAL, вы не сможете фактически использовать этот WAL. RDS запускает исправленный PostgreSQL, хотя никто не знает, насколько сильно он исправлен или существенно ли он изменяет формат на диске. Он также работает на архитектуре, выбранной Amazon, которая, вероятно, представляет собой x64 Linux, но определить ее нелегко. Поскольку PostgreSQL в отношении формата диска и репликации зависит от архитектуры, вы можете выполнять репликацию только на хосты с той же архитектурой, что и в Amazon RDS, и только в том случае, если ваша сборка PostgreSQL была совместима с их сборкой.

Среди прочего это означает, что у вас нет простого способа перейти от RDS. Вы должны были бы остановить все записи в базу данных на достаточно долгое время, чтобы выполнить pg_dumpвосстановление, восстановить и запустить новую БД. Обычные приемы с репликацией и отработкой отказа, с rsync и т. Д. Не сработают, потому что у вас нет прямого доступа к хосту БД.

Даже если RDS запускает непатентованный PostgreSQL, Amazon, вероятно, не захочет разрешать вам выполнять потоковую передачу WAL в RDS или импортировать в RDS с pg_basebackupцелью обеспечения безопасности. PostgreSQL рассматривает каталог данных как доверенное содержимое, и если вы создали какие-либо умные функции 'LANGUAGE c', которые перехватывают внутреннюю функциональность, или сделали что-то еще сложное, вы можете использовать сервер для получения большего доступа, чем предполагалось , Таким образом, Amazon не собирается разрешать входящий WAL в ближайшее время.

Они могут поддерживать исходящую WAL-рассылку, но указанные выше проблемы с совместимостью форматов, свободой вносить изменения и т. Д. По-прежнему актуальны.

Вместо этого вы должны использовать такой инструмент, как Londiste или Bucardo.

Теперь это возможно с помощью логической репликации: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.

Репликация с использованием систем на основе триггеров, таких как Londiste и Bucardo, в RDS и из RDS теперь поддерживается с 10 ноября 2014 года , согласно ответу в этой ветке форума.

Объявление здесь