Jak skonfigurować replikację fizyczną za pomocą PostgreSQL

„PostgreSQL to popularny system zarządzania relacyjnymi open source, który jest obsługiwany przez najwięcej systemu operacyjnego. Sposób utrzymania kopii głównej bazy danych nazywa się replikacją. Kopia głównej bazy danych jest replikowana na różnych serwerach fizycznych. Replikacja odbywa się poprzez ustawienie konfiguracji master-niewolnicy. Tutaj mistrz działa jako instancja podstawowa i przechowuje główną kopię bazy danych, a niewolnik działa jako instancja wtórna, która przechowuje identyczną kopię głównej bazy danych. Master działa jako serwer do odczytu, a niewolnik działa jako serwer tylko do odczytu. Dwa rodzaje replikacji są obsługiwane przez bazę danych PostgreSQL, która pomaga wdrożyć skalowalne, wysoką dostępność, tolerującą awarie aplikacji. Są to fizyczna replikacja przesyłania strumieniowego i replikacja logiczna. Sposób skonfigurowania replikacji fizycznej lub przesyłania strumieniowego z bazą danych PostgreSQL został wyjaśniony w tym samouczku."

Replikacja fizyczna lub strumieniowa

Najczęściej stosowanym rozwiązaniem replikacji jest Dziennik zapisu (WAL) Replikacja wysyłki lub przesyłania strumieniowego. Serwer rezerwowy lub niewolnik replikacji jest skonfigurowany do nawiązania połączenia z serwerem podstawowym/głównym. Rekordy WAL są przesyłane strumieniowo na serwer rezerwowy przed wypełnieniem pliku Wal. Dane są domyślnie przesyłane do serwera rezerwowego w trybie asynchronicznym. Oznacza to, że dane są przesyłane do serwera rezerwowego po popełnieniu transakcji na serwerze podstawowym. Może to spowodować utratę danych, ponieważ jeśli serwer główny zawiedzie się bez popełnienia żadnej transakcji, transakcja ta nie zostanie powtórzona na serwerze rezerwowym.

Architektura replikacji fizycznej

Proces tła, który nazywa się Wal Sender, rozpoczyna się na komputerze głównym po skonfigurowaniu konfiguracji replikacji fizycznej. Akceptuje prośbę od trybu gotowości i przesyła rekordy Wal do gotowości. Kolejny proces tła, który nazywa się odbiornik WAL, rozpoczyna się na komputerze niewolniczym, który odbiera i stosuje zmiany głównej bazy danych do bazy danych komputera niewolnika. Replikację fizyczną można zdefiniować na następującym schemacie.

Funkcje replikacji fizycznej

Całe dane pojedynczego klastra są kopiowane przez proces replikacji fizycznej, w którym klaster jest zestawem baz danych zarządzanych przez bazę danych PostgreSQL. Maszyna źródłowa nazywa się serwer główny, a komputer docelowy nazywa się serwerem rezerwowym. Poniżej wymieniono niektóre ważne cechy replikacji fizycznej.

Pliki Wal

Zamówioną serię rekordów WAL jest generowana przez PostgreSQL Server. Te rekordy zostaną przetransportowane do innej maszyny za pomocą replikacji fizycznej, a modyfikacja zostanie przeprowadzona w lokalnej bazie danych. Rekordy WAL są podzielone na pliki o równie rozmiaru, które nazywane są segmentami Wal. Pliki te są tworzone w katalogu PG_WAL, a stare pliki Wal są usuwane, gdy nie są już potrzebne.

Gorący, zimny i ciepły tryb gotowości

Gorący serwer rezerwowy służy do przechowywania aktualnych danych i umożliwienia klientom wykonywania transakcji tylko do odczytu. Zimny ​​serwer rezerwowy nie działa normalnie i zaczyna się, gdy nastąpi awaria. Ciepły serwer rezerwowy działa podobnie do gorącego serwera rezerwowego, z tym wyjątkiem, że nie może nawiązać połączenia z klientem.

Tryb odzyskiwania

Ciepłe i gorące serwery rezerwowe uruchomione w trybie odzyskiwania, a Postgres zaimportuje i zastosuje pliki WAL generowane przez serwer podstawowy w trybie odzyskiwania.

Zalety replikacji fizycznej lub strumieniowej

