PostgreSQL configureren voor bedrijfscontinuïteit

Bedrijfscontinuïteit voor databases

Bedrijfscontinuïteit voor databases betekent dat databases zelfs tijdens de rampen continu operationeel moeten zijn. Het is absoluut noodzakelijk om ervoor te zorgen dat productiedatabases altijd beschikbaar zijn voor de applicaties, zelfs tijdens de rampen, anders zou het een dure deal kunnen worden. DBA's, architecten zouden ervoor moeten zorgen dat databaseomgevingen rampen kunnen doorstaan en SLA-compatibel zijn voor noodherstel. Om ervoor te zorgen dat rampen de beschikbaarheid van de database niet beïnvloeden, moeten databases worden geconfigureerd voor bedrijfscontinuïteit.

Het configureren van databases voor bedrijfscontinuïteit omvat veel ontwerpen, plannen, ontwerpen en testen. Veel factoren, zoals datacenters en hun geografische gebieden, waaronder infrastructuurontwerp, komen in aanmerking als het gaat om het ontwerpen en implementeren van een effectieve rampherstelstrategie voor databases. Dat verklaart het feit dat "Business Continuity =Voorkom uitval tijdens rampen ”.

Om ervoor te zorgen dat productiedatabases een ramp overleven, moet een Disaster Recovery (DR)-site worden geconfigureerd. Productie- en DR-locaties moeten deel uitmaken van twee geografisch ver verwijderde datacenters. Dit betekent dat er op de DR-locatie voor elke productiedatabase een standby-database moet worden geconfigureerd, zodat de gegevenswijzigingen die in de productiedatabase plaatsvinden onmiddellijk worden gesynchroniseerd met de standby-database via transactielogboeken. Dit kan worden bereikt door de mogelijkheid "Streaming Replication" in PostgreSQL.

Wat moet er gebeuren als een ramp de productie (of primaire) database treft?

Wanneer de (primaire) productiedatabase crasht of niet meer reageert, moet de standby-database worden gepromoveerd naar de primaire database en moeten de toepassingen worden verwezen naar de nieuw gepromote standby-database (nieuwe primaire) en dit alles moet automatisch gebeuren binnen de toegewezen uitval-SLA. Dit proces wordt failover genoemd.

PostgreSQL configureren voor hoge beschikbaarheid

Zoals hierboven vermeld, om ervoor te zorgen dat PostgreSQL compatibel is met noodherstel, moet deze eerst worden geconfigureerd met Streaming Replication (master + standby-database) en met automatische standby-promotie/failover-mogelijkheden. Laten we eerst eens kijken hoe we streaming-replicatie kunnen configureren, gevolgd door het "failover"-proces.

Standby-database configureren (streamingreplicatie)

Streaming-replicatie is de ingebouwde functie van PostgreSQL die ervoor zorgt dat gegevens worden gerepliceerd van de primaire naar de standby-database via WAL-records en ondersteunt zowel asynchrone als synchrone replicatiemethoden. Deze manier van repliceren is redelijk betrouwbaar en geschikt voor omgevingen die realtime en zeer performante replicatie vereisen.

Het configureren van streaming-standby is vrij eenvoudig. De eerste stap is ervoor te zorgen dat de primaire databaseconfiguraties als volgt zijn:

Primaire database verplichte configuraties

Zorg ervoor dat de volgende parameters zijn geconfigureerd in postgresql.conf op de primaire database. Als u de volgende wijzigingen aanbrengt, moet de database opnieuw worden opgestart.

wal_level=logical

wal_level parameter zorgt ervoor dat de informatie die nodig is voor replicatie naar de WAL-bestanden wordt geschreven.

max_wal_senders=1 (or any number more than 0)

WAL-records worden per wal-zenderproces verzonden van de primaire database naar de standby-database. De bovenstaande parameter moet dus worden geconfigureerd op minimaal 1. Meer dan een waarde van 1 is vereist wanneer meerdere walzenders vereist zijn.

WAL-archivering inschakelen

Er is geen harde afhankelijkheid van WAL Archiving voor streamingreplicatie. Het wordt echter sterk aanbevolen om WAL-archivering te configureren, want als de stand-by achterblijft en als de vereiste WAL-bestanden worden verwijderd uit de map pg_xlog (of pg_wal), zijn er archiefbestanden vereist om de stand-by synchroon te laten lopen met de primaire zo niet, dan moet de stand-by opnieuw worden opgebouwd.

archive_mode=on
archive_command=<archive location>

De primaire database moet worden geconfigureerd om verbindingen vanuit stand-by te accepteren.

