Репликацията в PostgreSQL е много удобен инструмент и има най-различни приложения. Може да се използва за load balancing, backup(може slave сървъра да се държи примерно 1 час след master-а) и т.н.
В PostgreSQL съществуват няколко различни вида репликация. Всички типове репликация разчитат на WAL(Write Ahead Logs). WAL логовете са добавени във версия 7.1. Освен за репликация могат да се използват за backup, restore, point in time recovery и т.н. Самата репликация може бъде няколко вида. В зависимост от това как трансферираме WAL логовте от master сървъра към slave сървъра, репликацията може да е streaming или с копиране на WAL logs. В зависимост от това, дали е допустимо slave сървъра да изостава малко, може репликацията да е syncronous или asyncronous.
Репликацията работи по много прост начин. Всяко query към PostgreSQL сървъра се изпълнява в отделен transaction. Ако има няколко query-та в блок BEGIN; ... COMMIT; всичките те се изпълняват в една транзакция. Основното при танзакциите е че те са атомарни - или всички query-та минават, или нито едно от тях не се изпълнява. След като дадена транзакция се изпълни, промените се записват във WAL log-а. След това този лог се изпраща на slave сървъра и той прилага същите промени. Много е важно да се отбележи, че WAL log-а е в бинарен формат, за разлика от други SQL сървъри, които изпращат plain text sql query-та, които се изпълняват на slave сървъра със идеята, че информацията трябва да е една и съща. Това може да довете до разминаване на инфомацията на master и slave сървъра. В PostgreSQL 9.4 съществува вариант за logical репликация, която разчита на sql заявки, а не на WAL логове, за да предаде информацията на slave съвърите. Този вид репликация е предвиден за създаване на по-сложни логически схеми за репликация като BDR(bidirectional replicatio), multi-master replication, UDR(unidirectional replication).
Тук ще разгледаме само streaming репликация. Тя може да бъде syncronous илиasyncronous и е важно да се отбележат разликите между различните вариации.
При syncronous репликацията, като изпълним една заявка на master сървъра, тя се записва във WAL log-а, и той се изпраща на slave сървъра. След това slave съвърана свой ред записва промените от WAL log-а и чак тогава се счита, че транзакцията е приключила.
При asyncronous репликацията, като се изпълни заявката на master сървъра, тя сезаписва във WAL log-а, и след това се смята, че транзакцията е завършила. Информацията стига до slave сървъра с малко закъснение(lag), което се дължи на това, че данните трябва да се изпратят и приемат на друг физически сървър по мрежата.
Аsyncronous репликацията е по-бърза, но има много малка възможност за загуба наданни, ако нещо се случи със master сървъра, докато изпрати информацията на slave-а. Загубените данни са правопропорционални на lag-а между master и slave сървъра.
Streamig репликацията по принцип е asyncronous. Освен това има възможност за репликация от slave сървър, като по този начин се постига cascading репликация.Няма ограничения, колко поднива slave сървъри може да има, като всеки slave сървър се свързва със сървър от по-горно ниво, като в крайна сметка има едно ново slave сървъри, които се свързват с master сървъра. Cascading репликацията е само asyncronous.
Репликацията в PostgreSQL е изключително лесна. За да опростим описанието на стъпките за конфигуриране на репликация, ще приемем следните дефиниции:
$PG_VERSION = 9.4
$PGDATA = /var/lib/pgsql/$PG_VERSION/data
$MASTER = 192.168.0.1
$SLAVE = 192.168.0.2
Добра практика е репликацията да се извършва в частна мрежа, както и хардуера, който се използва за мрежата да носи само частен трафик за максимална сигурност на данните.
На master сървъра се редакрира $PGDATA/postgresql.conf файла. Трябва да се добавят/променят следните променливи:
listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 3
wal_keep_segments = 8
checkpoint_segments = 8
При добавяне на повече от един slave сървъри max_wal_senders трябва да се увеличи подходящо. Ако slave сървъра не може да насмогне и репликацията се чупи, е добре да се увеличатwal_keep_segments и checkpoint_segments.
На master сървъра трябва да се добави потребител, с който да се извършва репликацията и да му се даде достъп:
В $PGDATA/pg_hba.conf се добавят следните редове:
host replication replicator $SLAVE/32 md5
hostssl replication replicator $SLAVE/32 md5
Ако се добавят повече от един slave сървър, трябва да се добавят съответните редове във файла.
След това трябва да създадем replication портебителя:
psql -c "CREATE USER replication REPLICATION LOGIN ENCRYPTED PASSWORD 'your-password';"
На slave сървъра трябва да копираме basedir-а от master-a:
pg_basebackup -h $MASTER -D $PGDATA -U replication -P -v -x
Трябва да се създаде нов $PGDATA/recovery.conf файл:
primary_conninfo = 'host=$MASTER port=5432 user=replication password=your-password'
trigger_file = '$PGDATA/failover'
standby_mode = 'on'
След успешен failover този файл ще бъде преименуван на recovery.done. Файла дефиниран от trigger_file може да се казва по всякакъв начин и да се намира на произволно място, като трябва да бъде достъпен от потребителя, с който работи PostgreSQL сървъра. Добра практика е този файл да стои в $PGDATA директорията.
Желателно е да се добавят следните опции в primary_conninfo:
keepalives_idle=60
sslmode=require
След това трябва да стартираме PostgreSQL-а на slave сървъра и репликацията трябва да работи. Това можем да го разберем като в списъка с процесите има подобен:
postgres: wal sender process postgres $MASTER(49599) streaming 8EA/124F0E80
Съответно на slave сървъра:
postgres: wal receiver process streaming 8EA/1F5A4DA8
Добре е да проверим дали промените, които правим на master сървъра се отразяват на slave сървъра.При проблеми с репликацията, можем да прегледаме логовете на PostgreSQL сървърите(master и slave), които се намират в $PGDATA/pg_log/ директорията.
Най-важния параметър при мониторинга на репликацията е lag-а между master и slave сървъра. Това можеда се види като се сравнят стойностите, които връщат pg_current_xlog_location на master-а и pg_last_xlog_receive_location функции на slave-а.
psql -c "SELECT pg_current_xlog_location()" -h $MASTER
psql -c "SELECT pg_last_xlog_replay_location()" -h $SLAVE
Големи разлики между pg_current_xlog_location и sent_location на master сървъра показват, че master сървъра не му достигат ресурси, а разлики между sent_location и pg_last_xlog_receive_location на slave сървъра показват, че или на slave-а не му достигат ресурси, или има някакъв проблем с мрежата между съвърите.