Pobierz pliki WAL z instancji AWS RDS PostgreSQL

Mamy instancję Postgres RDS w Amazon Web Services. Mamy włączone automatyczne kopie zapasowe i codziennie wykonujemy migawki. Chcielibyśmy wygenerować lokalną „aktualną” kopię zapasową instancji RDS, którą sami możemy zarządzać. Uruchomienie pg_dump na instancji nie jest wystarczające, ponieważ chcemy móc przywrócić bazę danych w dowolnym momencie. Wolelibyśmy mieć lokalną kopię zapasową RDS i wszystkich plików WAL od czasu jej utworzenia. Pytania:

1. Czy można uzyskać dostęp do plików WAL i kopii zapasowych generowanych automatycznie przez RDS w ramach procedury tworzenia kopii zapasowych? To byłoby idealne. Chciałbym pobrać ich lokalną kopię. Po wstępnym dochodzeniu czuję, że odpowiedź na to pytanie brzmi „nie”. Wygląda na to, że RDS przechowuje swoje pliki WAL i kopie zapasowe w S3, ale czyni je dla nas niedostępnymi. Chciałbym potwierdzenia.

2. Czy istnieje inny sposób dostępu do transakcji (plików WAL), które miały miejsce w instancji RDS? Wyobrażam sobie, że powinniśmy być w stanie utworzyć bazę danych Postgres na EC2 i transakcje „feed” z naszej podstawowej „aktywnej” instancji RDS do tej instancji EC2. Po zaktualizowaniu naszego wystąpienia EC2 możemy pobrać z niego pliki WAL. Co za ból głowy: / Czy ta konfiguracja jest możliwa? Jaka jest magia „karmić” z naszego wystąpienia RDS do wystąpienia EC2, aby zawsze było aktualne?

Dzięki!

Aktualizacja: Napisałem o tym na forach AWS - wejdź do środka i poproś o to .

W chwili pisania tego tekstu Amazon RDS nie obsługuje fizycznej replikacji poza RDS. Możesz użyć prawa GRANTużytkownika REPLICATIONza pomocą rds_superuserloginu, ale nie możesz skonfigurować replicationwpisów dla zewnętrznych adresów IP w pg_hba.conf.

Ponadto, gdy tworzysz grupę parametrów DB w RDS, niektóre kluczowe parametry są wyświetlane, ale zablokowane, np. archive_commandKtóre jest zablokowane /etc/rds/dbbin/pgscripts/rds_wal_archive %p. Wydaje się, że AWS RDS dla PostgreSQL nie ujawnia tych WAL dla zewnętrznego dostępu (powiedzmy przez S3), jak byłoby to konieczne, gdybyś używał replikacji wysyłającej WAL dla zewnętrznego PITR.

Więc w tym momencie, jeśli chcesz wal-shipping, nie używaj RDS. Jest to prosta w obsłudze baza danych w puszkach, ale łatwa w użyciu często oznacza, że ​​jest również ograniczona, i na pewno tak jest w tym przypadku. Jak zauważa Joe Love w komentarzach, zapewnia wysyłkę WAL i PITR w ramach RDS , ale nie można uzyskać dostępu do WAL do tego z zewnątrz RDS.

Musisz więc korzystać z własnych funkcji tworzenia kopii zapasowych RDS - zrzutów, migawek i własnego PITR opartego na WAL.

Nawet jeśli pg_basebackupusługa RDS pozwoliła na tworzenie połączeń replikacyjnych (replikacja lub transmisja strumieniowa) i umożliwiła dostęp do zarchiwizowanej WAL, może nie być w stanie faktycznie z niej skorzystać. RDS uruchamia łatany PostgreSQL, choć nikt nie wie, jak mocno został on załatany ani czy znacząco zmienia format na dysku. Działa również na architekturze wybranej przez Amazon, która jest prawdopodobnie Linuksem x64, ale nie jest łatwa do ustalenia. Ponieważ PostgreSQL na format dysku i replikację są zależne od architektury, możesz replikować tylko na hostach o tej samej architekturze, co używana przez Amazon RDS, i tylko wtedy, gdy twoja kompilacja PostgreSQL jest zgodna z ich.

Oznacza to między innymi, że nie masz łatwego sposobu na migrację z RDS. Musiałbyś zatrzymać wszystkie zapisy do bazy danych na tyle długo, aby wziąć pg_dump, przywrócić i uruchomić nową bazę danych . Zwykłe sztuczki z replikacją i przełączaniem awaryjnym, z rsync itp. Nie będą działać, ponieważ nie masz bezpośredniego dostępu do hosta DB.

Nawet jeśli RDS uruchomił niezałatowaną PostgreSQL, Amazon prawdopodobnie nie chciałby zezwalać na przesyłanie WAL do RDS lub import do RDS pg_basebackupze względów bezpieczeństwa. PostgreSQL traktuje katalog danych jako zaufaną treść, a jeśli stworzyłeś jakieś sprytne funkcje „JĘZYK c”, które przechwytują wewnętrzną funkcjonalność lub robisz cokolwiek innego, co może być trudne, możesz wykorzystać serwer do uzyskania większego dostępu, niż powinien. . Dlatego Amazon nie zezwoli w najbliższym czasie na WAL.

Mogą obsługiwać wychodzące wysyłanie WAL, ale powyższe problemy ze zgodnością formatu, swobodą wprowadzania zmian itp. Nadal obowiązują.

Zamiast tego powinieneś użyć narzędzia takiego jak Londiste lub Bucardo.

Jest to teraz możliwe przy użyciu replikacji logicznej: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication

Replikacja przy użyciu systemów opartych na wyzwalaczach, takich jak Londiste i Bucardo, do i z RDS jest teraz obsługiwana od 10 listopada 2014 r. , Na odpowiedź w tym wątku na forum.

Ogłoszenie tutaj