Onderstaande configuratie moet aanwezig zijn in pg_hba.conf

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

Maak nu een back-up van de primaire database en herstel deze op de DR-site. Als u klaar bent met het herstel, bouwt u het bestand recovery.conf in de gegevensmap met de onderstaande inhoud:

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 de standby-database. De streamingreplicatie moet zijn ingeschakeld. Het onderstaande bericht in het postgresql-logbestand van de standby-database bevestigt dat streamingreplicatie succesvol werkt:

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

Dat concludeert dat er een volledig functionele streaming-replicatie aanwezig is. Volgende stap om repmgr. Laten we eerst het failover-proces begrijpen.

Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaper

Wat is failover?

Failover treedt op wanneer de primaire database volledig niet meer beschikbaar is als gevolg van een ramp. Tijdens het failoverproces wordt de Standby-database gepromoveerd tot een nieuwe primaire database, zodat applicaties de bedrijfsactiviteiten kunnen voortzetten.

Automatische failover

Het hele failoverproces moet automatisch gebeuren om te zorgen voor een effectieve bedrijfscontinuïteit en dit kan alleen worden bereikt door bepaalde middleware-tools. Het hele idee is om een handmatige tussenkomst van DBA's, ontwikkelaars te vermijden.

Een dergelijke tool die helpt bij het uitvoeren van automatische failover is "repmgr".

Laten we eens kijken naar repmgr en zijn mogelijkheden.

Repmgr

Repmgr is een opensource-tool ontwikkeld door 2nd Quadrant. Deze tool helpt bij het uitvoeren van verschillende databasebeheeractiviteiten, zoals het bouwen en bewaken van PostgreSQL-replicatie, inclusief het uitvoeren van geautomatiseerde failover-activiteiten in het geval van een ramp en helpt ook bij het uitvoeren van omschakelingsbewerkingen.

Repmgr is een eenvoudig te installeren tool en de configuraties zijn ook niet ingewikkeld. Laten we eerst de installatie bekijken:

Repmgr installeren

Download de tool hier.

Untar de tarball en voer de installatie uit zoals hieronder getoond:

Ik heb repmgr-4.2.0 op een CentOS 7-host geïnstalleerd en ik heb repmgr tegen PostgreSQL-11.1 geïnstalleerd. Zorg er vóór de installatie voor dat de PostgreSQL-bin-directory deel uitmaakt van $PATH en de PostgreSQL-lib-directory deel uitmaakt van $LD_LIBRARY_PATH. Om te begrijpen dat de repmgr is geïnstalleerd tegen PostgreSQL-11.1, geef ik de onderstaande "make install"-uitvoer weer:

[[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 configureren voor automatische failover

Voordat we kijken naar het configureren van "repmgr", moeten de databases worden geconfigureerd met streamingreplicatie die we eerder hebben gezien. Om te beginnen moeten beide databases (primair en stand-by) worden geconfigureerd met de volgende parameter in 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)

De bovenstaande parameter is om de "repmgrd"-daemon in te schakelen die continu op de achtergrond draait en de streamingreplicatie bewaakt. Zonder deze parameter is het niet mogelijk om automatische failover uit te voeren. Als u deze parameter wijzigt, moet de database opnieuw worden opgestart.
Bouw vervolgens het repmgr-configuratiebestand (zeg met de naam repmgr.conf) voor beide databases. De primaire database moet een configuratiebestand hebben met de volgende inhoud:

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

Plaats het bestand in de datadirectory, in dit geval is het “/data/pgdata11”.

Standby-databaseconfiguratiebestand moet de volgende inhoud hebben:

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

Beide databases moeten geregistreerd zijn bij repmgr.
Registreer primaire 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) registered

Standby-database registreren

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

Voer de onderstaande opdracht uit om ervoor te zorgen dat het loggen van repmgr werkt.

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

Als je kunt zien, heb ik log_level geconfigureerd voor DEBUG om gedetailleerde logboekregistratie te genereren in het repmgr.conf-bestand van de standby-stand. Controleer de logboeken voor de replicatiestatus.
Controleer of de replicatie werkt zoals verwacht met 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

Het bovenstaande bericht bevestigt dat de replicatie goed werkt.

Als ik nu de primaire database afsluit, zou de repmgrd-daemon het falen van de primaire database moeten detecteren en de standby-database moeten promoten. Laten we kijken of dat gebeurt -De primaire database is gestopt:

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

De secundaire database moet automatisch worden gepromoot. De repmgr-logboeken zouden hetzelfde tonen:

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