• Można go użyć do utrzymania kopii zapasowej bazy danych i pomaga odzyskać dane, gdy serwer podstawowy ulega awarii.
• Lepiej jest korzystać z operacji tylko do odczytu.
• Gwarantuje, że zostanie zapisana kopia ostatniego działania serwera podstawowego.
• Jeden lub więcej serwerów rezerwowych można połączyć z serwerem podstawowym, a informacje o dzienniku strumieniowe z serwera podstawowego do wszystkich podłączonych serwerów rezerwowych. Jeśli jeden z serwerów rezerwowych zostanie odłączony lub opóźniony z jakiegokolwiek powodu, wówczas przesyłanie strumieniowe będzie kontynuowane dla innego serwera rezerwowego.
• Jeśli serwer główny zostanie odłączony lub wyłączony z jakiegokolwiek powodu, będzie poczekać, aby wysłać zaktualizowane dane do serwera rezerwowego przed wyłączeniem.

Wady replikacji fizycznej lub strumieniowej

• Domyślnie powtarza dane asynchronicznie. Oznacza to, że pliki Wal, które nie są kopiowane do serwera rezerwowego, mogą zostać usunięte, gdy jakiekolwiek zmiany zostaną przeprowadzone na serwerze podstawowym. Lepiej jest ustawić wyższą wartość w Wal_Keep_Segments, aby zapobiec utratę danych.
• Nie obsługuje replikacji między różnymi serwerami PostgreSQL.
• Dane nie są bardziej bezpieczne w tej replikacji, ponieważ poufne dane można wyodrębnić bez uwierzytelniania użytkownika.
• Nie obcięwa polecenia.
• Nie obsługuje tabel zagranicznych, widoków i partycji.
• Nie obsługuje replikacji dużych obiektów.
• Nie obsługuje schematu bazy danych i poleceń DDL.

Konfiguracja replikacji fizycznej

W tej części tego samouczka pokazano kroki wdrażania logicznej replikacji w bazie danych PostgreSQL.

Wymagania wstępne

Skonfiguruj węzły Master i Replica

Możesz ustawić węzły Master i Replica na dwa sposoby. Jednym ze sposobów jest użycie dwóch osobnych komputerów, w których instalowany jest system operacyjny Ubuntu, a innym sposobem jest użycie dwóch maszyn wirtualnych, które są instalowane na tym samym komputerze. Proces testowania procesu replikacji fizycznej będzie łatwiejszy, jeśli użyjesz dwóch oddzielnych komputerów dla węzła głównego i węzła repliki, ponieważ określony adres IP można łatwo przypisać dla każdego komputera. Ale jeśli użyjesz dwóch maszyn wirtualnych na tym samym komputerze, wówczas statyczny adres IP będzie wymagał ustawienia dla każdej maszyny wirtualnej i upewnij się, że obie wirtualne maszyny mogą się ze sobą komunikować za pośrednictwem statycznego adresu IP. Użyłem dwóch wirtualnych maszyn do przetestowania procesu replikacji fizycznej w tym samouczku. Nazwa hosta węzła głównego Fahmida-Master, a nazwa hosta węzła repliki została ustawiona Fahmida-Slave Tutaj.

Zainstaluj PostgreSQL w węzłach głównych i repliki

Musisz zainstalować najnowszą wersję serwera bazy danych PostgreSQL na dwóch maszynach przed rozpoczęciem kroków tego samouczka. W tym samouczku użyto postgresql wersja 14. Uruchom następujące polecenia, aby sprawdzić zainstalowaną wersję PostgreSQL w węźle głównym.

Uruchom następujące polecenie, aby zostać użytkownikiem rootowym.

$ sudo -i

Uruchom następujące polecenia, aby zalogować się jako użytkownicy Postgres z uprawnieniami Superuser i nawiązać połączenie z bazą danych PostgreSQL.

$ su - Postgres
$ psql

Wyjście pokazuje, że PostgreSQL wersja 14.4 zostało zainstalowane w wersji 22 Ubuntu.04.1.

Musisz zainstalować tę samą wersję PostgreSQL w węźle repliki, ponieważ logicznej replikacji nie można skonfigurować między różnymi wersjami serwera PostgreSQL.

Konfiguracja węzłów pierwotnych

W tej części samouczka pokazano niezbędne konfiguracje dla węzła pierwotnego. Poniższe zadania zostaną wykonane w węźle podstawowym.

