Непрекъсваемост на бизнеса за бази данни
Непрекъсваемостта на бизнеса за бази данни означава, че базите данни трябва да работят непрекъснато дори по време на бедствия. Наложително е да се гарантира, че производствените бази данни са достъпни за приложенията през цялото време дори по време на бедствия, в противен случай това може да се окаже скъпа сделка. DBA, архитектите ще трябва да гарантират, че среди на база данни могат да издържат на бедствия и са съвместими със SLA за възстановяване при бедствия. За да се гарантира, че бедствията не засягат наличността на базата данни, базите данни трябва да бъдат конфигурирани за непрекъснатост на бизнеса.
Конфигурирането на бази данни за непрекъснатост на бизнеса включва много архитектура, планиране, проектиране и тестване. Много фактори като центрове за данни и техните географски територии, включително проектиране на инфраструктура, идват под внимание, когато става въпрос за проектиране и прилагане на ефективна стратегия за възстановяване при бедствия за бази данни. Това обяснява факта, че „Непрекъсваемост на бизнеса =Избягвайте прекъсвания по време на бедствия “.
За да се гарантира, че производствените бази данни ще оцелеят при бедствие, трябва да бъде конфигуриран сайт за възстановяване след бедствие (DR). Производствените и DR обекти трябва да са част от два географски отдалечени центъра за данни. Това означава, че резервната база данни трябва да бъде конфигурирана на сайта на DR за всяка производствена база данни, така че промените в данните, настъпващи в производствената база данни, незабавно да се синхронизират към резервната база данни чрез регистрационни файлове за транзакции. Това може да се постигне чрез възможността за „поточно репликация“ в PostgreSQL.
Какво трябва да се случи, ако бедствие удари производствената (или основната) база данни?
Когато производствената (основната) база данни се срине или стане неотговаряща, резервната база данни трябва да бъде повишена в основна и приложенията трябва да бъдат насочени към новопромотираната резервна (нова основна) база данни и всичко това трябва да се случи автоматично в рамките на определения SLA за прекъсване. Този процес се нарича преодоляване на срив.
Конфигуриране на PostgreSQL за висока наличност
Както беше казано по-горе, за да се гарантира, че PostgreSQL е съвместим с възстановяване след бедствие, той трябва първо да бъде конфигуриран с поточно репликация (главна + резервна база данни) и с възможности за автоматично промоция в режим на готовност/преодоляване на отказ. Нека първо да разгледаме как да конфигурираме стрийминг репликацията и последвано от процеса на „отказ при отказ“.
Конфигуриране на база данни в режим на готовност (поточно репликация)
Поточно репликацията е вградената функция на PostgreSQL, която гарантира, че данните се репликират от първична към резервна база данни чрез WAL записи и поддържа както асинхронни, така и синхронни методи за репликация. Този начин на репликация е доста надежден и подходящ за среди, изискващи репликация в реално време и високопроизводителна репликация.
Конфигурирането на режим на готовност за поточно предаване е доста лесно. Първата стъпка е да се уверите, че конфигурациите на основната база данни са както следва:
Първична база данни задължителни конфигурации
Уверете се, че следните параметри са конфигурирани в postgresql.conf на основната база данни. Извършването на следните промени ще изисква рестартиране на базата данни.
wal_level=logicalПараметърът wal_level гарантира, че информацията, необходима за репликация, се записва в WAL файловете.
max_wal_senders=1 (or any number more than 0)WAL записите се изпращат от процес на изпращач на wal от първичната база данни към резервната база данни. Така че горният параметър трябва да бъде конфигуриран на минимум 1. Необходима е повече от стойност от 1, когато се изискват множество податели на wal.
Активиране на WAL архивиране
Няма твърда зависимост от WAL архивиране за стрийминг репликация. Въпреки това, силно се препоръчва да конфигурирате WAL архивиране, защото, ако режимът на готовност изостава и ако необходимите WAL файлове бъдат премахнати от директорията pg_xlog (или pg_wal), тогава ще са необходими архивни файлове, за да се синхронизира режимът на готовност с основния ако не, режимът на готовност трябва да бъде възстановен от нулата.
archive_mode=on
archive_command=<archive location>Основната база данни трябва да бъде конфигурирана да приема връзки от режим на готовност.
Конфигурацията по-долу трябва да е там в pg_hba.conf
host replication postgres <standby-database-host-ip>/32 trustСега направете резервно копие на основната база данни и я възстановете на сайта на DR. След като приключите с възстановяването, изградете файла recovery.conf в директорията с данни със следното съдържание:
standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’Сега стартирайте резервната база данни. Поточно репликацията трябва да е активирана. Съобщението по-долу в регистрационния файл на postgresql на резервната база данни потвърждава, че репликацията на поточно предаване работи успешно:
2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG: started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG: redo starts at 127/CD380170Това заключава, че е налице напълно функционално стрийминг репликация. Следваща стъпка за инсталиране/конфигуриране на repmgr. Преди това нека разберем процеса на отказ.
Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книгаКакво е Failover?
Отказът се случва, когато основната база данни стане напълно недостъпна поради бедствие. По време на процеса на отказ, базата данни в режим на готовност ще бъде повишена в нова основна база данни, така че приложенията да могат да продължат бизнес операциите.
Автоматично отказване
Целият процес на отказ трябва да се случи автоматично, за да се гарантира ефективна непрекъснатост на бизнеса и това може да се постигне само с някои инструменти за междинен софтуер. Цялата идея е да се избегне ръчна намеса на администратори на база данни, разработчици.
Един такъв инструмент, който помага за извършване на автоматично преминаване при отказ, е „repmgr“.
Нека да разгледаме repmgr и неговите възможности.
Repmgr
Repmgr е инструмент с отворен код, разработен от 2nd Quadrant. Този инструмент помага за извършване на различни административни дейности на базата данни, като изграждане и наблюдение на репликацията на PostgreSQL, включително извършване на автоматизирани дейности за преодоляване на срив в случай на бедствие, а също така помага за извършване на операции по превключване.
Repmgr е лесен за инсталиране инструмент и конфигурациите също не са сложни. Нека първо да разгледаме инсталацията:
Инсталиране на repmgr
Изтеглете инструмента от тук.
Разархивирайте tarball-а и извършете инсталацията, както е показано по-долу:
Инсталирах repmgr-4.2.0 на хост CentOS 7 и инсталирах repmgr срещу PostgreSQL-11.1. Преди инсталирането се уверете, че PostgreSQL bin директорията е част от $PATH, а директорията на библиотеката на PostgreSQL е част от $LD_LIBRARY_PATH. За да разбера, че repmgr е инсталиран срещу PostgreSQL-11.1, показвам изхода „направи инсталиране“ по-долу:
[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755 repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'Конфигуриране на repmgr за автоматично отказване
Преди да разгледаме конфигурирането на „repmgr“, базите данни трябва да бъдат конфигурирани с поточно репликация, която видяхме по-рано. За начало и двете бази данни (основна и резервна) трябва да бъдат конфигурирани със следния параметър в postgresql.conf:
Primary
[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Standby
[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Горният параметър е да активирате демон „repmgrd“, който непрекъснато работи във фонов режим и следи репликацията на поточно предаване. Без този параметър не е възможно да се извърши автоматично преминаване при отказ. Промяната на този параметър ще изисква рестартиране на базата данни.
След това изградете конфигурационния файл repmgr (да речем с името repmgr.conf) и за двете бази данни. Основната база данни трябва да има конфигурационен файл със следното съдържание:
node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'Поставете файла в директорията с данни, в този случай това е „/data/pgdata11“.
Конфигурационният файл на базата данни в режим на готовност трябва да има следното съдържание:
node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'
failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'
monitoring_history=yes
monitor_interval_secs=5
log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG
promote_check_timeout=5
promote_check_interval=1
master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10
И двете бази данни трябва да бъдат регистрирани с repmgr.
Регистриране на основна база данни
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registeredРегистрирайте резервна база данни
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registeredИзпълнете командата по-долу, за да се уверите, че записването на repmgr работи.
[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"
Ако можете да наблюдавате, конфигурирах log_level към DEBUG за генериране на подробно регистриране във файла repmgr.conf на готовност. Проверете регистрационните файлове за състояние на репликация.
Проверете дали репликацията работи според очакванията с помощта на repmgr:
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
1 | node1 | primary | * running | | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
2 | node2 | standby | running | node1 | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2Съобщението по-горе потвърждава, че репликацията работи добре.
Сега, ако изключа основната база данни, демонът repmgrd трябва да открие неизправността на основната база данни и трябва да популяризира резервната база данни. Нека видим дали това се случва -Основната база данни е спряна:
[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stoppedРезервната база данни трябва да се популяризира автоматично. Регистраторите на repmgr ще показват същото:
fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.upstream_node_id = 1 AND n.node_id != 2 AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
"repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primaryГорното точно означава, че repmgr не успя да се свърже с основната база данни и след неуспешни 5 опита, режимът на готовност се прехвърля към новата основна база данни. По-долу е това, което показва промотираните резервни (нови първични) регистрационни файлове на базата данни:
2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not connect to server: Connection refused
Is the server running on host "xxx.xxx.xx.xx" and accepting
TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG: received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG: redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG: last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG: selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG: archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG: checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG: database system is ready to accept connectionsСпоменах само важните параметри в конфигурационния файл repmgr. Има много други параметри, които могат да бъдат модифицирани, за да отговорят на различни изисквания. Другите важни параметри са параметрите replication_lag_*, както е показано по-долу:
#replication_lag_warning=300 # repmgr node check --replication-lag
#replication_lag_critical=600 #Repmgr ще провери праговете на горните параметри, преди да промотира режим на готовност. Ако забавянето на репликацията е критично, промоцията няма да продължи. Което е наистина добре, защото ако режимът на готовност се повиши, когато има забавяне, това би довело до загуба на данни.
Приложенията трябва да гарантират, че се свързват успешно с новопостъпилия режим на готовност в рамките на очаквания срок. Балансьорите на натоварване биха имали способността да пренасочват връзките на приложенията, когато основната база данни престане да реагира. Другата алтернатива би била използването на инструменти за междинен софтуер като PgPool-II, за да се гарантира, че всички връзки се пренасочват успешно.
За да се гарантира успешното внедряване на архитектура с висока достъпност в производството, трябва да се извърши задълбочено тестване от край до край на пълния процес. Според моя опит ние използваме да наричаме това упражнение като DR DRILL. Това означава, че на всеки 6 месеца или около това ще се извършва операция по превключване, за да се гарантира, че режимът на готовност се повишава успешно и връзките на приложенията се свързват успешно към повишения режим на готовност. Съществуващият първичен ще стане нов режим на готовност. След като операцията по превключване е успешна, показателите се премахват, за да се види, че SLA са спазени.
Какво е превключване?
Както беше обяснено по-горе, превключването е планирана дейност, при която ролите на основната и резервната база данни се превключват. Това означава, че режим на готовност ще стане основен, а първичният ще стане режим на готовност. С помощта на repmgr това може да се постигне. По-долу е какво прави repmgr, когато е издадена команда за превключване.
$ repmgr -f /etc/repmgr.conf standby switchover
NOTICE: executing switchover on node "node2" (ID: 2)
INFO: searching for primary node
INFO: checking if node 1 is primary
INFO: current primary node is 1
INFO: SSH connection to host "node1" succeeded
INFO: archive mode is "off"
INFO: replication lag on this standby is 0 seconds
NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
NOTICE: stopping current primary node "node1" (ID: 1)
NOTICE: issuing CHECKPOINT
DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
INFO: checking primary status; 1 of 6 attempts
NOTICE: current primary has been cleanly shut down at location 0/0501460
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
server promoting
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary
INFO: setting node 1's primary to node 2
NOTICE: starting server using "pg_ctl -D '/data/pgdata11' restart"
NOTICE: NODE REJOIN successful
DETAIL: node 1 is now attached to node 2
NOTICE: switchover was successful
DETAIL: node "node2" is now primary
NOTICE: STANDBY SWITCHOVER is completeКакво друго може да направи repmgr?
- Repmgr може да помогне за изграждането на резервни бази данни от нулата
- Могат да бъдат изградени няколко резервни бази данни с един главен работещ
- Може да се изградят каскадни резерви, което според мен е по-изгодно от конфигурирането на множество режими на готовност към една главна база данни
Ами ако и първичният, и режимът на готовност са изчезнали?
Е, това е ситуация, в която бизнесът мисли да има множество екземпляри в режим на готовност. Ако всички те са изчезнали, единственият изход е да възстановите базата данни от резервните копия. Това е причината добрата стратегия за архивиране да е наложителна. Архивите трябва да бъдат тестово възстановени, редовно валидирани, за да се гарантира, че архивите са надеждни. Проектирането на инфраструктурата за архивиране трябва да бъде такова, че възстановяването и възстановяването на архивните копия да не отнема много време. Процесът на възстановяване и възстановяване на архивните копия трябва да бъде завършен в рамките на определения SLA. SLA за архивиране са проектирани от гледна точка на RTO (Цел за време за възстановяване) и RPO (Цел за точка на възстановяване). Значение, RTO:времето, необходимо за възстановяване и възстановяване на архива, трябва да е в рамките на SLA и RPO:до какъв момент е извършено възстановяването трябва да е приемливо, с други думи това е толерантност към загуба на данни и като цяло бизнесът казва 0 загуба на данни толерантност.
Заключение
- Непрекъснатостта на бизнеса за PostgreSQL е важно изискване за критични за мисията среди на бази данни. Постигането на това включва много планиране и разходи.
- Ресурсите и инфраструктурата трябва да се използват оптимално, за да се гарантира, че е налице ефективна стратегия за възстановяване след бедствие.
- Може да има предизвикателства от гледна точка на разходите, за които трябва да се обърне внимание
- Ако бюджетът позволява, уверете се, че има множество DR сайтове за отказ
- В случай, че резервните копия трябва да бъдат възстановени, уверете се, че е налице добра стратегия за архивиране.