Het bovenstaande betekent precies dat repmgr geen verbinding kon maken met de primaire database en na 5 mislukte pogingen wordt de standby gepromoveerd naar de nieuwe primaire database. Hieronder ziet u wat de gepromote stand-by (nieuwe primaire) databaselogboeken worden weergegeven:


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

Ik heb alleen de belangrijke parameters in het repmgr-configuratiebestand genoemd. Er zijn veel andere parameters die kunnen worden gewijzigd om aan verschillende vereisten te voldoen. De andere belangrijke parameters zijn replication_lag_* parameters zoals hieronder getoond:

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

Repmgr zou de drempels van bovenstaande parameters controleren voordat stand-by wordt gepromoot. Als replicatievertraging van cruciaal belang is, gaat de promotie niet door. Dat is echt goed, want als stand-by wordt gepromoot als er een vertraging is, zou dat leiden tot gegevensverlies.

De applicaties moeten ervoor zorgen dat ze binnen het verwachte tijdsbestek met succes opnieuw verbinding maken met de nieuw gepromote stand-by. De load balancers zouden de app-verbindingen kunnen omleiden wanneer de primaire database niet meer reageert. Het andere alternatief is het gebruik van middleware-tools zoals PgPool-II om ervoor te zorgen dat alle verbindingen met succes worden omgeleid.

Om ervoor te zorgen dat een succesvolle high-availability-architectuur wordt ingezet in de productie, moeten grondige end-to-end tests van het volledige proces worden uitgevoerd. In mijn ervaring noemen we deze oefening DR DRILL. Dit betekent dat er ongeveer om de zes maanden een omschakeling wordt uitgevoerd om ervoor te zorgen dat stand-by succesvol wordt gepromoot en dat de app-verbindingen opnieuw verbinding maken met de gepromote stand-by. De bestaande primaire wordt een nieuwe stand-by. Zodra de omschakeling is gelukt, worden de statistieken verwijderd om te zien of aan de SLA's wordt voldaan.

Wat is omschakeling?

Zoals hierboven uitgelegd, is Switchover een geplande activiteit waarbij de rollen van Primary en Standby database worden omgewisseld. Dit betekent dat stand-by primair wordt en primair stand-by. Met behulp van repmgr kan dit worden bereikt. Hieronder ziet u wat repmgr doet wanneer de omschakelopdracht wordt gegeven.

$ 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

Wat kan repmgr nog meer doen?

Repmgr kan helpen om de standby-databases helemaal opnieuw op te bouwen
Er kunnen meerdere standby-databases worden gebouwd terwijl één master actief is
Er kunnen trapsgewijze stand-by's worden gebouwd, wat volgens mij voordeliger is dan het configureren van meerdere stand-by's naar één hoofddatabase

Wat als zowel primair als stand-by zijn verdwenen?

Welnu, dit is een situatie waarin bedrijven nadenken over het hebben van meerdere stand-by-instanties. Als ze allemaal weg zijn, is de enige uitweg het herstellen van de database vanaf de back-ups. Dit is de reden waarom een goede back-upstrategie absoluut noodzakelijk is. De back-ups moeten door een test worden hersteld en regelmatig worden gevalideerd om ervoor te zorgen dat de back-ups betrouwbaar zijn. Het infrastructuurontwerp voor back-ups moet zodanig zijn dat herstel en herstel van de back-ups niet lang mag duren. Het herstel- en herstelproces van de back-ups moet worden afgerond binnen de daarvoor bestemde SLA. SLA's voor back-ups zijn ontworpen in termen van RTO (Recovery Time Objective) en RPO (Recovery Point Objective). Betekenis, RTO:de tijd die nodig is om de back-up te herstellen en te herstellen, moet binnen de SLA en RPO vallen:tot welk tijdstip het herstel is uitgevoerd, moet acceptabel zijn, met andere woorden, het is tolerantie voor gegevensverlies en over het algemeen zeggen bedrijven 0 gegevensverlies tolerantie.

Conclusie

Bedrijfscontinuïteit voor PostgreSQL is een belangrijke vereiste voor bedrijfskritieke database-omgevingen. Om dit te bereiken brengt veel planning en kosten met zich mee.
Resources en infrastructuur moeten optimaal worden gebruikt om te zorgen voor een efficiënte strategie voor noodherstel.
Er kunnen uitdagingen zijn vanuit het oogpunt van kosten die moeten worden aangepakt
Als het budget het toelaat, zorg er dan voor dat er meerdere DR-sites zijn voor failover
Als de back-ups moeten worden hersteld, zorg dan voor een goede back-upstrategie.