PostgreSQL: wprowadzenie do replikacji

Pisałam już posta na temat instalacji PostgreSQLa ze źródeł oraz z paczki. Te informacje mogą się wam przydać aby postawić dwie maszyny, a następnie ustawić je tak aby działały w replikacji. Od wersji PostgreSQLa 9.0 mamy dostępną replikację primary-standby (nazywana także: master-slave). W Tym poście poopowiadam co nieco o teorii na ten temat, a w następnym przejdziemy do praktyki.

Podstawowym elementem przenoszenia danych między serwerami w PostgreSQLu są pliki WAL (Write-Ahead Logging), a ich wymiana nazywa jest Log Shipping. Dane w plikach WAL są zapisywane dopiero gdy transakcja została zacomitowane (czyli zakończyła się poprawnie i została zatwierdzona). Jest to proces asynchroniczny. Rozróżniamy File-Based Log Shipping, gdzie segmenty pliku WAL są przenoszone na raz oraz Record-Based Log Shipping, gdzie plik WAL jest strumieniowany.

Przyjrzymy się jednak historii powstawania replikacji w PostgreSQLu

• PITR - Point-In-Time Recovery (PITR) - Dostępny od wersji 8.0. Nazywany jest także Incremental database backup, Online backup albo Archive backup. Logi transakcyjne są kopiowane i przechowywane, aż do momentu gdy są potrzebne. Jest głównie używany w diagnostyce i odzyskiwaniu danych po crashu głównego serwera.
• Warm Standby - Dostępny od wersji 8.3. Logi transakcji są kopiowane do serwera standby i tak zatwierdzane jak tylko slave je otrzyma (log shipping). Serwer standby pracuje w trybie offline i nie może być używany do odczytu. Może jednak być uruchomiony do użycia w bardzo krótkim czasie.
• Hot Standby - Dostępny od wersji 9.0. W porównaniu do Warm Standby, serwer standby jest dostępny do odczytu. Także wymaga file-based log shipping. Może być wykorzystywany także do pracy awaryjnej. Pliki WAL (o rozmiarach 16MB) mogą być przenoszone pomiędzy wiele serwerów poprzez sieć. Nie wymaga to podłączenia do bazy danych ale miejsca na dysku.
• Streaming Replication - Dostępny od wersji 9.1. Zamiast kopiować logi plików, dla każdego slava otwierane jest połączenie do mastera poprzez połączenia TCP/IP (może spowodować to wzrost obciążenia na bazie master). Zostało to stworzone poprzez utworzenie na masterze i slave dwóch procesów: walsender i walreceiver, które przenoszą zmodyfikowane dane stron między portami sieci. Dzięki temu zmiany z głównej bazy są widoczne prawie natychmiast na serwerze standby. W normalnym działaniu Stream Replication nie wymaga log shipping, ale może być pomocna przy starcie.

Schemat działania Streaming Replikacji:

Hot Standby i Streaming Replication są nazywane także replikacją binarną, mimo iż są różne. Głównymi cechami replikacji binarnej w PostgreSQLu są:

• replikacja całego klastra - nie ma możliwości wyróżnienia pojedynczej schematu/bazy danych/tabeli
• możliwe jest uruchomienie load-balacu pomiędzy zapytaniami czytania/pisania między masterem a slavami
• replikowane są także wszystkie zapytania DDL (Data Definition Langue) - zmiany w tabelach i indexach, tworzenie indexów i baz danych
• nie jest możliwe replikacja pomiędzy różnymi wersjami PostgreSQL-a lub między różnymi platformami
• nie ma możliwości utworzenia replikacji multi-master (tego typu architektura jest podobno (bo jeszcze nie testowałam) możliwa przy pomicy Bucardo)

Mam nadzieję, że rozumiecie główną idee i działanie replikacji tak abyśmy przeszli do praktyki.