Введення в PostgreSQL BDR

    

Введення в PostgreSQL BDR.

 image
PostgreSQL це не тільки стабільна і надійна СУБД але й плюс до всіх це динамічно розвивається продукт, в якому від релізу до релізу з'являються самі різні проривні речі. Свого часу однією з таких технологій була потоковая реплікація. Це високопродуктивна реплікація яка дозволяє дуже легко і дешево масштабувати базу даних на читання. Використовуючи її можна створювати надійні конфігурації розподіляючи навантаження на читання між вузлами. Однак як я написав вище, продукт розвивається, і сьогодні в статті мова піде про нову технологію BDR (Bi-Directional Replication).
 
 
Трохи термінів для тих хто не в темі:
 WAL (Write Ahead Log) — журнал транзакції, на ньому заснована вбудована потоковая реплікація в постгресе, СУБД пише туди все що відбувається з даними в БД.
 SR (Streaming Replication) — загальна назва вбудованої потокової реплікації яка яка заснована на WAL, все що пишеться в WAL, потім вирушає на слейв і відтворюється. Буває фізична і логічна потоковая реплікація.
 PLSR (Physical Log Streaming Replication) — фізична потоковая реплікація (те що вже реалізовано і працює), все що потрапило в WAL без подальшого розбору реплицируется на слейв сервера, це і зміна даних / схеми і більше низькорівневі речі (full page writes, vacuum, hint bit settings).
 LLSR (Logical Log Streaming Replication) — логічна потоковая реплікація (з'явиться в 9.4) також заснована на WAL журналах, але вже більш інтелектуальна і для реплікації витягується тільки певна частина журналів в яких описуються зміни схеми і даних БД (тобто деякі низькорівневі речі відсіваються).
 
Що ховається під терміном BDR?
 BDR (Bi-Directional Replication) це нова функціональність додаванні в ядро ​​PostgreSQL яка надає розширені засоби для реплікації. На даний момент це реалізовано у вигляді невеликого патча і модуля. Оголошене що повністю буде тільки в PostgreSQL 9.5 (зараз 9.3-stable і 9.4-beta1).
Якщо коротко, то BDR дозволяє створювати географічно розподілені асинхронні мульти-майстер конфігурації (о так, дитинко) використовуючи для цього вбудовану логічну потокову реплікацію LLSR.
Проте, BDR не є інструментом для кластеризації, т.к. тут немає якихось глобальних менеджерів блокувань або координаторів транзакцій (привіт Postgres-XC / XL). Кожен вузол не залежить від інших, що було б неможливо у випадку використання менеджерів блокування. Кожен з вузлів містить локальну копію даних ідентичну даними на інших вузлах. Запити також виконуються тільки локально (щоб було більш зрозуміло про що мова, наведу порівняння з Postgres-XC/Postgres-XL, там всі сервери працюють як би в одній упряжці, транзакції рулятся глобальним менеджером транзакції, а запити від програми надходять на координатора (ів ) який відправляє виконуватися прийшли запити на будь-який робочий вузол, ось). При цьому кожен з вузлів внутрішньо Консистент в будь-який час, цілком ж група серверів є узгодженою в кінцевому рахунку (eventually consistent )
 
Унікальність BDR полягає в тому що вона несхожа ні на вбудовану потокову реплікацію, ні на існуючі trigger-based рішення (Londiste, Slony, Bucardo).
Найпомітнішим відмінністю від потокової реплікації є те, що BDR (LLSR) оперує базами (per-database replication), а класична PLSR реплицирует цілком інстанси (per-cluster replication), тобто всі бази всередині інстанси.
 
Існуючі обмеження і особливості:
1. Всі зміни даних викликаються INSERT / DELETE / UPDATE реплицируются (TRUNCATE на момент написання статті поки не реалізований)
2. Більшість операції зміни схеми (DDL) реплицируются успішно. Непідтримувані DDL фіксуються модулем реплікації і відхиляються з видачею помилкою (на момент написання статті не працював CREATE TABLE… AS)
3. Визначення таблиць, типів, розширень і т.п. повинні бути ідентичними між upstream і downstream майстрами.
4. Дії які відображаються в WAL, але непредставляється у вигляді логічних змін не реплицируются на інший вузол (запис повних сторінок, вакуумація таблиць і т.п.). Таким чином логічна потоковая реплікація (LLSR) позбавлена ​​від деякої частини накладних витрат які присутні у фізичній потокової реплікації PLSR (проте це не означає що LLSR потрібна менша пропускна здатність мережі ніж для PLSR).
 
Отже мабуть вистачить теорії, трохи практики. Вже зараз є можливість потестувати Bi-Directional реплікацію.
 
Установка виконується на двох віртуальних машинах з CentOS 6.5 minimal. Встановлюємо необхідні для складання пакети:
 
# yum install readline-devel zlib-devel yum-utils -y
# yum groupinstall "Development Tools" -y

Переходимо в акаунт postgres і виконуємо установку postgresql з підтримкою BDR. Тут варто відзначити що хлопці з 2ndQuadrant написали установник щоб бажаючі спробувати ДОДАВАЙТЕ великих зусиль з встановлення та налаштування, за що їм пучок зелені.
 
# su - postgres
$ curl -s "http://git.postgresql.org/gitweb/?p=2ndquadrant_bdr.git;a=blob_plain;f=contrib/bdr/scripts/bdr_quickstart.sh;hb=refs/heads/bdr-next" | bash

Додаємо каталог з виконуваними файлами postgres в змінну оточення PATH і тут же перевіряємо на psql . Хто не знає, команда export одноразова, тому якщо ви плануєте довго використовувати або гратися з BDR, то додайте цю команду в. bashrc вашого користувача (якщо у вас bash звичайно ж).
 
$ export PATH=$HOME/2ndquadrant_bdr/bdr/bin:$PATH
$ psql --version
psql (PostgreSQL) 9.4beta1_bdr0601

Ініціалізіруем каталоги баз даних на обох вузлах після чого відразу ж запускаємо. Попередньо правити postgresql.conf необов'язково, при першому запуску ми створимо тестову базу яка і буде надалі реплицироваться.
 
$ initdb -D data/ -A trust -U postgres
$ pg_ctl -l logfile -D data/ -w start
$ psql -c 'create database staging_db'

Створили базу, після чого переходимо до налаштування postgresql.conf. Спочатку налаштовуємо upstream майстер. У конфігурації нижче, ми вказуємо необхідність завантаження бібліотеки bdr (shared_preload_libraries ), визначаємо рівень подробиці WAL журналів в значення logical (wal_level ), визначаємо кількість слотів для реплікації, максимально можливу кількість процесів зайнятих у відправці WAL журналів (wal_senders ) і включаємо трекінг часу для операції COMMIT що необхідно для вирішення конфліктів (last-UPDATE-wins). Потім в кінці файлу визначаємо конфігурацію для BDR: вказуємо назву з'єднання і налаштування для підключення до віддаленого вузла. Варто відзначити, що ім'я вказано вище в bdr.connections є довільним (у мене це ім'я віртуальної машини), головне що вказане ім'я має брати участь в іменах нижележащих параметрів.
 
$ vi data/postgresql.conf
listen_address = '*'
shared_preload_libraries = 'bdr'
wal_level = logical
wal_senders = 4
max_replication_slots = 4
track_commit_timestamp = on
bdr.connections = 'vm13'
bdr.vm13_dsn = 'host=192.168.122.13 port=5432 user=postgres dbname=staging_db'

Тепер конфігурація downstream майстра. Спочатку привожу опис конфігурації і потім її розбір нижче.
 
$ vi data/postgresql.conf
listen_address = '*'
shared_preload_libraries = 'bdr'
wal_level = logical
wal_senders = 4
max_replication_slots = 4
track_commit_timestamp = on
bdr.connections = 'vm12'
bdr.vm12_dsn = 'host=192.168.122.12 port=5432 user=postgres dbname=staging_db'
bdr.vm12_init_replica = on
bdr.vm12_replica_local_dsn = 'host=127.0.0.1 port=5432 user=postgres dbname=staging_db'

Налаштування другого вузла відрізняється небагатьом, зокрема тут в конфігурації BDR ми вказуємо необхідність виконати ініціалізацію репліки (bdr.vm12_init_replica ) з вузла зазначеного в bdr.vm12_dsn на локальну базу чиї реквізити вказані в bdr.vm12_replica_local_dsn . Останній параметр є обов'язковим у разі якщо кластер БД ініціалізрован за допомогою initdb (якраз наш випадок) і в такому випадку в кластері повинна існувати порожня база яка буде надалі брати участь у реплікації.
У разі ініціалізації через pg_basebackup опція bdr.vm12_replica_local_dsn не потрібна.
 
Тепер визначаємо налаштування аутентифікації на обох вузлах, в моєму випадку все дозволено. Для production інсталяції так звичайно ж робити не можна.
 
$ vi data/pg_hba.conf
host    all             all             192.168.122.0/24        trust
host    replication     postgres        192.168.122.0/24        trust

Виконуємо перезапуск обох вузлів і дивимося журнали
 
$ pg_ctl -l logfile -D data/ -w restart

 upstream майстер: vm12 ~ $ tail-f logfile
LOG: unexpected EOF on standby connection
LOG: starting logical decoding for slot bdr_16384_6029905891437956874_1_16384__
DETAIL: streaming transactions committing after 0/1898F90, reading WAL from 0/1898C30
LOG: logical decoding found consistent point at 0/1898C30
DETAIL: running xacts with xcnt == 0
LOG: starting background worker process «bdr (6029905879776466735,1,16384,): vm13: apply»
 
 downstream майстер: vm13 ~ $ tail-f logfile
LOG: registering background worker «bdr (6029905891437956874,1,16384,): vm12: apply»
LOG: starting background worker process «bdr (6029905891437956874,1,16384,): vm12: apply»
LOG: logical decoding found consistent point at 0/18A4290
DETAIL: running xacts with xcnt == 0
LOG: exported logical decoding snapshot: «0000071B-1» with 0 xids
LOG: starting logical decoding for slot bdr_16384_6029905879776466735_1_16384__
DETAIL: streaming transactions committing after 0/18A42C8, reading WAL from 0/18A4290
LOG: logical decoding found consistent point at 0/18A4290
DETAIL: running xacts with xcnt == 0
 
У журналах все добре і ERROR повідомлень немає (а якщо є, перевіряйте конфіги або грішіть на розробників))). На цьому налаштування та запуск завершений. Тепер можна перевірити роботу через створення таблиць в обох базах.
 