• Zmodyfikuj PostgreSQL.plik CONF w celu skonfigurowania adresu IP i poziomu Wal.
• Utwórz rolę użytkownika z tym hasłem, aby nawiązać połączenie z węzłem podstawowym z węzła repliki.
• Zmodyfikuj PG_HBA.plik CONF, aby dodać informacje o połączeniu sieciowym

Zmodyfikuj PostgreSQL.conf plik

Musisz skonfigurować adres IP węzła podstawowego w pliku konfiguracyjnym PostgreSQL o nazwie PostgreSQL.conf To znajduje się w lokalizacji, /etc/postgresql/14/main/postgresql.conf. Zaloguj się jako użytkownik root w węźle podstawowym i uruchom następujące polecenie, aby edytować plik.

$ nano/etc/postgresql/14/main/postgresql.conf

Dowiedz się Słuchaj_addresses Zmienna w pliku, usuń skrót (#) od początku zmiennej, aby odkupić linię. Możesz ustawić gwiazdkę (*) lub adres IP węzła pierwotnego dla tej zmiennej. Jeśli ustawisz Asterisk (*), serwer podstawowy będzie słuchać wszystkich adresów IP. Będzie słuchać określonego adresu IP, jeśli adres IP serwera głównego jest ustawiony na tę zmienną. W tym samouczku adres IP głównego serwera, który został ustawiony na tę zmienną 192.168.10.5.

Listen_Addressess = „”

Następnie dowiedz się Wal_Level zmienna do ustawienia typu replikacji. Tutaj wartość zmiennej będzie replika.

Wal_Level = Replica

Uruchom następujące polecenie, aby ponownie uruchomić serwer PostgreSQL po zmodyfikowaniu PostgreSQL.conf plik.

$ Systemctl restartuj postgresql

*** Uwaga: Po skonfigurowaniu konfiguracji, jeśli napotykasz problem uruchamiania serwera PostgreSQL, następnie uruchom następujące polecenia dla PostgreSQL w wersji 14.

$ sudo chmod 700 -r/var/lib/postgresql/14/main
$ sudo -i -u postgres
#/usr/lib/postgresql/14/bin/pg_ctl restart -d/var/lib/postgresql/14/main

Po pomyślnym wykonaniu powyższego polecenia będziesz mógł połączyć się z serwerem PostgreSQL.

Utwórz rolę/użytkownik do replikacji

Do replikacji wymagana jest rola/użytkownik o konkretnej zgody. Uruchom następujące polecenie SQL, aby utworzyć rolę z użytkownikiem dla replikacji.

# Utwórz repikauser Role z hasłem logowania do replikacji „12345”;

Następujące dane wyjściowe pojawią się, jeśli rola zostanie utworzona pomyślnie.

Zmodyfikuj PG_HBA.conf plik

Musisz skonfigurować adres IP węzła dodatkowego w pliku konfiguracyjnym PostgreSQL o nazwie PG_HBA.conf To znajduje się w lokalizacji, /etc/postgresql/14/main/pg_hba.conf. Zaloguj się jako użytkownik root w węźle podstawowym i uruchom następujące polecenie, aby edytować plik.

$ nano/etc/postgresql/14/main/pg_hba.conf

Dodaj następujące informacje na końcu tego pliku.

Host /32 Scram-SHA-256

IP serwera niewolnika jest ustawione na „192.168.10.10" Tutaj. Zgodnie z poprzednimi krokami do pliku dodano następujący wiersz.

Replikacja replikacji hosta 192.168.10.10/32 Scram-SHA-256

Uruchom ponownie serwer PostgreSQL

Uruchom następujące polecenie, aby ponownie uruchomić serwer PostgreSQL jako użytkownik root.

$ Systemctl restartuj postgresql

Konfiguracja węzła repliki

Niezbędne zadania zostaną wykonane dla węzła repliki, w którym zostanie przechowywana kopia głównej bazy danych. Istniejąca zawartość bazy danych węzła repliki zostanie usunięta, aby utrzymać kopię zapasową bazy danych węzła podstawowego i uczynić serwer PostgreSQL w odczytaniu węzła repliki.

Zatrzymaj serwer PostgreSQL w węźle repliki

Uruchom następujące polecenie po zalogowaniu się jako użytkownik root, aby zatrzymać serwer PostgreSQL.

$ Systemctl Stop PostgreSQL

Usuń istniejącą zawartość węzła repliki

Uruchom następujące polecenie, aby usunąć istniejącą zawartość bazy danych z serwera PostgreSQL w węźle repliki. Jest to konieczne do celów replikacji. Węzeł repliki będzie przepracowany w trybie tylko do odczytu po wykonaniu następującego polecenia

$ rm -rf/var/lib/postgresql/14/main/*

Testowanie procesu replikacji fizycznej

Musisz utworzyć bazę danych z jedną lub więcej tabel w węźle podstawowym, aby sprawdzić, czy replikacja fizyczna działa poprawnie, czy nie. Tutaj, istniejąca baza danych wymieniona Postgres serwera głównego był używany do celów testowych. Jeśli chcesz, możesz utworzyć tabelę, tworząc nową bazę danych. W tej części samouczka zostaną wykonane następujące zadania.

• Dodaj nową tabelę w wybranej bazie danych węzła pierwotnego.
• Dodaj rekord do tabeli.
• Przechowuj kopię bazy danych węzła pierwotnego do węzła repliki.
• Utwórz tabelę na serwerze podstawowym

Zaloguj się do bazy danych PostgreSQL węzła pierwotnego i uruchom następującą instrukcję SQL, aby utworzyć pracownicy Tabela w istniejącej bazie danych Postgres. Jeśli chcesz, możesz utworzyć nową bazę danych i utworzyć tabelę, wybierając nową bazę danych. Nie stworzyłem tutaj żadnej nowej bazy danych. Tak więc tabela zostanie utworzona w domyślnej bazie danych. Tabela pracowników będzie zawierać 5 pól. Są to identyfikator, nazwa, adres, e -mail i telefon.

# Utwórz pracowników tabeli (
ID szeregowy klucz podstawowy,
Nazwa varchar (15) nie null,
Tekst adresu nie null,
e -mail varchar (30),
telefon (14) nie null);

Uruchom następującą instrukcję SQL, aby wstawić rekord do tabeli.

# Wstaw do pracowników (nazwa, adres, e -mail, telefon)
Wartości („Farheen Hasan”, '12/A, Dhanmondi, Dhaka.',' [email protected] ', „+8801826783423”);
Uruchom następujące oświadczenie SQL, aby przeczytać treść tabeli pracowników.
# Wybierz * od pracowników;

Jeśli tabela jest utworzona i rekord zostanie włożony w tabeli, wówczas następujące dane wyjściowe pojawią się po wykonaniu zapytania Wybierz. Jeden rekord wprowadzono do tabeli, która jest pokazana na wyjściu.

Skopiuj bazę danych na serwer repliki

Zaloguj się do bazy danych PostgreSQL serwera repliki i uruchom następującą instrukcję SQL, aby utworzyć kopię Postgres baza danych serwera podstawowego na serwerze repliki. Po wykonaniu instrukcji poprosi o hasło użytkownika, które zostało utworzone w poprzednim kroku. Jeśli uwierzytelnianie zostanie przeprowadzone pomyślnie, replika zostanie uruchomiona.

# PG_BASEBAKUP -R -H 192.168.10.5 -u replicauser -d/var/lib/postgresql/14/main -p

Poniższe dane wyjściowe pokazuje, że replikacja odbywa się pomyślnie, a 34962 KB zostało skopiowane.

Uruchom następujące polecenie po zakończeniu replikacji jako użytkownika root, aby ponownie uruchomić serwer PostgreSQL w węźle repliki.

$ Systemctl restartuj postgresql

Teraz zaloguj się do serwera PostgreSQL w węźle repliki i uruchom następującą instrukcję SQL, aby sprawdzić, czy pracownicy' Tabela została skopiowana do węzła repliki, czy nie.

# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje zawartość pracownicy' Tabela replika Węzeł jest taki sam jak treść pracownicy' Tabela podstawowy węzeł.

Możesz dodać jedną lub więcej rekordów lub aktualizować rekordy lub usunąć rekordy w tabeli pracowników węzła podstawowego lub dodać jedną lub więcej tabel w wybranej bazie danych węzła podstawowego i sprawdzić bazę danych węzła repliki, aby sprawdzić, czy zaktualizowana treść podstawowej bazy danych jest prawidłowo powtórzona w bazie danych węzła repliki, czy nie.

Wstaw nowe rekordy w głównym węźle:

Teraz uruchom następujące polecenie Insert, aby dodać trzy kolejne rekordy w tabeli pracowników Postgres baza danych, która znajduje się w podstawowy węzeł.

# Wstaw do pracowników (nazwa, adres, e -mail, telefon)
Wartości („Abir Hossain”, '10, Jigatola, Dhaka.',' [email protected] ', „+8801888564345”),
(„Nila Chowdhury”, '67/B, Mirpur, Dhaka.',' [email protected] ', „+8801799453123”),
(„Mizanur Rahman”, „8/c, Malibag, Dhaka.',' [email protected] ', „+8801957864564”);
Uruchom następujące polecenie, aby sprawdzić bieżącą zawartość tabeli pracowników w węźle podstawowym.
# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje, że trzy nowe rekordy zostały poprawnie włożone do tabeli.

Sprawdź węzeł repliki po wprowadzeniu:

Teraz musisz sprawdzić, czy tabela pracowników węzła repliki została zaktualizowana, czy nie. Zaloguj się do serwera PostgreSQL węźle repliki i uruchom następujące polecenie, aby sprawdzić zawartość tabeli pracowników.

# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje, że w trzech nowych rekordach zostały włożone w pracownicy' Tabela replika węzeł, który został wstawiony do podstawowy Węzeł pracownicy' tabela. Tak więc zmiany w głównej bazie danych zostały poprawnie powtórzone w węźle repliki.

Aktualizacja rekord w węźle podstawowym:

Uruchom następujące polecenie aktualizacji, które zaktualizuje wartość pola telefonicznego, w którym wartość pola nazwy to „Nila Chowdhury”. Jest tylko jeden rekord w pracownicy' Tabela, która pasuje do stanu zapytania aktualizacji.

# Aktualizacja pracowników Ustaw telefon = „+880191111111” gdzie nazwa = „Nila Chowdhury”;

Uruchom następujące polecenie, aby sprawdzić bieżącą zawartość pracownicy' Tabela w podstawowy węzeł.

# Wybierz * od pracowników;

Pokazuje to następujące dane wyjściowe telefon Wartość polowa konkretnego rekordu została zaktualizowana po wykonaniu zapytania aktualizacji.

Sprawdź węzeł repliki po aktualizacji:

Teraz musisz sprawdzić, czy tabela pracowników węzła repliki została zaktualizowana, czy nie. Zaloguj się do serwera PostgreSQL węźle repliki i uruchom następujące polecenie, aby sprawdzić zawartość tabeli pracowników.

# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje, że jeden rekord został zaktualizowany w pracownicy' Tabela replika węzeł, który został zaktualizowany w podstawowy Węzeł pracownicy' tabela. Tak więc zmiany w głównej bazie danych zostały poprawnie powtórzone w węźle repliki.

Usuń rekord w węźle podstawowym:

Uruchom następujące polecenie Usuń, które usunie rekord z pracownicy' Tabela podstawowy węzeł, w którym wartość pola e -mail to „[email protected] ”. Jest tylko jeden rekord w pracownicy' Tabela, która pasuje do stanu zapytania Usuń.

# Usuń od pracowników, gdzie e -mail = '[email protected] ';

Uruchom następujące polecenie, aby sprawdzić bieżącą zawartość pracownicy' Tabela w podstawowy węzeł.

# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje, że jeden rekord został usunięty po wykonaniu zapytania Usuń.

Sprawdź węzeł repliki po usunięciu rekordu:

Teraz musisz sprawdzić, czy tabela pracowników węzła repliki została usunięta, czy nie. Zaloguj się do serwera PostgreSQL węźle repliki i uruchom następujące polecenie, aby sprawdzić zawartość tabeli pracowników.

# Wybierz * od pracowników;

Poniższe dane wyjściowe pokazuje, że jeden rekord został usunięty w pracownicy' Tabela replika węzeł, który został usunięty w podstawowy Węzeł pracownicy' tabela. Tak więc zmiany w głównej bazie danych zostały poprawnie powtórzone w węźle repliki.

Wniosek

Cel fizycznej replikacji w celu utrzymania kopii zapasowej bazy danych, architektura replikacji fizycznej, zalety i wady replikacji fizycznej oraz etapy wdrażania replikacji fizycznej w bazie danych PostgreSQL zostały wyjaśnione w tym samouczku z przykładami. Mam nadzieję, że koncepcja replikacji fizycznej zostanie usunięta dla użytkowników, a użytkownicy będą mogli użyć tej funkcji w swojej bazie danych PostgreSQL po przeczytaniu tego samouczka.