Konfigurera PostgreSQL för Business Continuity

Business Continuity för databaser

Affärskontinuitet för databaser innebär att databaser måste vara kontinuerligt i drift även under katastroferna. Det är absolut nödvändigt att se till att produktionsdatabaser är tillgängliga för applikationerna hela tiden även under katastroferna, annars kan det bli en dyr affär. DBA:er, arkitekter skulle behöva se till att databasmiljöer kan uthärda katastrofer och är SLA-kompatibla för katastrofåterställning. För att säkerställa att katastrofer inte påverkar databasens tillgänglighet måste databaser konfigureras för kontinuitet i verksamheten.

Att konfigurera databaser för affärskontinuitet innebär mycket arkitektur, planering, design och testning. Många faktorer som datacenter och deras geografiska territorier inklusive infrastrukturdesign kommer i beaktande när det gäller att designa och implementera en effektiv katastrofåterställningsstrategi för databaser. Det förklarar det faktum att "Business Continuity =Undvik avbrott under katastrofer ”.

För att säkerställa att produktionsdatabaser överlever en katastrof måste en DR-plats (Disaster Recovery) konfigureras. Produktions- och DR-platser måste vara en del av två geografiskt avlägsna datacenter. Detta innebär att en reservdatabas måste konfigureras på DR-platsen för varje produktionsdatabas så att dataändringarna som sker i produktionsdatabasen omedelbart synkroniseras till standbydatabasen via transaktionsloggar. Detta kan uppnås genom "Streaming Replication"-kapacitet i PostgreSQL.

Vad måste hända om en katastrof inträffar i produktionsdatabasen (eller den primära) databasen?

När produktionsdatabasen (primär) kraschar eller inte svarar, måste standby-databasen flyttas upp till primär och applikationerna måste hänvisas till nyligen marknadsförd standby-databas (ny primär) och allt måste ske automatiskt inom den utsedda avbrotts-SLA:n. Denna process kallas för failover.

Konfigurera PostgreSQL för hög tillgänglighet

Som nämnts ovan, för att säkerställa att PostgreSQL är disaster recovery-kompatibel, måste den först konfigureras med Streaming Replication (master + standby databas) och med automatisk standby promotion/ failover-funktioner. Låt oss titta på hur man konfigurerar strömmande replikering först och följt av "failover"-processen.

Konfigurera standby-databas (strömmande replikering)

Strömmande replikering är den inbyggda funktionen i PostgreSQL som säkerställer att data replikeras från primär till standby-databas via WAL-poster och stöder både asynkrona och synkrona replikeringsmetoder. Det här sättet att replikera är ganska tillförlitligt och lämpligt för miljöer som kräver realtids- och högpresterande replikering.

Att konfigurera strömningsstandby är ganska enkelt. Det första steget är att se till att primära databaskonfigurationer är följande:

Obligatoriska konfigurationer för primär databas

Se till att följande parametrar är konfigurerade i postgresql.conf på den primära databasen. Om du gör följande ändringar krävs en omstart av databasen.

wal_level=logical

wal_level-parametern säkerställer att informationen som krävs för replikering skrivs till WAL-filerna.

max_wal_senders=1 (or any number more than 0)

WAL-poster skickas via wal-avsändarprocessen från den primära databasen till standby-databasen. Så parametern ovan måste konfigureras till minst 1. Mer än ett värde på 1 krävs när flera wal-avsändare krävs.

Aktivera WAL-arkivering

Det finns inget hårt beroende av WAL Archiving för strömmande replikering. Det rekommenderas dock starkt att konfigurera WAL-arkivering eftersom, om vänteläget släpar efter och om de nödvändiga WAL-filerna tas bort från katalogen pg_xlog (eller pg_wal), då kommer arkivfiler att krävas för att få vänteläget synkroniserat med den primära om inte måste standby-läget byggas om från början.

archive_mode=on
archive_command=<archive location>

Primär databas måste konfigureras för att acceptera anslutningar från vänteläge.

Nedanstående konfiguration måste finnas i pg_hba.conf

host    replication     postgres        <standby-database-host-ip>/32            trust

