Създаване на настройка за репликация на PostgreSQL в Debian/Ubuntu

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

Идеята зад това е да се подобри времето за отговор на системата, като се разпределят заявките в мрежа „Round Robin“, където всеки присъстващ възел е клъстер. При този тип настройка не е важно кой от тях ще бъдат доставени, за да бъдат обработени, тъй като отговорът винаги ще бъде един и същ.

В този блог ще обясним как да репликирате PostgreSQL клъстер с помощта на инструментите, предоставени в инсталацията на програмата. Използваната версия е PostgreSQL 11.5, текущата стабилна,  общодостъпна версия за операционната система Debian Buster. За примерите в този блог се предполага, че вече сте запознати с Linux.

Програми за PostgreSQL

Вътре в директорията /usr/bin/ е програмата, отговорна за управлението на клъстера.

# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_

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

За да изброите наличните клъстери, използвайте програмата pg_lsclusters. Можете също да използвате make, за да го стартирате. Работата му зависи от файл с име Makefile, който трябва да бъде в същата директория, където ще се изпълнява командата.

# 1. The current directory is checked
pwd

# 2. Creates a directory
mkdir ~/Documents/Severalnines/

# 3. Enroute to the chosen directory
cd ~/Documents/Severalnines/

# 4. Create the file Makefile
touch Makefile

# 5. Open the file for editing

Дефиницията на блок е показана по-долу, като името му е ls и една програма, която трябва да се изпълнява, pg_lsclusters.

# 1. Block name
ls:
# 2. Program to be executed
pg_lsclusters

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

Използването на make за стартиране на програмата pg_lsclusters се осъществява с помощта на командата make ls.

# 1. Executes pg_lsclusters
make ls

Резултатът, получен при скорошна инсталация на PostgreSQL, носи единичен клъстер, наречен main, разпределен на порт 5432 на операционната система. Когато се използва програмата pg_createcluster, към създадения нов клъстер се разпределя нов порт, който има стойност 5432 като начална точка, докато се намери друг във възходящ ред.

Записване напред (WAL)

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

Хоризонталното мащабиране на системата гарантира по-голяма достъпност на услугата, тъй като ако възникнат хардуерни проблеми, това няма да има голяма разлика, тъй като има други машини, готови да поемат натоварването.

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

Архитектурата вече има три различни типа клъстери:

1. Основно лице с отговорност за писане в WAL;
2. Реплика, готова да поеме основната публикация;
3. Разни други реплики с задължение за четене на WAL.

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

Клъстерна конфигурация на PostgreSQL

Всеки клъстер има две директории, едната съдържа неговите конфигурационни файлове, а другата с регистрационните файлове на транзакциите. Те се намират съответно в /etc/postgresql/11/$(cluster) и /var/lib/postgresql/11/$(cluster) (където $(cluster) е името на клъстера).

Файлът postgresql.conf се създава веднага след създаването на клъстера чрез стартиране на програмата pg_createcluster и свойствата могат да бъдат променени за персонализиране на клъстер.

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

Възможно е добавяне на друг файл, съдържащ желаните промени, просто редактирайте едно свойство с име include, като замените стойността по подразбиране #include =‘’ с include =‘postgresql.replication.conf’.

Преди да стартирате клъстера, имате нужда от присъствието на файла postgresql.replication.conf в същата директория, където намирате оригиналния конфигурационен файл, наречен postgresql.conf.

# 1. Block name
create:
# 2. Creates the cluster
pg_createcluster 11 $(cluster) -- --data-checksums
# 3. Copies the file to the directory
cp postgresql.replication.conf /etc/postgresql/11/$(cluster)/
# 4. A value is assigned to the property
sed -i "s|^#include = ''|include = 'postgresql.replication.conf'|g" /etc/postgresql/11/$(cluster)/postgresql.conf

Използването на --data-checksums при създаването на клъстера добавя по-високо ниво на интегритет към данните, което струва малко производителност, но е много важно, за да се избегне повреда на файловете, когато прехвърлени от един клъстер в друг.

Процедурите, описани по-горе, могат да бъдат използвани повторно за други клъстери, като просто се предаде стойност на $(cluster) като параметър при изпълнението на програмата make.

# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primary

Сега, след като е установена кратка автоматизация на задачите, това, което остава да се направи, е дефинирането на файла postgresql.replication.conf според необходимостта за всеки клъстер.

Репликация на PostgreSQL

Възможни са два начина за репликиране на клъстер, като единият е пълен, другият включва целия клъстер (наречен поточно репликация), а третият може да бъде частичен или пълен (наречен логическа репликация).

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

