replikacja w

postgreSQL
Jakub Biernacki
Bartek Lubikowski
Pawe Lesiecki
Log-Shipping Standby Servers
Log-Shipping Standby Servers to metoda replikacji, w ktrej serwery !apasowe "standby or slave
servers# polagaj$ na pr!etwar!aniu plikw b%d$cymi logami generowanymi pr!e! serwer gwny
"primary or master server#&
'i$ga archiwi!acja mo(e by) u(ywana do twor!enia klastrw wysokiej nie!awodno*ci skadaj$cych
si% ! jednego "lub wi%cej# serwera !apasowego, ktry pr!ejmie rol% serwera gwnego w pr!ypadku
jego awarii& Serwer gwny ora! serwery !apasowe pracuj$ wsplnie w celu !apewnienia wysokiej
nie!awodno*ci "high availabilty#& +wny serwer d!iaa w ci$gym trybie archiwi!acji a ka(dy
!apasowy serwer odtwar!a stan gwnego serwera ! plikw ,-L "write-ahead log#& .o!wi$!anie to
nie wymaga (adnych !mian w tabelach ba!y danych, ! tego powodu jest ono atwe i s!ybkie do
wdro(enia w porwnaniu do innych ro!wi$!a/, a tak(e posiada bard!o may wpyw na spadek
wydajno*ci gwnego serwera& Pr!esyanie pliku ,-L jest atwe i s!ybkie pomi%d!y serwerami
nie!ale(nie od odlego*ci, ktra je d!ieli& Pr!epustowo*) $c!a potr!eba do pr!esyania plikw !ale(y
od obci$(enia serwera gwnego&
Pr!esyanie plikw ,-L jest asynchronic!ne, to !nac!y, pliki pr!esyane s$ po !aakceptowaniu
transakcji "commit#& 0 tego powodu istnieje prawdopodobie/stwo utraty danych transakcji nie
pr!esanych pr!ed awari$& 0mniejs!enie ilo*ci danych mo(liwych do utracenia mo(na !minimali!owa)
ustawiaj$c parametr archive_timeout parameter na nisk$ warto*), b$d1 stosuj$c replikacj%
kor!ystaj$c$ ! pr!esyania strumieniowego&
'!as, ktry mija pomi%d!y aktywacj$ serwera !apasowego do jego penego d!iaania jest bard!o
krtki, w porwnaniu do od!yskiwania serwera ! kopii !apasowej& 0 tego powodu warm standby
o2eruj% bard!o wysok$ dost%pno*), nie osi$galn$ pr!y !wykych kopiach !apasowych ba!y danych&
Serwer !apasowy mo(e by) tak(e u(ywany do odc!ytywania danych& 3akie ro!wi$!anie nosi na!w%
hot standby&
Planowanie replikacji
Serwer gwny ora! serwery !apasowe powinny by) mo(liwie podobnie skon2igurowane&
4cie(ki do miejsca gd!ie pr!echowywane s$ tabele na dysku s$ pr!eka!ywane
nie!mody2ikowane pomi%d!y serwerami i mus!$ by) takie same& +dy polecenie CREATE
TABLESPACE jest wykonywane musi !osta) utwor!ony punkt montowania na master!e ora! na
ka(dym slavie pr!ed wykonaniem tego polecenia& Spr!%t !astosowany w serwer!e nie musi by)
taki sam lec!, ! praktyki wynika, (e atwiej skon2igurowa) dwa takie same serwery& Serwery
mus!$ by) identyc!ne je*li chod!i o architektur%& 5ane pr!esane ! serwera 67-bit nie b%d$
d!iaa) na serwer!e 89-bitowym i vice versa&
Pr!esyanie pliku !e !mianami pomi%d!y r(nymi wydaniami gwnymi PostgreS:La nie jest
mo(liwe, natomiast ! powodu nie!mieniania 2ormatu !apisu danych pomi%d!y r(nymi
wydaniami tej samej wersji jest to mo(liwe lec! nie jest w (aden sposb wspierane ani
gwarantowane& , pr!ypadku aktuali!acji wersji w pierws!ej kolejno*ci !aktuali!owane
powinny by) serwery !apasowe a nast%pnie serwer gwny& ,ynika to ! 2aktu, (e jest wi%ks!e
prawdopodobie/stwo, (e nows!a wersja pr!ec!yta plik ,-L !e stars!ej ni( na odwrt&
Praca serwera zapasowego
Serwer !apasowy be! pr!erwy wprowad!a !miany otr!ymane w ,-L ! serwera gwnego&
Serwer !apasowy mo(e odc!ytywa) ,-L be!po*rednio ! archiwum lub be!po*rednio ! serwera
gwnego popr!e! po$c!enie 3'P "je*li !astosowana jest replikacja strumieniowa#& ,
pr!ypadku restartu serwera wprowad!a !miany !nale!ione we ws!ystkich ,-L w katalogu
pg_xlog&
Pr!y starcie serwera !apasowego w pierws!ej kolejno*ci pr!ywracane s$ dost%pne ,-L !
archiwum& ;ast%pnie wykonywane jest polecienie !de2iniowane parametrem
restore_command, je*li wywoanie polecenia si% nie powied!ie pr!ywracane s$ ,-L
!nale!ione w 2older!e pg_xlog& Je*li to te( si% nie powied!ie i w$c!ona jest replikacja
strumieniowa serwer !apasowy stara si% po$c!y) ! serwerem gwnym i !ac!yna wysya)
,-L od ostatniego poprawnego !nale!ionego w 2older!e pg_xlog& Je*li wy$c!ona jest
replikacja strumieniowa lub si% nie powied!ie, procedura !ac!yna si% od nowa&
Serwer !apasowy !mienia tryb na prac% jako normalny serwer natychmiast gdy pg_ctl
promote jest uruchomione lub !nale!iony !ostaje plik skon2igurowany parametrem
trigger_file& Pr!ed uruchomieniem ws!ystkie ,-L dost%pne dla serwera !apasowego s$
pr!ywracane&
Przygotowywanie serwera gwnego
<on2iguracja ci$gej archiwi!acji na serwer!e gwnym powinna !apisywa) do lokali!acji
dost%pnej dla serwera !apasowego nawet po wy$c!eniu serwera gwnego c!yli na serwer!e
!apasowym lub innym !au2anym serwer!e po*rednic!$cym&
Je*li w$c!ona !ostaje replikacja strumieniowa uwier!ytelnianie na serwer!e gwnym powinno
po!woli) serwerom !apasowym na po$c!enie& ;ale(y utwor!y) rol% ora! odpowiednie wpisy
w pg_hba.conf& ;ale(y si% upewni) tak(e, (e max_wal_senders jest ustawiony na
odpowiednio du($ warto*)& ;ale(y utwor!y) poc!$tkow$ kopi% do pierws!ej kon2iguracji
serwer !apasowego u(ywaj$c polecenia= SELECT pg_start_backup('label'); 0r!ut ba!y
nale(y umie*ci) w 2older!e wska!ywanym w komend!ie pr!echowywanej w parametr!e
restore_command&
Przygotowywanie serwera zapasowego
<on2iguracje serwerw !apasowych do pr!ywrcenia danych ! pierws!ej kopii pobranej !
serwera gwnego !ac!yna si% od stwor!enia w pliku recovery.conf komendy !apisanej pod
parametrem recovery_command ora! ustawienia parametru standby_mode na on& <omend%
restore_command ustawiamy jako !wyke kopiowanie plikw ! archiwum ,-L& , pr!ypadku
posiadania kilku serwerw !apasowych dla wysokiej nie!awodno*ci nale(y ustawi) parametr
recovery_target_timeline&
, pr!ypadku kon2igurowania replikacji strumieniowej, nale(y poda) parametry po$c!enia w
parametr!e primary_conninfo !awieraj$ce na!w% hosta "lub adres >P# ora! port, u(ytkownika
i haso&
Je*li serwer !apasowy jest kon2igurowany do !apewnienia wysokiej nie!awodno*ci nale(y
ustawi) archiwi!ajc% ,-L, po$c!enia ora! uwier!ytelnianie tak jak na serwer!e gwnym
poniewa( serwer !apasowy !ac!nie d!iaa) jak serwer gwny po awarii&
Je*li u(ywane jest archiwum ,-L jego ro!miar mo(e by) !mniejs!ony popr!e! kon2iguracj%
parametru archive_cleanup_command aby usuwane byy pliki nie potr!ebne wi%cej pr!e!
serwer !apasowy& 5o tego celu stwor!one jest nar!%d!ie pg_archivecleanup w pr!ypadku
kon2iguracji ! jednym serwerem !apasowym&
Pr!ykadowy plik recovery.conf=
standby_mode = on
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
>lo*) serwerw !apasowych jest nieogranic!ona lec! nale(y ustawi) parametr
max_wal_senders na odpowiedni$ warto*) aby !apewni) im mo(liwo*) rwnoc!esnego
po$c!enia&
Replikacja struieniowa
.eplikacja strumieniowa po!wala serwerom !apasowym na bycie bard!iej aktualnym ni( w
pr!ypadku ro!wi$!ania opartego na pr!esyaniu caych plikw ,-L& Serwer gwny wysya
rekordy ,-L do pod$c!onych serwerw !apasowych be! oc!ekiwania na !apenienie pliku
,-L&
>stnieje pewne op1nienie !anim !miany na serwer!e gwnym stan$ si% widoc!ne na
serwerach !apasowych lec! to op1nienie jest mo(liwie mae w porwnaniu do ro!wi$!ania
opartego na pr!esyaniu caych plikw& ?p1nienie wynika ! asynchronic!no*ci replikacji
strumieniowej& ?p1nienie to wynosi !a!wyc!aj mniej ni( sekund%&
!wierzytelnianie
0 powodu pr!ysyania w strumieniu ,-L wa(nych in2ormacji o pr!ywilejach wa(ne
jest aby da) dost%p do replikacji tylko bard!o !au2anym u(ytkownikom& Serwery
!apasowe mus!$ uwier!ytelnia) si% do serwera gwnego ! pr!ywilejami REPLICATION
ora! LOGIN& @wier!ytelnianie klienta do replikacji kontrolowane jest pr!e! wpisy w
pg"hba#con$& Pr!ykadowo je*li serwer !apasowy jest na adresie 192.168.1.100 a na!wa
konta do replikacji na!ywa si% kowalski, administrator systemu mo(e doda) taki wpis =
host replication kowalski 192.168.1.100/32 md5
;a!wa hosta, numer portu serwera gwnego, na!wa u(ytkownika ora! haso s$ ustalane
w pliku recovery.conf na serwer!e !apasowym& Aaso mo(e by) pr!echowywane
tak(e w pliku %/.pgpass& Pr!ykadowo je*li adres >P gwny serwera to 192.168.1.50,
porcie 542 na!wa konta do replikacji to !oo natomisat haso to bar w pliku
recovery.conf nale(y doda) nast%puj$cy wpis=
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=bar'
&ot Standby
Aot Standby, c!yli Bgor$ca gotowo*)C o!nac!a w Postgresie mo(liwo*) nawi$!ania po$c!enia !
serwerem w trybie c!ytaj$cym "read-only# podc!as gdy serwer pracuje jako serwer !apasowy "lub jest
w procesie pr!ywracania systemu po upadku serwera gwnego#& Serwer operuj$cy w tym trybie nie
powoduje ro!$c!enia aktywnych u(ytkownikw podc!as procesu pr!ywracania systemu& ?dpytywanie
serwera d!iaaj$cego w trybie Bgor$cej gotowo*ciC jest podobne do tego d!iaaj$cego BnormalnieC, s$
jednak pewne ogranic!enia, ktre pr!edstawione s$ poni(ej&
Punkt widzenia u'ytkownika
<iedy parametr hot_standby ma warto*) TRUE "ON lub (# na serwer!e !apasowym, serwer ten
b%d!ie po!wala na po$c!enia tylko wtedy gdy pr!ywracanie systemu !apewni jego pen$
spjno*)& ,s!ystkie po$c!enia ! serwerem pracuj$cym w trybie hot standby po!walaj$
wy$c!nie na c!ytanie "read-only connections#& 3ransakcje na serwer!e opracuj$cym w tym
trybie mog$ !awiera) wi%c nast%puj$ce komendy=
dost%powe= SELECT, COPY TO
!wi$!ane ! kursorem= DECLARE, FETCH, CLOSE
!wi$!ane ! parametrami serwera= SHOW) SET) RESET
!wi$!ane ! samymi transakcjami= BEGIN, END, ABORT, START TRANSACTION,
SAVEPOINT, ROLLBACK TO SAVEPOINT, bloki EXCEPTION i inne&&&
LOCK TABLE "w jednym ! trybw ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE#
PREPARE, EXECUTE, DEALLOCATE, DISCARD
!wi$!ane ! pluginami= LOAD
3ransakcje na serwer!e !apasowym pracuj$cym w trybie hot standby nie maj$ pr!ypisanego >5,
nie mog$ !atem twor!y) plikw ,-L& 5latego nast%puj$ce komendy spowoduj$ b$d=
komendy 5DL "INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE#
komendy 55L "CREATE, DROP, ALTER, COMMENT#
SELECT ... FOR SHARE E UPDATE
komendy LOCK ktra jawnie ($da trybu wy(s!ego ni( ROW EXCLUSIVE MODE&
komendy LOCK be! jawnego (adania odpowiedniego trybu "gdy( domy*lnie jest to
ACCESS EXCLUSIVE MODE#
kommend !wi$!anych ! transakcjami ktre jawnie wprowad!j$ stan non-read-only=
BEGIN READ WRITE, START TRANSACTION READ WRITE
SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS
TRANSACTION READ WRITE
SET transaction_read_only = off
dw2a!owych komitw - PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK
PREPARED poniewa( wymaga to twor!enia plikw ,-L, co jest w tym trybie
niemo(liwe&
komend !wi$!anych !e !mian$ stanu obiektw typu SEQUENCE" nextval(), setval()
LISTEN, UNLISTEN, NOTIFY "BnormalneC transkacje read-only mog$ uaktualnia) obiekty
typu SEQUENCE i u(ywa) komend UNLISTEN i NOTIFY, w pr!ypadku po$c!ania !
serwerem hot standby transakcje te s$ jes!c!e bard!iej restrykcyjne F mo(liwe, (e
ogranic!enie to !niknie w pr!ys!ych wersjach#&
Ponadto, podc!as pracy w trybie hot standby parametr transaction_read_only jest !aws!e
rwny TRUE i warto*) ta nie mo(e by) !mieniona& ?glnie, gdy tylko c!ytamy, ba!a !achwuje
si% dokadnie tak samo jak w pr!ypadku standardowego po$c!enia& Je*li nast$pi !ailover "c!yli
BpadnieC serwer gwny i serwer !apasowy b%d!ie chcia pr!ej$) rol% mastera# lub jawna
!miana ! serwera !apasowego na serwer gwn "np& w celu pr!etestowania c!y nas!a replikacja
d!iaa poprawnie# ba!a !ac!nie pracowa) w normalnym trybie "mo(liwe b%d!ie wykonywanie
transakcji, ktre mody2ikuj$ ba!% F nawet te, ro!poc!%te w trybie hot standby#&
Punkt widzenia adinistratora
By serwer mg pracowa) w trybie hot standby administrator systemu musi ustawi) parametr
hot_standby na TRUE ora! dostarc!y) plik kon2iguracyjny recovery.conf& Serwer pracuj$cy
w trybie hot standby b%d!ie akceptowa po$c!enia tylko wtedy, gdy !najd!ie si% w spjnym
stanie - ka(da prba nawi$!ywania po$c!enia, gdy ba!a nie jest w spjna skutkowa) b%d!ie
b%dem& By dowied!ie) si% c!y po pr!ywracaniu systemu "system recovery# !najduje si% on w
spjnym stanie mo(emy !ajr!e) do logw=
LOG: entering standby mode
... then some time later ...
LOG: consistent recovery state reached
LOG: database system is ready to accept read only connections
;iektre ! parametrw "max_connections, max_prepared_transactions,
max_locks_per_transaction# serwera !apasowego pracuj$cego w trybie hot standby, mus!$
by) pr!ekon2igurowane !godnie ! kon2iguracj$ serwera gwnego& ,arto*ci tych parametrw
mus!$ by) pr!ynajmniej rwne, w pr!eciwnym ra!ie serwer !apasowy nie wystartuje "nie
b%d!ie spenia swojej domy*lnej roli#& <luc!owe mo(e oka!a) si% odpowiednie ustawienie
parametrw max_standby_archive_delay i max_standby_streaming_delay& ,arto*ci dla
tych parametrw !determinnowane s$ pr!e! potr!eby bi!nesowe&
;ast%puj$ce komendy administracyjna s$ nie dost%pne podc!as pracy w trybie hot standby"
CREATE INDEX "i inne komendy ! 55L#, GRANT, REVOKE, REASSIGN, ANALYZE, VACUUM,
CLUSTER, REINDEX& ?c!ywi*cie, je(eli niektre ! tych komend s$ naprawd% potr!ebne mog$
by) wykonane na serwer!e gwnym&
;ar!%d!ie monitoruj$ce check_pgsql b%d!ie pracowa) normalnie w trybie Bgor$cymC, jednak
skrypt monitoruj$cy check_postgres mo(e !wraca) r(ne wyniki, np& last vacuum time nie
jest obsugiwane poniewa( vac##m nie d!iaa na serwer!e pracyj$cym w tym trybie&
<omendy !wi$!ane ! plikami ,-L "pg_start_backup, pg_switch_xlog# nie b%d$ d!iaa)
podc!as pr!ywracania systemu& 5ynamic!nie adowane moduy takie jak pg_stat_statements
d!iaaj$ poprawnie&
Jak wy(ej wspomniano, Bgor$cyC tryb pracy serwera !apasowego umo(liwia tylko operacje
c!ytaj$ce "read-only#, nie ma tu wyj$tku nawet dla twor!enia tabel tymc!asowych, dlatego
skrypty, ktre na nich polegaj$ nie b%d$ d!iaa) poprawnie F ogranic!enie to prawdopodobnie
!niknie w najnows!ych wersjach Postgresa&
,ywoanie komend takich jak ALTER DATABASE ... SET TABLESPACE, DROP DATABASE
skutkuje wygenerowaniem logu WAL co automatyc!nie powoduje natychmiastowe "nie!ale(ne
od parametru max_standby_streaming_delay# ro!$c!enie ws!ystkich u(ytkownikw
maj$cych sesj% na serwer!e !apasowym& Sama !miana na!wy ba!y "ALTER DATABASE ...
RENAME# nie powoduje ro!$c!enia u(ytkownikw, mo(e jednak powodowa) problemy w
aplikacjach polegaj$cych na na!wie ba!y&
Podc!as normalnej pracy serwera "tj& nie podc!as pr!ywracanie systemu# komendy DROP USER
lub DROP ROLE ktre dotyc!$ akutalnie !alogowanego u(ytkownika wykonane na serwer!e
gwnym nie skutkuj$ !ako/c!eniem sesji, jednak prba ponownego po$c!enia nie b%d!ie ju(
mo(liwa&
Paraetry zwi*zane z &ot Standby
serwer gwny
wal_level
vacuum_defer_cleanup_age
serwer !apasowy
hot_standby
max_standby_archive_delay
max_standby_streaming_delay
+on$iguracja replikacji struieniowej
,yagania
5wa serwery ! !ainstalowanym $ebianem %&#ee'e ora! (ostgres&l 9.1 "! ga%!i s&#ee'e-
backports# w poni(s!ej kon2iguracji b%d!iemy pracowa) na dwch hostach=
Master: 192.168.0.1
Slave: 192.168.0.2
+on$iguracja astera
Pierws!a c!ynno*), ktr$ nale(y wykona) to edycja pliku postgresql.conf
root@master:~# vi -w /etc/postgresql/9.1/main/postgresql.conf
;ale(y ods!uka) podane ni(ej !akomentowane linie i edytowa) je w nast%puj$cy sposb =
#listen address = 'localhost' # what IP address(es) to listen on;
listen_addresses = '*'
#wal_level = minimal # minimal, archive, or hot_standby
wal_sevel = hot_standby
#max_wal_senders = 0
max_wal_senders = 3
;ast%pnie nale(y utwor!y) nowego u(ytkownika na serwer!e PostgresS:L !a pomoc$, ktrego
b%d!ie pr!ebiegaa replikacja =
root@master:~# psql -h localhost -U postgres -W -c CREATE USER ruser WITH
REPICATION PASSWORD 'password';
3era! nale(y pr!yd!ieli) nowemu u(ytkownikowi odpowiednie uprawnienia =
root@master:~# vi /etc/postgresql/9.1/main/pg_hba.conf
host replication ruser 192.168.0.2/24 md5
;a koniec nale(y !atr!yma) usug% postgresGl =
root@master:~# service postgresql stop
+on$iguracja slave-a
;a kolejnej mas!ynie rwnie( nale(y edytowa) plik kon2iguracyjny (ostgre%)*
root@slave:~# vi -w /etc/postgresql/9.1/main/postgresql.conf
#listen_addresses = 'localhost'
listen_addresses = '*'
#hot_standby = off
hot_standby = on
;ast%pnie nale(y !atr!yma) usug% ora! wyc!y*ci) t!w& data directory "!waga. ,yc!ys!c!enie
data directory powoduje usuni%cie ws!ystkich danych HHH#
root@slave:~# service postgresql stop
root@slave:~# cd /var/lib/postgresql/9.1/main
root@slave:~# rm -rf *
<olejnym krokiem jest uwtor!enie pliku recovery.conf w data directory
root@slave:~# vi /var/lib/postgresql/9.1/main/recovery.conf
;ast%pnie nale(y u!upeni) go nast%puj$ce in2ormacje =
primary_conninfo = 'host=192.168.0.1 port=5432 user=ruser password=password'
standby_mode = on
!ruchoienie replikacji
;ale(y skopiowa) ws!ystkie dane ! mastera do slaveIa& Do(na to !robi) popr!e! nast%puj$ce
polecenie wykonuj$c je na master!e=
root@master:~# rsync -av /var/lib/postgresql/9.1/main/*
192.168.0.2:/var/lib/postgresql/9.1/main/
;a master!e ora! na slaveIa mo(na tera! uruchomi) usug% postgresGl
root@master:~# service postgresql start
root@slave:~# service postgresql start
3era! mo(na sprawd!i) status replikacji
root@master:~# psql -h localhost -U postgres -W -c SELECT * FROM
pg_stat_replication;
/est
;a master!e nale(y po$c!y) si% do instniej$cej ju( ba!y test
root@master:~# su postgres
postgres@master:~# psql -d test
a nast%pnie utwor!y) testow$ relacje ora! doda) do niej kilka rekordw
CREATE TABLE t1(
id INT PRIMARY KEY,
name VARCHAR(25)
);
INSERT INTO t1 VALUES (1, 'foo');
INSERT INTO t1 VALUES (2, 'bar');
INSERT INTO t1 VALUES (3, 'baz');
INSERT INTO t1 VALUES (4, 'bin');
;a slave rwnie( nale(y po$c!y) si% do ba!y test
root@slave:~# su postgres
postgres@slave:~# psql -d test
ora! sprawd!i) c!y istnieje relacja utwor!ona na master!e
test=# \d
id | name
---+-----
1 | foo
2 | bar
3 | baz
4 | bin
,ida), (e replikacja d!iaa& ;a koniec mo(na sprbowa) !e slaveIa doda) nowy rekord
test=# INSERT INTO t1 VALUES(4, 'asdf');
B D: nie mo na wykona INSERT wewn trz transakcji tylko do odczytu
0adanie
Powy(s!a implementacja reali!uje strumieniow$ replikacj% hot standby. .eplikacje systemw
ba!odanowych c!%sto wykor!ystywane s$ by !apewni) wysok$ nie!awodno*) "high
availability#& 0mody2ikuj powy(s!$ implementacj% by po Bpad!ieC serwera gwnego serwer
!apasowy pr!ej$ jego obowi$!ki staj$c si% jednoc!e*nie nowym serwerem gwnym&