W ostatnim blogu o nowościach w PostgreSQL 13 dokonaliśmy przeglądu niektórych nowych funkcji tej wersji, ale teraz zobaczmy, jak dokonać aktualizacji, aby móc korzystać ze wszystkich wspomnianych funkcji .
Aktualizacja do PostgreSQL 13
Jeśli chcesz zaktualizować swoją obecną wersję PostgreSQL do nowej, masz trzy główne opcje natywne do wykonania tego zadania.
-
Pg_dump/pg_dumpall:Jest to logiczne narzędzie do tworzenia kopii zapasowych, które pozwala zrzucić dane i przywrócić je w nowa wersja PostgreSQL. Tutaj będziesz mieć czas przestoju, który będzie się różnić w zależności od rozmiaru danych. Musisz zatrzymać system lub uniknąć nowych danych w węźle podstawowym, uruchomić pg_dump, przenieść wygenerowany zrzut do nowego węzła bazy danych i przywrócić go. W tym czasie nie możesz pisać do swojej podstawowej bazy danych PostgreSQL, aby uniknąć niespójności danych.
-
Pg_upgrade:Jest to narzędzie PostgreSQL do aktualizacji Twojej wersji PostgreSQL na miejscu. Może to być niebezpieczne w środowisku produkcyjnym i w takim przypadku nie zalecamy tej metody. Korzystając z tej metody, również będziesz mieć przestój, ale prawdopodobnie będzie on znacznie krótszy niż przy użyciu poprzedniej metody pg_dump.
-
Replikacja logiczna:Od wersji PostgreSQL 10 możesz używać tej metody replikacji, która umożliwia przeprowadzanie głównych aktualizacji wersji za pomocą zerowy (lub prawie zerowy) czas przestoju. W ten sposób można dodać węzeł zapasowy w ostatniej wersji PostgreSQL, a gdy replikacja jest aktualna, można przeprowadzić proces przełączania awaryjnego, aby promować nowy węzeł PostgreSQL.
Zobaczmy więc te metody jedna po drugiej.
Korzystanie z pg_dump/pg_dumpall
Jeśli przestój nie stanowi dla Ciebie problemu, ta metoda jest łatwym sposobem na aktualizację.
Aby utworzyć zrzut, możesz uruchomić:
$ pg_dumpall > dump_pg12.outLub utworzyć zrzut pojedynczej bazy danych:
$ pg_dump world > dump_world_pg12.outNastępnie możesz skopiować ten zrzut na serwer z nową wersją PostgreSQL i przywrócić go:
$ psql -f dump_pg12.out postgresPamiętaj, że będziesz musiał zatrzymać aplikację lub unikać zapisywania w bazie danych podczas tego procesu, w przeciwnym razie wystąpi niespójność danych lub potencjalna utrata danych.
Korzystanie z pg_upgrade
Po pierwsze, musisz mieć zainstalowaną na serwerze zarówno nową, jak i starą wersję PostgreSQL.
$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64Następnie możesz najpierw uruchomić pg_upgrade w celu przetestowania aktualizacji, dodając flagę -c:
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*Flagi oznaczają:
-
-b:Stary katalog wykonywalny PostgreSQL
-
-B:Nowy katalog wykonywalny PostgreSQL
-
-d:Stary katalog konfiguracji klastra bazy danych
-
-D:Nowy katalog konfiguracji klastra bazy danych
-
-c:Sprawdź tylko klastry. Nie zmienia żadnych danych
Jeżeli wszystko wygląda dobrze, możesz uruchomić to samo polecenie bez opcji -c, co spowoduje aktualizację serwera PostgreSQL. W tym celu musisz najpierw zatrzymać obecną wersję i uruchomić wspomniane polecenie.
$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.shPo zakończeniu, jak sugeruje komunikat, możesz użyć tych skryptów do analizy nowego serwera PostgreSQL i usunięcia starego, gdy będzie to bezpieczne.
Korzystanie z replikacji logicznej
Replikacja logiczna to metoda replikacji obiektów danych i ich zmian na podstawie ich tożsamości replikacji. Opiera się na trybie publikowania i subskrybowania, w którym jeden lub więcej subskrybentów subskrybuje jedną lub więcej publikacji w węźle wydawcy.
Więc na tej podstawie skonfigurujmy wydawcę, w tym przypadku serwer PostgreSQL 12, w następujący sposób.
Edytuj plik konfiguracyjny postgresql.conf:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4Edytuj plik konfiguracyjny pg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
host all rep1 10.10.10.141/32 md5Użyj tam adresu IP subskrybenta.
Teraz musisz skonfigurować subskrybenta, w tym przypadku serwer PostgreSQL 13, w następujący sposób.
Edytuj plik konfiguracyjny postgresql.conf:
listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8Ponieważ PostgreSQL 13 będzie wkrótce nowym węzłem podstawowym, powinieneś rozważyć dodanie parametrów wal_level i archive_mode w tym kroku, aby uniknąć ponownego ponownego uruchomienia usługi później.
wal_level = logical
archive_mode = onTe parametry będą przydatne, jeśli chcesz dodać nową replikę lub korzystać z kopii zapasowych PITR.
Niektóre z tych zmian wymagają ponownego uruchomienia serwera, więc zrestartuj zarówno wydawcę, jak i subskrybenta.
Teraz w wydawcy musisz utworzyć użytkownika, który będzie używany przez subskrybenta w celu uzyskania do niego dostępu. Rola używana do połączenia replikacji musi mieć atrybut REPLICATION i, aby móc skopiować dane początkowe, musi również posiadać uprawnienie SELECT do opublikowanej tabeli:
world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANTUtwórzmy publikację pub1 w węźle wydawcy dla wszystkich tabel:
world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATIONPonieważ schemat nie jest replikowany, musisz wykonać kopię zapasową w swoim PostgreSQL 12 i przywrócić ją w swoim PostgreSQL 13. Kopia zapasowa zostanie wykonana tylko dla schematu, ponieważ informacje zostaną zreplikowane w początkowym transfer.
W PostgreSQL 12 uruchom:
$ pg_dumpall -s > schema.sqlW PostgreSQL 13 uruchom:
$ psql -d postgres -f schema.sqlGdy masz już swój schemat w PostgreSQL 13, musisz utworzyć subskrypcję, zastępując wartości host, dbname, user i password tymi, które odpowiadają Twojemu środowisku.
world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTIONPowyższe działanie rozpocznie proces replikacji, który synchronizuje początkową zawartość tabel w publikacji, a następnie rozpoczyna replikację przyrostowych zmian w tych tabelach.
W celu weryfikacji utworzonej subskrypcji możesz skorzystać z katalogu pg_stat_subscription. Ten widok będzie zawierał jeden wiersz na subskrypcję dla głównego pracownika (z pustym numerem PID, jeśli pracownik nie jest uruchomiony) oraz dodatkowe wiersze dla pracowników obsługujących początkową kopię danych subskrybowanych tabel.
world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid | 16421
subname | sub1
pid | 464
relid |
received_lsn | 0/23A8490
last_msg_send_time | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn | 0/23A8490
latest_end_time | 2021-07-23 22:42:26.358605+00W celu sprawdzenia, kiedy pierwszy transfer się zakończył, możesz sprawdzić zmienną srsubstate w katalogu pg_subscription_rel. Ten katalog zawiera stan dla każdej replikowanej relacji w każdej subskrypcji.
world=# SELECT * FROM pg_subscription_rel;
srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
16421 | 16408 | r | 0/23B1738
16421 | 16411 | r | 0/23B17A8
16421 | 16405 | r | 0/23B17E0
16421 | 16402 | r | 0/23B17E0
(4 rows)Opisy kolumn:
-
srsubid:Odniesienie do subskrypcji.
-
srrelid:Odniesienie do relacji.
-
srsubstate:Kod stanu:i =inicjuj, d =dane są kopiowane, s =synchronizowane, r =gotowe (normalna replikacja).
-
srsublsn:Zakończ LSN dla stanów s i r.
Kiedy wstępny transfer się zakończy, masz wszystko gotowe, aby skierować Twoją aplikację do nowego serwera PostgreSQL 13.
Wnioski
Jak widać, PostgreSQL ma różne opcje aktualizacji, w zależności od wymagań i tolerancji przestojów.
Bez względu na to, jakiego rodzaju technologii używasz, utrzymywanie aktualności serwerów baz danych poprzez regularne uaktualnianie jest niezbędnym, ale trudnym zadaniem, ponieważ musisz mieć pewność, że nie dojdzie do utraty danych lub niespójność danych po aktualizacji. Szczegółowy i przetestowany plan jest tutaj kluczowy i oczywiście musi zawierać opcję wycofania, na wszelki wypadek.