Ще пара моментів. Тимчасова зупинка реплікації здійснюється вимиканням downstream майстра. Проте варто відзначити що зупинена репліка призводить до того що upstream майстер продовжить накопичувати WAL журнали що в свою чергу може привести до неконтрольованого витраті простору на диску. Тому вкрай не рекомендується надовго вимикати репліку.
Видалення репліки назавжди здійснюється через видалення конфігурації BDR на downstream сервері з наступним перезапуском downstream майстра. Потім потрібно видалити відповідний слот реплікації на upstream майстра за допомогою функції pg_drop_replication_slot ('slotname'). Доступні слоти можна переглянути за допомогою функції pg_get_replication_slots ().
  
В якості висновку скажу свої враження… У мене звичайно є деякі питання по експлуатації BDR, відповіді на які, скоріше за все доведеться з'ясовувати дослідно-експериментальним шляхом. Але вже на даному етапі мені подобається цей новий інструмент, налаштовується воно легко і швидко, плюс до цього воно вже працює незважаючи на те, що офіційно з'явиться тільки в 9.5 (а це приблизно через рік). Таким чином, з релізом додасться ще один інструмент з допомогою якого можна буде створювати надійні відмовостійкі конфігурації, і це прекрасно. PostgreSQL від релізу до релізу стає тільки краще і краще.
 
Власне на цьому все. Всім дякую за увагу.
 
P.S. Посилання на почуття:
 BDR User Guide
 Logical Log Streaming Replication
 PostgreSQL WAL Shipping and Streaming Replication
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.