• Главен сървър
• Сървъри в режим на готовност
• Изпращащи сървъри
• Абонати

Както видяхме по-рано, WAL е файл, който съдържа транзакциите, които се извършват в клъстера, а репликацията е предаването на тези файлове от един клъстер в друг.

Вътре в настройките, присъстващи във файла postgresql.conf, можем да видим свойства, които определят поведението на клъстера по отношение на WAL файловете, като например размера на тези файлове.

# default values
max_wal_size = 1GB
min_wal_size = 80MB

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

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

Слотът за репликация е функционалност, която позволява на клъстера да съхранява WAL файлове, необходими за предоставяне на друг клъстер с всички записи, като свойство има опцията max_replication_slots.

# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10

Когато намерението е да се възложи съхранението на тези WAL файлове, може да се използва друг метод за обработка на тези файлове, наречен непрекъснато архивиране.

Непрекъснато архивиране

Тази концепция ви позволява да насочвате WAL файловете към определено място, като използвате програма за Linux и две променливи, представляващи пътя на файла и неговото име, като %p и %f, съответно.

Това свойство е деактивирано по подразбиране, но използването му може лесно да се приложи, като се отнеме отговорността на клъстер да съхранява такива важни файлове и може да се добави към файла postgresql.replication.conf.

# 1. Creates a directory
mkdir ~/Documents/Severalnines/Archiving

# 2. Implementation on postgresql.replication.conf
archive_mode = on
archive_command = 'cp %p ~/Documents/Severalnines/Archiving/%f'

# 3. Starts the cluster
sudo systemctl start [email protected]

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

Информация за такива теми може да бъде получена чрез коментарите във файла postgresql.conf, който се появява като # (забележка:промяната изисква рестартиране).

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

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

# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433

В горния пример свойството archive_mode изисква рестартиране, докато archive_command не. След това кратко въведение в тази тема, нека да разгледаме как клъстерът реплика може да архивира тези архивирани WAL файлове, използвайки Point In Time Recovery (PITR).

Възстановяване на репликация на PostgreSQL във времето

Това внушаващо име позволява на клъстер да се върне в своето състояние от определен период от време. Това се прави чрез свойство, наречено recovery_target_timeline, което очаква да получи стойност във формат на дата, като 22.08.2019 12:05 GMT, или най-късното задание, информиращо необходимостта от възстановяване до последния съществуващ запис.

Програмата pg_basebackup, когато се изпълнява, прави копие на директория, съдържаща данните от клъстер на друго място. Тази програма има тенденция да получава множество параметри, като един от тях -R, който създава файл с име recovery.conf в копираната директория, която от своя страна не е същата като тази, която съдържа другите конфигурационни файлове, виждани преди, като postgresql.conf .

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

# 1. Block name
replicate:
# 2. Removes the current data directory
rm -rf /var/lib/postgresql/11/$(replica)
# 3. Connects to primary cluster as user postgres
# 4. Copies the entire data directory
# 5. Creates the file recovery.conf
pg_basebackup -U postgres -d postgresql://localhost:$(primaryPort) -D /var/lib/postgresql/11/$(replica) -P -R
# 6. Inserts the restore_command property and its value
echo "restore_command = 'cp ~/Documents/Severalnines/Archiving/%f %p'" >> /var/lib/postgresql/11/$(replica)/recovery.conf
# 7. The same is done with recovery_target_timeline
echo "recovery_target_timeline = 'latest'" >> /var/lib/postgresql/11/$(replica)/recovery.conf

Този посочен по-горе дублиран блок трябва да се изпълнява от потребителя на postgres на операционната система, за да се избегнат потенциални конфликти с това кой е собственикът на клъстерните данни, postgres или потребителския корен.

Клъстерът на репликата все още стои, като го насочва към успешното стартиране на репликацията, като процесът на клъстера реплика, наречен pg_walreceiver, взаимодейства с първичния клъстер, наречен pg_walsender, през TCP връзка.

# 1. Executes the block ‘replicate’ by passing two parameters
sudo -H -u postgres make replicate replica=replica primaryPort=5433
# 2. Starts the cluster replica
sudo systemctl start [email protected]

Проверката на изправността на този модел на репликация, наречен поточно репликация, се извършва чрез заявка, която се изпълнява в основния клъстер.

# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433

Заключение

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

Репликацията на клъстер осигурява няколко предимства, когато се използва по правилния начин и има лесен достъп до API, които взаимодействат с клъстерите.