Надстройка до PostgreSQL13

В скорошен блог за новостите в PostgreSQL 13 прегледахме някои от новите функции на тази версия, но сега нека видим как да надстроите, за да можете да се възползвате от всички тези споменати функции .

Надстройване до PostgreSQL 13

Ако искате да надстроите текущата си версия на PostgreSQL до тази нова, имате три основни естествени опции за изпълнение на тази задача.

Pg_dump/pg_dumpall:Това е инструмент за логично архивиране, който ви позволява да изхвърлите данните си и да ги възстановите в нова версия на PostgreSQL. Тук ще имате период на престой, който ще варира в зависимост от размера на вашите данни. Трябва да спрете системата или да избегнете нови данни в първичния възел, да стартирате pg_dump, да преместите генерирания дъмп в новия възел на базата данни и да го възстановите. През това време не можете да пишете в основната си база данни PostgreSQL, за да избегнете несъответствие на данните.
Pg_upgrade:Това е инструмент на PostgreSQL за надграждане на вашата PostgreSQL версия на място. Може да бъде опасно в производствена среда и ние не препоръчваме този метод в този случай. Използвайки този метод, вие също ще имате време за престой, но вероятно то ще бъде значително по-малко от използването на предишния метод pg_dump.
Логическа репликация:От PostgreSQL 10 можете да използвате този метод на репликация, който ви позволява да извършвате големи надстройки на версията с нулев (или почти нулев) престой. По този начин можете да добавите резервен възел в последната версия на PostgreSQL и когато репликацията е актуална, можете да извършите процес на отказ, за да популяризирате новия PostgreSQL възел.

И така, нека видим тези методи един по един.

Използване на pg_dump/pg_dumpall

В случай, че престоят не е проблем за вас, този метод е лесен начин за надграждане.

За да създадете дъмп, можете да изпълните:

$ pg_dumpall > dump_pg12.out

Или за създаване на дъмп на една база данни:

$ pg_dump world > dump_world_pg12.out

След това можете да копирате този дъмп на сървъра с новата версия на PostgreSQL и да го възстановите:

$ psql -f dump_pg12.out postgres

Имайте предвид, че ще трябва да спрете приложението си или да избегнете запис в базата данни по време на този процес, в противен случай ще имате несъответствие на данните или потенциална загуба на данни.

Използване на pg_upgrade

Първо, ще трябва да имате както новата, така и старата версия на 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_64

След това, първо, можете да стартирате pg_upgrade за тестване на надстройката, като добавите флага -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*

Флаговете означават:

-b:Старата изпълнима директория на PostgreSQL
-B:Новата изпълнима директория на PostgreSQL
-d:Старата директория за конфигурация на клъстер на база данни
-D:Новата директория за конфигурация на клъстера на базата данни
-c:Проверете само клъстерите. Не променя никакви данни

Ако всичко изглежда наред, можете да изпълните същата команда без флага -c и тя ще надстрои вашия PostgreSQL сървър. За това първо трябва да спрете текущата си версия и да изпълните споменатата команда.

$ 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.sh

Когато приключи, както подсказва съобщението, можете да използвате тези скриптове за анализ на новия PostgreSQL сървър и изтриване на стария, когато е безопасно.

Използване на логическа репликация

Логическата репликация е метод за репликиране на обекти с данни и техните промени въз основа на тяхната идентичност на репликация. Базира се на режим на публикуване и абонамент, при който един или повече абонати се абонират за една или повече публикации на възел на издател.

Така че въз основа на това, нека конфигурираме издателя, в този случай сървъра PostgreSQL 12, както следва.

Редактирайте конфигурационния файл postgresql.conf:

listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4

Редактирайте конфигурационния файл pg_hba.conf:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host     all     rep1     10.10.10.141/32     md5

Използвайте IP адреса на абоната там.

Сега трябва да конфигурирате абоната, в този случай сървъра на PostgreSQL 13, както следва.

Редактирайте конфигурационния файл postgresql.conf:

listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8

Тъй като този PostgreSQL 13 скоро ще бъде новият основен възел, трябва да помислите за добавяне на параметрите wal_level и archive_mode в тази стъпка, за да избегнете ново рестартиране на услугата по-късно.

wal_level = logical
archive_mode = on

Тези параметри ще бъдат полезни, ако искате да добавите нова реплика или за използване на PITR архиви.

Някои от тези промени изискват рестартиране на сървъра, така че рестартирайте както издателя, така и абоната.

Сега в издателя трябва да създадете потребителя, който да бъде използван от абоната за достъп до него. Ролята, използвана за връзката за репликация, трябва да има атрибута REPLICATION и, за да може да копира първоначалните данни, тя също се нуждае от привилегията SELECT в публикуваната таблица:

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANT

Нека създадем публикацията pub1 в възела на издателя за всички таблици:

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION

Тъй като схемата не се репликира, трябва да направите резервно копие във вашия PostgreSQL 12 и да го възстановите във вашия PostgreSQL 13. Архивът ще бъде направен само за схемата, тъй като информацията ще бъде репликирана в първоначалната прехвърляне.

В PostgreSQL 12 изпълнете:

$ pg_dumpall -s > schema.sql

В PostgreSQL 13 изпълнете:

$ psql -d postgres -f schema.sql

След като имате своята схема в PostgreSQL 13, трябва да създадете абонамента, като замените стойностите на хост, dbname, потребител и парола с тези, които съответстват на вашата среда.

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 SUBSCRIPTION

Гореното ще стартира процеса на репликация, който синхронизира първоначалното съдържание на таблицата на таблиците в публикацията и след това започва да репликира постепенни промени в тези таблици.

За да проверите създадения абонамент, можете да използвате каталога pg_stat_subscription. Този изглед ще съдържа по един ред на абонамент за основния работник (с нулев PID, ако работникът не работи) и допълнителни редове за работници, обработващи първоначалното копие на данни на абонираните таблици.

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+00

За да проверите кога първоначалното прехвърляне е завършено, можете да проверите променливата srsubstate в каталога pg_subscription_rel. Този каталог съдържа състоянието за всяка репликирана връзка във всеки абонамент.

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)

Описания на колони:

srsubid:Препратка към абонамента.
srrelid:Препратка към релация.
srsubstate:Код на състоянието:i =инициализира, d =данните се копират, s =синхронизирани, r =готов (нормална репликация).
srsublsn:Край на LSN за s и r състояния.

Когато първоначалното прехвърляне приключи, имате всичко готово, за да насочите приложението си към вашия нов PostgreSQL 13 сървър.

Заключение

Както можете да видите, PostgreSQL има различни опции за надграждане, в зависимост от вашите изисквания и толерантност към престой.

Без значение какъв вид технология използвате, поддържането на вашите сървъри на база данни актуални чрез извършване на редовни надстройки е необходима, но трудна задача, тъй като трябва да сте сигурни, че няма да имате загуба на данни или несъответствие на данните след надстройка. Подробният и тестван план е ключът тук и разбира се, той трябва да включва опция за връщане назад, за всеки случай.