Позволете ми да се опитам да го илюстрирам накратко преди тези пачове, всички знаете, че режимът на готовност е критични компоненти за постигане на бързо и безопасно възстановяване при бедствия. В PostgreSQL концепцията за възстановяване основно се занимава с времеви линии за идентифициране на поредица от WAL сегменти преди и след PITR или популяризиране на Standby, за да се избегне припокриване на WAL сегменти. Идентификаторът на времевата линия се асоциира с имената на файлове на сегмента на WAL (напр.:- В $PGDATA/pg_xlog/0000000C000000020000009E сегмент „0000000C“ е идентификатор на времевата линия). При поточно репликация както Primary, така и Slave ще следват един и същ идентификационен номер на времевата линия, но когато Standby получи повишение като нов главен чрез превключване, той повдига ID на времевата линия и старият Primary отказва да се рестартира като Standby поради разлика в идентификатора на времевата линия и извежда съобщение за грешка като:
FATAL: requested timeline 10 is not a child of this server's history
DETAIL: Latest checkpoint is at 2/9A000028 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2/99017E68.
По този начин, нов режим на готовност трябва да бъде изграден от нулата, ако размерът на базата данни е огромен, тогава има по-дълго време за възстановяване и за този период новопромотираният Primary ще работи без Standby. Има и друг проблем, като когато се случи превключването, Основното прави чисто изключване, процесът на Walsender изпраща всички неизпълнени WAL записи в режим на готовност, но не чака те да бъдат репликирани, преди да излезе. Walreceiver не успява да приложи тези неизпълнени WAL записи, тъй като открива затваряне на връзката и излиза.
Днес, с две ключови софтуерни актуализации в PostgreSQL 9.3, и двата проблема са разгледани много добре от авторите, а сега в режим на готовност за поточно репликация следват последователно превключване на времевата линия. Вече можем безпроблемно и безболезнено да превключваме задълженията между първичен и режим на готовност, като просто рестартираме и значително намалим времето за възстановяване на режим на готовност.
Забележка:Превключването/Обратното превключване не е възможно, ако WAL архивите не са достъпни и за двата сървъра и в процеса на превключване Основната база данни трябва да извърши чисто изключване (нормален или бърз режим).
За демонстрация, нека започнем с настройката на поточно репликация (wiki за настройка SR), която съм конфигурирал в моя локална виртуална машина между два клъстера (5432 като първичен и 5433 като режим на готовност), споделящи общо местоположение на WAL архиви, тъй като и двата клъстера трябва да имат пълен достъп на последователност от WAL архиви. Вижте споделената по-долу моментна снимка с подробности за настройката и текущия идентификационен номер на времевата линия за по-добро разбиране на концепцията.
На този етап всеки трябва да има ясно разбиране, че превключването и обратното превключване са планирани дейности. Сега SR настройката е на място, можем да разменим задълженията на първичен и режим на готовност, както е показано по-долу:
Стъпки за превключване:
Стъпка 1. Направете чисто изключване на Primary[5432] (-m бързо или интелигентно)
[postgres@localhost:/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data stop -mf
waiting for server to shut down.... done
server stopped
Стъпка 2. Проверете за състоянието на синхронизиране и състоянието на възстановяване на Standby[5433], преди да го популяризирате:
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c 'select pg_last_xlog_receive_location() "receive_location",
pg_last_xlog_replay_location() "replay_location",
pg_is_in_recovery() "recovery_status";'
receive_location | replay_location | recovery_status
------------------+-----------------+-----------------
2/9F000A20 | 2/9F000A20 | t
(1 row)
Режим на готовност в пълна синхрон. На този етап сме сигурни да го популяризираме като Основен.
Стъпка 3. Отворете режима на готовност като нов първичен чрез pg_ctl популяризиране или създаване на файл за задействане.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ grep trigger_file data_slave/recovery.conf
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_down.txt
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
In Logs:
2014-12-29 00:16:04 PST-26344-- [host=] LOG: trigger file found: /tmp/primary_down.txt
2014-12-29 00:16:04 PST-26344-- [host=] LOG: redo done at 2/A0000028
2014-12-29 00:16:04 PST-26344-- [host=] LOG: selected new timeline ID: 14
2014-12-29 00:16:04 PST-26344-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:16:04 PST-26344-- [host=] LOG: archive recovery complete
2014-12-29 00:16:04 PST-26342-- [host=] LOG: database system is ready to accept connections
2014-12-29 00:16:04 PST-31874-- [host=] LOG: autovacuum launcher started
Режимът на готовност е повишен като главен и се следва нова времева линия, която можете да забележите в регистрационните файлове.
Стъпка 4. Рестартирайте стария Primary като режим на готовност и оставете да следвате новата времева линия, като подадете „recovery_target_timline=’latest’“ във файла $PGDATA/recovery.conf.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ cat data/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5433 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_131_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data start
server starting
Ако преминете през recovery.conf е много ясно, че старият първичен се опитва да се свърже с порт 5433 като нов режим на готовност, насочващ към общото местоположение на WAL архиви и стартира.
In Logs:
2014-12-29 00:21:17 PST-32315-- [host=] LOG: database system was shut down at 2014-12-29 00:12:23 PST
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: entering standby mode
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D00000002000000A0" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: consistent recovery state reached at 2/A0000090
2014-12-29 00:21:17 PST-32315-- [host=] LOG: record with zero length at 2/A0000090
2014-12-29 00:21:17 PST-32310-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:21:17 PST-32325-- [host=] LOG: started streaming WAL from primary at 2/A0000000 on timeline 14
Стъпка 5. Проверете новото състояние на готовност.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)
Страхотно, без повторно настройване върнахме старото Основно като нов режим на готовност.
Стъпки за обратно превключване:
Стъпка 1. Направете чисто изключване на новия първичен [5433]:
[postgres@localhost:/opt/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave stop -mf
waiting for server to shut down.... done
server stopped
Стъпка 2. Проверете за състоянието на синхронизиране на новия режим на готовност [5432], преди да го популяризирате.
Стъпка 3. Отворете новия режим на готовност [5432] като първичен, като създадете тригерен файл или pg_ctl популяризирайте.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt
Стъпка 4. Рестартирането спря нов първичен [5433] като нов режим на готовност.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ more data_slave/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5432 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave start
server starting
Можете да проверите регистрационните файлове на новия режим на готовност.
In logs:
[postgres@localhost:/opt/PostgreSQL/9.3/data_slave/pg_log~]$ more postgresql-2014-12-29_003655.log
2014-12-29 00:36:55 PST-919-- [host=] LOG: database system was shut down at 2014-12-29 00:34:01 PST
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: entering standby mode
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E00000002000000A1" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: consistent recovery state reached at 2/A1000090
2014-12-29 00:36:55 PST-919-- [host=] LOG: record with zero length at 2/A1000090
2014-12-29 00:36:55 PST-914-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:36:55 PST-929-- [host=] LOG: started streaming WAL from primary at 2/A1000000 on timeline 15
2014-12-29 00:36:56 PST-919-- [host=] LOG: redo starts at 2/A1000090
Много хубаво, без много време сменихме задълженията на първичния и резервния сървър. Можете дори да забележите увеличението на идентификаторите на времевата линия от регистрационните файлове за всяка промоция.
Подобно на други всички мои публикации са част от споделянето на знания, всякакви коментари или корекции са добре дошли. 🙂
