Налаштування кластера реплікації PostgreSQL на сервері Ubuntu 20.04
Крок 1 — Встановлення PostgreSQL
apt update
Потім встановіть пакет Postgres разом із -contribпакетом, який додає деякі додаткові утиліти та функції:
sudo apt install postgresql postgresql-contrib
Переконайтеся, що служба запущена:
sudo systemctl start postgresql.service
Крок 2 — Використання ролей і баз даних PostgreSQL
За замовчуванням Postgres використовує концепцію під назвою «ролі» для обробки аутентифікації та авторизації. Вони в чомусь схожі на звичайних користувачів і груп у стилі Unix.
Після встановлення Postgres налаштовується на використання ідентифікаційної автентифікації, що означає, що він пов’язує ролі Postgres із відповідним системним обліковим записом Unix/Linux. Якщо в Postgres існує роль, ім’я користувача Unix/Linux з тим самим ім’ям може ввійти як ця роль.
Процедура встановлення створила обліковий запис користувача під назвою postgres , яка пов’язана з роллю Postgres за замовчуванням. Існує кілька способів використовувати цей обліковий запис для доступу до Postgres. Один із способів — перейти до облікового запису postgres на вашому сервері, виконавши таку команду:
sudo -i -u postgres
Тоді ви можете отримати доступ до підказки Postgres, запустивши:
psql
Щоб вийти з підказки PostgreSQL, виконайте наступне:
\q
Для забезпечення високої доступності, надійності та відмовостійкості сервер баз даних PostgreSQL підтримує реплікацію. Це процес копіювання даних у режимі реального часу на кількох серверах для створення резервних копій для відновлення. У цьому типі налаштування первинний вузол називають головним , а сервери, які отримують репліковані дані, відомі як репліки або резервні вузли, як показано нижче.
У більшості випадків ви налаштовуєте резервні репліки PostgreSQL, щоб забезпечити надлишковість даних і запобігти єдиній точці збою (SPOF). У випадку, якщо головний сервер виходить з ладу, ви можете підвищити будь-яку з реплік, щоб вона стала новим головним. За конструкцією PostgreSQL дозволяє запускати репліки в режимі гарячого очікування . Це здатність резервних вузлів приймати підключення та операції лише для читання. Це дозволяє розподілити тягар операцій інтенсивного читання на весь кластер.
server-1: Master 10.10.10.100
server-2: Slave1 10.10.10.101
server-3: Slave2 10.10.10.102 (при потребі)
1. Налаштовуємо головний вузол (Master)
SSH на головний сервер (10.10.10.100) і виконайте наведені нижче дії, щоб внести зміни в конфігурацію.
sudo -u postgres psql
Введіть пароль postgresкористувача та натисніть ENTER, щоб продовжити. Далі введіть CREATE ROLEкоманду нижче, щоб налаштувати виділений repl_userобліковий запис з REPLICATIONпривілеями. Замінити EXAMPLE_PASSWORDна сильне значення. Пізніше ваш вузол репліки використовуватиме облікові дані repl_userдля підключення до головного вузла для отримання даних реплікації.
postgres-# CREATE ROLE repl_user WITH REPLICATION LOGIN PASSWORD 'My_PASSWORD';
Вийдіть із бази даних PostgreSQL.
postgres-# \q
Далі скористайтеся, nanoщоб відкрити файл конфігурації PostgreSQL за замовчуванням.
$ sudo nano /etc/postgresql/12/main/postgresql.conf
Відкривши наведений вище файл, знайдіть listen_addresses директиву. Цей параметр дозволяє вказати інтерфейс, за яким сервер прослуховує з’єднання. Для цього налаштування ви хочете, щоб сервер бази даних слухав інтерфейс приватної IP-адреси.
... listen_addresses = '10.10.10.100' ... # what IP address(es) to listen on; ...
Далі знайдіть wal_level. Цей параметр визначає, скільки інформації записується до файлу Write Ahead Log(WAL).
... wal_level = logical ...
Далі знайдіть wal_log_hintsдирективу. За замовчуванням це значення дорівнює off.
... wal_log_hints = on ...
Збережіть та закрийте /etc/postgresql/12/main/postgresql.confфайл, коли завершите редагування.
Далі ви внесете кілька змін у /etc/postgresql/12/main/pg_hba.confфайл, який все ще знаходиться під головним вузлом. У цьому файлі ви включите IP-адресу вузла репліки, щоб він міг підключитися до головного вузла. Відкрийте /etc/postgresql/12/main/pg_hba.confфайл за допомогою nanoдля редагування.
$ sudo nano /etc/postgresql/12/main/pg_hba.conf
Далі додайте записи нижче в нижній частині файлу, щоб дозволити вашій репліці node( 10.106.0.2) підключитися до головного repl_userоблікового запису.
host replication repl_user 10.10.10.101/32 md5
Збережіть і закрийте /etc/postgresql/12/main/pg_hba.confфайл. Потім перезапустіть сервер PostgreSQL на головному вузлі, щоб застосувати нові зміни.
$ sudo systemctl restart postgresql
Тепер ви налаштували головний сервер і тепер можете підключити резервний сервер, щоб почати реплікацію даних у режимі реального часу.
2. Налаштовуємо вузол репліки (Slave)
Сервер репліки( 10.10.10.101) повинен десь почати, перш ніж він зможе почати реплікацію даних з головного.
Найкращий спосіб ініціалізації або завантаження сервера репліки - скопіювати файли даних головного сервера за допомогою pg_basebackupутиліти. SSH до сервера репліки та виконайте наведений нижче процес, щоб створити базову копію даних головного сервера.
Переконайтеся, що сервер PostgreSQL не працює на сервері репліки, зупинивши postgresqlслужбу.
$ sudo systemctl stop postgresql
Все ще на сервері репліки скористайтеся командою Linux rm, щоб видалити всі файли в каталозі даних PostgreSQL /var/lib/postgresql/12/main/
$ sudo rm -rv /var/lib/postgresql/12/main/
Далі запустіть pg_basebackupна сервері репліки, щоб скопіювати дані з головного сервера, використовуючи наступні параметри.
sudo pg_basebackup -h 10.10.10.100 -U repl_user -X stream -C -S replica_1 -v -R -W -D /var/lib/postgresql/12/main/
Далі виконайте таку команду на своєму вузлі репліки, щоб переконатися, що файли даних належним чином належать postgresкористувачу.
$ sudo chown postgres -R /var/lib/postgresql/12/main/
Тепер у вашому вузлі репліки є правильні файли даних, тепер ви можете відкрити його як вузол гарячого очікування.
$ sudo systemctl start postgresql
У цьому посібнику ви дізналися про різні методи реплікації, які підтримуються сервером баз даних PostgreSQL, а також їх плюси, мінуси та варіанти використання. Ближче до кінця посібника ви налаштували кластер реплікації за допомогою моделі обробки потоку PostgreSQL і зможете реплікувати дані на двох серверах. Використовуйте цей посібник для впровадження резервного копіювання PostgreSQL в реальному часі, кластерів аварійного відновлення та налаштувань високої доступності.
Відновлення Slave використовуючи pg_basebackup
Бувають випадки, що репліка відстає в записах із мастером і якщо якийсь сервер не працює, то відповідно ми отримаєм втрату роботи репліки
часта помилка - не стартує репліка видаючи помилку:
psql: error: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
Отже ми будем пробувати обновляти дані:
1 Зупиняєм сервіс
# systemctl stop postgresql # killall -9 postgres
Потокова реплікація PostgreSQL — це чудовий спосіб масштабування кластерів PostgreSQL , який додає їм високу доступність. Як і у випадку з кожною реплікацією, ідея полягає в тому, що підлеглий пристрій є копією головного і що підлеглий пристрій постійно оновлюється змінами, які відбулися на головному пристрої за допомогою певного механізму реплікації. Може статися так, що підлеглий з якихось причин розсинхронізується з головним. Як я можу повернути його до ланцюга реплікації? Як я можу переконатися, що підлеглий пристрій знову синхронізований із головним? Давайте поглянемо на це коротке повідомлення в блозі. Що дуже допомагає, немає можливості записати на slave, якщо він знаходиться в режимі відновлення. Ви можете перевірити це так: postgres=# SELECT pg_is_in_recovery(); pg_is_in_recovery ------------------- t (1 row) postgres=# CREATE DATABASE mydb; ERROR: cannot execute CREATE DATABASE in a read-only transaction Все ще може статися, що підлеглий пристрій не синхронізується з головним. Пошкодження даних – ні апаратне, ні програмне забезпечення не позбавлені помилок і проблем. Деякі проблеми з дисководом можуть викликати пошкодження даних на підлеглому пристрої. Деякі проблеми з процесом «вакууму» можуть призвести до зміни даних. Як вийти з такого стану? Відновлення підлеглого пристрою за допомогою pg_basebackup Основним кроком є надання підлеглого пристрою, використовуючи дані від головного. Оскільки ми будемо використовувати потокову реплікацію, ми не можемо використовувати логічне резервне копіювання. На щастя, є готовий інструмент, який можна використовувати для налаштування: pg_basebackup . Давайте подивимося, які кроки нам потрібно зробити, щоб створити підлеглий сервер. Щоб було зрозуміло, ми використовуємо PostgreSQL 12 для цілей цієї публікації в блозі. Початковий стан простий. Наш раб не копіює свого пана. Дані, які він містить, пошкоджені, їх не можна використовувати чи довіряти. Тому першим кроком, який ми зробимо, буде зупинка PostgreSQL на нашому підпорядкованому пристрої та видалення даних, які він містить: root@vagrant:~# systemctl stop postgresql Або навіть: root@vagrant:~# killall -9 postgres Тепер давайте перевіримо вміст файлу postgresql.auto.conf , ми можемо використати облікові дані реплікації, що зберігаються в цьому файлі пізніше, для pg_basebackup :
# cat /var/lib/postgresql/12/main/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. promote_trigger_file='/tmp/failover_5432.trigger' recovery_target_timeline=latest primary_conninfo='application_name=pgsql_0_node_1 host=10.10.10.100 port=5432 user=repl_user password=qpassword7LV97CFX9F'
Копіюєм пароль та користувача
Далі видаляємо старі конфігураційні файли:
# rm -rf /var/lib/postgresql/12/main/*
Після видалення даних нам потрібно використовувати pg_basebackup, щоб отримати дані з master:
pg_basebackup -h 10.10.10.100 -U repl_user -Xs -P -R -D /var/lib/postgresql/12/main/
далі він попросить пароль та почне синхронізувати БД
Password: 999354/999354 kB (100%), 1/1 tablespace
Прапори, які ми використовували, мають таке значення:
-Xs: ми хочемо транслювати WAL під час створення резервної копії. Це допомагає уникнути проблем із видаленням файлів WAL, якщо у вас є великий набір даних.
-P: ми хотіли б бачити прогрес резервного копіювання.
-R: ми хочемо, щоб pg_basebackup створив файл standby.signal і підготував файл postgresql.auto.conf з налаштуваннями підключення.
Коли резервна копія буде готова, все, що нам потрібно зробити, це переконатися, що для вмісту каталогу даних призначено правильний користувач і групу – ми виконали pg_basebackup як 'root', тому ми хочемо змінити його на 'postgres':
# chown -R postgres.postgres /var/lib/postgresql/12/main/
Ось і все, ми можемо запустити підлеглий, і він повинен почати копіювати від головного.
# systemctl start postgresql
додаткові джерела: