Forretningskontinuitet for databaser
Forretningskontinuitet for databaser betyder, at databaser skal være kontinuerligt operationelle selv under katastrofer. Det er bydende nødvendigt at sikre, at produktionsdatabaser er tilgængelige for applikationerne hele tiden selv under katastroferne, ellers kan det ende med at blive en dyr handel. DBA'er, arkitekter skal sikre, at databasemiljøer kan tåle katastrofer og er SLA-kompatible. For at sikre, at katastrofer ikke påvirker databasens tilgængelighed, skal databaser konfigureres til forretningskontinuitet.
Konfiguration af databaser til forretningskontinuitet involverer en masse arkitektur, planlægning, design og test. En masse faktorer som datacentre og deres geografiske territorier, herunder infrastrukturdesign, kommer i betragtning, når det kommer til at designe og implementere en effektiv katastrofegendannelsesstrategi for databaser. Det forklarer det faktum, at "Forretningskontinuitet =Undgå afbrydelser under katastrofer ”.
For at sikre, at produktionsdatabaser overlever en katastrofe, skal et Disaster Recovery (DR)-sted konfigureres. Produktions- og DR-sites skal være en del af to geografisk fjerntliggende datacentre. Det betyder, at der skal konfigureres en standby-database på DR-stedet for hver produktionsdatabase, således at de dataændringer, der sker på produktionsdatabasen, straks synkroniseres til standby-databasen via transaktionslogs. Dette kan opnås ved "Streaming Replication"-funktion i PostgreSQL.
Hvad skal der ske, hvis katastrofen rammer produktionsdatabasen (eller den primære)?
Når produktionsdatabasen (primær) går ned eller ikke reagerer, skal standby-databasen forfremmes til primær, og applikationerne skal peges på nypromoveret standby-database (ny primær) og det hele skal ske automatisk inden for den udpegede udfalds-SLA. Denne proces kaldes failover.
Konfiguration af PostgreSQL til høj tilgængelighed
Som nævnt ovenfor, for at sikre, at PostgreSQL er disaster recovery-kompatibel, skal den først konfigureres med Streaming Replication (master + standby database) og med automatisk standby promotion/failover-funktioner. Lad os se på, hvordan man konfigurerer streaming-replikering først og efterfulgt af "failover"-processen.
Konfiguration af Standby-database (Streaming-replikering)
Streaming-replikering er den indbyggede funktion i PostgreSQL, som sikrer, at data replikeres fra primær til standby-database via WAL-poster og understøtter både asynkrone og synkrone replikeringsmetoder. Denne måde at replikere på er ret pålidelig og velegnet til miljøer, der kræver realtid og højtydende replikering.
Konfiguration af streaming standby er ret enkel. Det første trin er at sikre, at primære databasekonfigurationer er som følger:
Primær database obligatoriske konfigurationer
Sørg for, at følgende parametre er konfigureret i postgresql.conf på den primære database. Udførelse af følgende ændringer vil kræve en genstart af databasen.
wal_level=logicalwal_level-parameteren sikrer, at de nødvendige oplysninger til replikering skrives til WAL-filerne.
max_wal_senders=1 (or any number more than 0)WAL-poster sendes af wal-afsenderprocessen fra den primære database til standby-databasen. Så ovenstående parameter skal konfigureres til minimum 1. Der kræves mere end en værdi på 1, når der kræves flere wal-afsendere.
Aktiver WAL-arkivering
Der er ingen hård afhængighed af WAL Archiving til streaming replikering. Det anbefales dog kraftigt at konfigurere WAL-arkivering, fordi hvis standby-tilstanden halter bagud, og hvis de nødvendige WAL-filer fjernes fra pg_xlog (eller pg_wal)-mappen, så kræves der arkivfiler for at få standbyen synkroniseret med den primære hvis ikke, skal standbyen genopbygges fra bunden.
archive_mode=on
archive_command=<archive location>Primær database skal konfigureres til at acceptere forbindelser fra standby.
Nedenstående konfiguration skal være der i pg_hba.conf
host replication postgres <standby-database-host-ip>/32 trustTag nu en sikkerhedskopi af den primære database og gendan den samme på DR-webstedet. Når du er færdig med gendannelsen, skal du bygge filen recovery.conf i databiblioteket med nedenstående indhold:
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’Start nu standby-databasen. Streaming-replikeringen skal være aktiveret. Meddelelsen nedenfor i postgresql-logfilen i standby-databasen bekræfter, at streaming-replikering fungerer:
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/CD380170Det konkluderer, at en fuldt funktionel streaming-replikering er på plads. Næste trin for at installere/konfigurere repmgr. Før det, lad os forstå failover-processen.
Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload WhitepaperHvad er Failover?
Failover opstår, når den primære database bliver fuldstændig utilgængelig på grund af en katastrofe. Under failover-processen vil Standby-databasen blive forfremmet til at blive en ny primær database, så applikationer kan fortsætte forretningsdriften.
Automatisk failover
Hele failover-processen skal ske automatisk for at sikre, at effektiv forretningskontinuitet er på plads, og dette kan kun opnås med nogle middleware-værktøjer. Hele ideen er at undgå en manuel indgriben fra DBA'er, udviklere.
Et sådant værktøj, der hjælper med at udføre automatisk failover, er "repmgr".
Lad os tage et kig på repmgr og dets muligheder.
Repmgr
Repmgr er et opensource-værktøj udviklet af 2nd Quadrant. Dette værktøj hjælper med at udføre forskellige databaseadministrative aktiviteter såsom opbygning og overvågning af PostgreSQL-replikering, herunder udførelse af automatiserede failover-aktiviteter i tilfælde af en katastrofe og hjælper også med at udføre overgangsoperationer.
Repmgr er et let at installere værktøj, og konfigurationerne er heller ikke komplekse. Lad os først tage et kig på installationen:
Installation af repmgr
Download værktøjet herfra.
Fjern tarballen og udfør installationen som vist nedenfor:
Jeg har installeret repmgr-4.2.0 på en CentOS 7-vært, og jeg har installeret repmgr mod PostgreSQL-11.1. Før installationen skal du sikre dig, at PostgreSQL bin-biblioteket er en del af $PATH, og at PostgreSQL lib-biblioteket er en del af $LD_LIBRARY_PATH. For at forstå, at repmgr er installeret mod PostgreSQL-11.1, viser jeg outputtet "make install" nedenfor:
[[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/'Konfiguration af repmgr for Automatic Failover
Før man ser på konfigurationen af "repmgr", skal databaserne konfigureres med streaming replikering, som vi har set tidligere. Til at starte med skal både databaserne (primær og standby) konfigureres med følgende parameter i 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)
Ovenstående parameter skal aktivere "repmgrd"-dæmonen, som løbende kører i baggrunden og overvåger streaming-replikeringen. Uden denne parameter er det ikke muligt at udføre automatisk failover. Ændring af denne parameter vil kræve en databasegenstart.
Byg derefter repmgr-konfigurationsfilen (f.eks. med navnet repmgr.conf) for begge databaser. Primær database skal have en konfigurationsfil med følgende indhold:
node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'Placer filen i databiblioteket, i dette tilfælde er det "/data/pgdata11".
Standby-databasekonfigurationsfil skal have følgende indhold:
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
Begge databaser skal være registreret med repmgr.
Registrer primær database
[[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) registeredRegistrer Standby-database
[[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 registeredKør nedenstående kommando for at sikre, at repmgr-logning fungerer.
[[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"
Hvis du kan observere, har jeg konfigureret log_level til DEBUG for at generere detaljeret logning i standbyens repmgr.conf-fil. Tjek logfilerne for replikeringsstatus.
Tjek, om replikeringen fungerer som forventet ved hjælp af 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=2Ovenstående meddelelse bekræfter, at replikeringen kører fint.
Nu, hvis jeg lukker den primære database, skulle repmgrd-dæmonen opdage fejlen i den primære database og skulle fremme standby-databasen. Lad os se, om det sker -Den primære database er stoppet:
[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stoppedStandby-databasen skal fremmes automatisk. Repmgr-loggene ville vise det samme:
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 primaryOvenstående betyder præcist, at repmgr ikke var i stand til at oprette forbindelse til den primære database, og efter 5 mislykkede forsøg forfremmes standbyen til den nye primære database. Nedenfor er det, der viser de promoverede standby (nye primære) databaselogfiler:
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 connectionsJeg har kun nævnt de vigtige parametre i repmgr-konfigurationsfilen. Der er en masse andre parametre, som kan ændres for at opfylde forskellige krav. De andre vigtige parametre er replication_lag_* parametre som vist nedenfor:
#replication_lag_warning=300 # repmgr node check --replication-lag
#replication_lag_critical=600 #Repmgr ville kontrollere tærsklerne for ovenstående parametre, før de fremmer standby. Hvis replikeringsforsinkelse er kritisk, vil promoveringen ikke fortsætte. Hvilket er rigtig godt, for hvis standby bliver fremmet, når der er en forsinkelse, vil det resultere i datatab.
Applikationerne skal sikre, at de genopretter forbindelsen til nyligt promoveret standby inden for den forventede tidsramme. Belastningsbalancerne ville have mulighed for at omdirigere appforbindelserne, når den primære database ikke reagerer. Det andet alternativ ville være at bruge middleware-værktøjer som PgPool-II for at sikre, at alle forbindelser omdirigeres med succes.
For at sikre en vellykket højtilgængelighedsarkitektur implementeres i produktionen, skal der udføres grundig end-to-end test af hele processen. Efter min erfaring bruger vi at betegne denne øvelse som DR DRILL. Det betyder, at hver 6. måned eller deromkring udføres en omstillingshandling for at sikre, at standby bliver forfremmet, og at appforbindelserne genopretter forbindelsen til den promoverede standby. Den eksisterende primære bliver en ny standby. Når overgangen er vellykket, fjernes metrics for at se, at SLA'er er opfyldt.
Hvad er omstilling?
Som forklaret ovenfor er omskiftning en planlagt aktivitet, hvor rollerne som primær- og standby-database skiftes. Det betyder, at Standby bliver primær og primær vil blive standby. Ved at bruge repmgr kan dette opnås. Nedenfor er hvad repmgr gør, når der udsendes omskiftningskommando.
$ 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 completeHvad andet kan repmgr gøre?
- Repmgr kan hjælpe med at opbygge standby-databaserne fra bunden
- Flere standby-databaser kan bygges med én master, der kører
- Cascading standbys kan bygges, hvilket jeg føler er mere fordelagtigt end at konfigurere flere standbys til én masterdatabase
Hvad hvis både primær og standby er væk?
Nå, dette er en situation, hvor virksomheder tænker på at have flere standby-tilfælde. Hvis alle af dem er væk, så er den eneste udvej at gendanne databasen fra sikkerhedskopierne. Dette er grunden til, at en god backup-strategi er bydende nødvendigt. Sikkerhedskopierne skal test-gendannes, valideres regelmæssigt for at sikre, at backups er pålidelige. Infrastrukturdesign til backup skal være sådan, at gendannelse og gendannelse af backups ikke må tage lang tid. Gendannelses- og gendannelsesprocessen af sikkerhedskopierne skal fuldføres inden for den udpegede SLA. SLA'er til backup er designet i forhold til RTO (Recovery Time Objective) og RPO (Recovery Point Objective). Betydning, RTO:tid det tager at gendanne og gendanne sikkerhedskopien skal være inden for SLA og RPO:indtil hvilket tidspunkt gendannelsen blev udført skal være acceptabelt, med andre ord er det datatabstolerance og generelt siger virksomheder 0 datatab tolerance.
Konklusion
- Forretningskontinuitet for PostgreSQL er et vigtigt krav til missionskritiske databasemiljøer. At opnå dette indebærer en masse planlægning og omkostninger.
- Ressourcer og infrastruktur skal udnyttes optimalt for at sikre, at en effektiv katastrofegenopretningsstrategi er på plads.
- Der kan være udfordringer ud fra et omkostningsperspektiv, som skal tages hånd om
- Hvis budgettet tillader det, skal du sikre dig, at der er flere DR-websteder til failover
- I tilfælde af, at sikkerhedskopierne skal gendannes, skal du sørge for, at en god sikkerhedskopieringsstrategi er på plads.