Ta nu en säkerhetskopia av den primära databasen och återställ densamma på DR-webbplatsen. När du är klar med återställningen, bygg filen recovery.conf i datakatalogen med innehållet nedan:

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’

Starta nu standby-databasen. Strömmande replikering måste vara aktiverad. Meddelandet nedan i postgresql-loggfilen i standby-databasen bekräftar att strömmande replikering fungerar framgångsrikt:

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

Det drar slutsatsen att en fullt fungerande streamingreplikering är på plats. Nästa steg för att installera/konfigurera repmgr. Innan det, låt oss förstå failover-processen.

Ladda ner Whitepaper Today PostgreSQL Management &Automation med ClusterControlLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala PostgreSQLDladda Whitepaper

Vad är failover?

Failover inträffar när den primära databasen blir helt otillgänglig på grund av en katastrof. Under failover-processen kommer Standby-databasen att främjas till att bli en ny primär databas så att applikationer kan fortsätta verksamheten.

Automatisk failover

Hela failover-processen måste ske automatiskt för att säkerställa effektiv affärskontinuitet på plats och detta kan endast uppnås med vissa middleware-verktyg. Hela idén är att undvika manuell inblandning av DBA:er, utvecklare.

Ett sådant verktyg som hjälper till att utföra automatisk failover är "repmgr".

Låt oss ta en titt på repmgr och dess möjligheter.

Repmgr

Repmgr är ett opensource-verktyg utvecklat av 2nd Quadrant. Det här verktyget hjälper till att utföra olika databasadministrativa aktiviteter som att bygga och övervaka PostgreSQL-replikering inklusive att utföra automatiska failover-aktiviteter i händelse av en katastrof och hjälper också till att utföra övergångsoperationer.

Repmgr är ett lättinstallerat verktyg och konfigurationerna är inte heller komplicerade. Låt oss ta en titt på installationen först:

Installerar repmgr

Ladda ner verktyget härifrån.

Ta bort tarbollen och utför installationen enligt nedan:

Jag har installerat repmgr-4.2.0 på en CentOS 7-värd och jag har installerat repmgr mot PostgreSQL-11.1. Se till att PostgreSQL bin-katalogen är en del av $PATH och att PostgreSQL lib-katalogen är en del av $LD_LIBRARY_PATH. För att förstå att repmgr är installerat mot PostgreSQL-11.1, visar jag utmatningen "make install" nedan:

[[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/'

Konfigurera repmgr för Automatic Failover

Innan man tittar på att konfigurera "repmgr", måste databaserna konfigureras med strömmande replikering som vi har sett tidigare. Till att börja med måste båda databaserna (primär och standby) konfigureras med följande 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)

Ovanstående parameter är att aktivera "repmgrd"-demonen som kontinuerligt körs i bakgrunden och övervakar strömmande replikering. Utan denna parameter är det inte möjligt att utföra automatisk failover. För att ändra denna parameter krävs en omstart av databasen.
Bygg sedan repmgr-konfigurationsfilen (säg med namnet repmgr.conf) för båda databaserna. Primär databas måste ha en konfigurationsfil med följande innehåll:

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Placera filen i datakatalogen, i det här fallet är det "/data/pgdata11".

Standby-databaskonfigurationsfilen måste ha följande innehåll:

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

Båda databaserna måste vara registrerade med repmgr.
Registrera primär databas

[[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

Registrera 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 registered

Kör kommandot nedan för att säkerställa att repmgr-loggning fungerar.

[[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"

Om du kan observera har jag konfigurerat log_level till DEBUG för att generera detaljerad loggning i standby-filen repmgr.conf. Kontrollera loggarna för replikeringsstatus.
Kontrollera om replikeringen fungerar som förväntat med 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

Meddelandet ovan bekräftar att replikeringen fungerar bra.

Om jag nu stänger av den primära databasen, bör repmgrd-demonen upptäcka felet i den primära databasen och främja standby-databasen. Låt oss se om det händer -Den primära databasen stoppas:

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

Standbydatabasen måste främjas automatiskt. Repmgr-loggarna skulle visa samma:

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

Ovanstående betyder exakt att repmgr inte kunde ansluta till den primära databasen och efter 5 misslyckade försök flyttas vänteläget upp till den nya primära databasen. Nedan är vad som visar de marknadsförda standby-databasloggarna (nya primära):


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

Jag har bara nämnt de viktiga parametrarna i repmgr-konfigurationsfilen. Det finns många andra parametrar som kan modifieras för att uppfylla olika krav. De andra viktiga parametrarna är replication_lag_* parametrar som visas nedan:

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr skulle kontrollera tröskelvärdena för ovanstående parametrar innan du främjar standby. Om replikeringsfördröjningen är kritisk kommer marknadsföringen inte att genomföras. Vilket är riktigt bra för om vänteläge främjas när det finns en fördröjning som skulle resultera i dataförlust.

Applikationerna måste säkerställa att de återansluter till nyligen marknadsfört standby-läge inom den förväntade tidsramen. Lastbalanserarna skulle ha förmågan att avleda appanslutningarna när den primära databasen inte svarar. Det andra alternativet skulle vara att använda middleware-verktyg som PgPool-II för att säkerställa att alla anslutningar omdirigeras framgångsrikt.

För att säkerställa att en framgångsrik arkitektur med hög tillgänglighet används i produktionen, måste grundliga tester från hela processen utföras. Enligt min erfarenhet brukar vi kalla denna övning som DR DRILL. Det innebär att var 6:e månad eller så, skulle en övergångsoperation utföras för att säkerställa att vänteläge framgångsrikt främjas och att appanslutningarna återansluts till det befordrade vänteläget. Den befintliga primära kommer att bli en ny standby. När övergången är framgångsrik tas mätvärden ner för att se SLA:er uppfylls.

Vad är övergång?

Som förklarats ovan är Switchover en planerad aktivitet där rollerna för Primär- och Standby-databas växlas över. Det betyder att Standby blir primär och primär kommer att bli standby. Med repmgr kan detta uppnås. Nedan är vad repmgr gör när switchover-kommandot utfärdas.

$ 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

Vad mer kan repmgr göra?

Repmgr kan hjälpa till att bygga standby-databaserna från början
Flera standby-databaser kan byggas med en master igång
Cascading standbys kan byggas vilket jag anser är mer fördelaktigt än att konfigurera flera standbys till en huvuddatabas

Vad händer om både Primär och Standby är borta?

Tja, det här är en situation där företag funderar på att ha flera standby-instanser. Om alla är borta är den enda utvägen att återställa databasen från säkerhetskopiorna. Detta är anledningen till att en bra säkerhetskopieringsstrategi är absolut nödvändig. Säkerhetskopiorna måste test-återställas, valideras regelbundet för att säkerställa att säkerhetskopiorna är tillförlitliga. Infrastrukturdesign för säkerhetskopior måste vara sådan att återställning och återställning av säkerhetskopiorna inte får ta lång tid. Återställnings- och återställningsprocessen av säkerhetskopiorna måste slutföras inom den angivna SLA:n. SLA:er för säkerhetskopiering är utformade i termer av RTO (Recovery Time Objective) och RPO (Recovery Point Objective). Betyder, RTO:tiden det tar att återställa och återställa säkerhetskopian måste vara inom SLA och RPO:tills vilken tidpunkt återställningen gjordes måste vara acceptabel, i andra termer är det tolerans för dataförlust och i allmänhet säger företag 0 dataförlust tolerans.

Slutsats

Affärskontinuitet för PostgreSQL är ett viktigt krav för verksamhetskritiska databasmiljöer. Att uppnå detta kräver mycket planering och kostnader.
Resurser och infrastruktur måste utnyttjas optimalt för att säkerställa en effektiv katastrofåterställningsstrategi.
Det kan finnas utmaningar ur kostnadsperspektiv som måste tas om hand
Om budgeten tillåter, se till att det finns flera DR-webbplatser för failover
Om säkerhetskopiorna ska återställas, se till att en bra säkerhetskopieringsstrategi finns på plats.