Hoge beschikbaarheid van PostgreSQL met master-slave- en master-masterarchitecturen

Hieronder vindt u een fragment uit onze whitepaper "PostgreSQL-beheer en -automatisering met ClusterControl", die gratis kan worden gedownload.

Opmerking bij herziening:Houd er rekening mee dat de termen die in deze blog Master-Slave worden gebruikt, synoniem zijn aan Master-Standby-termen die worden gebruikt door PostgreSQL. We gebruiken Master-Slave om het parallellisme met andere technologieën te behouden.

Voor HA-configuratie kunnen we verschillende architecturen hebben, maar de basisarchitecturen zijn master-slave- en master-master-architecturen. Databaseservers kunnen samenwerken zodat een tweede server het snel kan overnemen als de primaire server uitvalt (hoge beschikbaarheid ), of om meerdere computers dezelfde gegevens te laten bedienen (taakverdeling).

PostgreSQL Master-Slave-architecturen

Deze architecturen stellen ons in staat om een ​​masterdatabase te onderhouden met een of meer standby-servers die klaar staan ​​om de operaties over te nemen als de primaire server uitvalt. Deze standby-databases blijven gesynchroniseerd (of bijna gesynchroniseerd) met de master.

De replicatie tussen de master en de slaves kan worden gedaan via SQL-statements (logische standbys) of via de interne gegevensstructuurwijzigingen (fysieke standbys). PostgreSQL gebruikt een stroom van WAL-records (write-ahead log) om de standby-databases gesynchroniseerd te houden. Als de hoofdserver uitvalt, bevat de stand-by bijna alle gegevens van de hoofdserver en kan snel de nieuwe hoofddatabaseserver worden gemaakt. Dit kan synchroon of asynchroon zijn en kan alleen worden gedaan voor de hele databaseserver.

Het instellen van streamingreplicatie is een taak waarvoor enkele stappen grondig moeten worden gevolgd. Voor deze stappen en wat meer achtergrondinformatie over dit onderwerp, zie:Word een PostgreSQL DBA - Streaming-replicatie instellen voor hoge beschikbaarheid.

Vanaf versie 10 bevat PostgreSQL de optie om logische replicatie in te stellen.

Met logische replicatie kan een databaseserver een stroom gegevenswijzigingen naar een andere server sturen. Met logische postgreSQL-replicatie wordt een stroom van logische gegevenswijzigingen van de WAL geconstrueerd. Met logische replicatie kunnen de gegevenswijzigingen van afzonderlijke tabellen worden gerepliceerd. Er hoeft geen bepaalde server als master of replica te worden aangewezen, maar gegevens kunnen in meerdere richtingen stromen.

U kunt meer informatie over logische replicatie vinden:Blog:een overzicht van logische replicatie in PostgreSQL.

Om een ​​hoge beschikbaarheid effectief te garanderen, is het niet voldoende om een ​​master-slave-architectuur te hebben. We moeten ook een of andere automatische vorm van failover inschakelen, dus als er iets mislukt, kunnen we de kleinst mogelijke vertraging hebben bij het hervatten van de normale functionaliteit. PostgreSQL bevat geen automatisch failover-mechanisme om fouten in de hoofddatabase te identificeren en de zalf op de hoogte te stellen om eigenaar te worden, dus dat vereist wat werk aan de kant van de DBA. Je zou aan een script moeten werken dat het pg_ctl promote-commando bevat, dat de slave als een nieuwe master zal promoten. Er zijn ook enkele tools van derden voor deze automatisering. Veel van dergelijke tools bestaan ​​en zijn goed geïntegreerd met de besturingssysteemfaciliteiten die nodig zijn voor een succesvolle failover, zoals IP-adresmigratie.

Nadat een failover heeft plaatsgevonden, moet u uw toepassing dienovereenkomstig aanpassen om met de nieuwe master te werken. Je hebt ook maar één server die werkt, dus de master-slave-architectuur moet opnieuw worden gemaakt, zodat we teruggaan naar dezelfde normale situatie die we hadden vóór het probleem.

PostgreSQL Master-Master Architecturen

Deze architectuur biedt een manier om de impact van een fout in een van de knooppunten te minimaliseren, aangezien het andere knooppunt voor al het verkeer kan zorgen, misschien de prestaties enigszins beïnvloedend, maar nooit functionaliteit verliest. Het wordt ook gebruikt om (en misschien is dit zelfs een interessanter punt) horizontale schaalbaarheid (scale-out) te bereiken, in tegenstelling tot het concept van verticale schaalbaarheid waarbij we meer bronnen aan een server toevoegen (scale-up).

Voor het implementeren van deze architectuur heb je externe tools nodig, aangezien deze functie (nog) niet native wordt ondersteund door PostgreSQL.

Je moet heel voorzichtig zijn bij het kiezen van een oplossing voor het implementeren van master-master, omdat er veel verschillende producten zijn. Veel van hen zijn nog steeds "groen", met weinig serieuze gebruikers of succesgevallen. Sommige andere projecten zijn daarentegen stopgezet, omdat er geen actieve beheerders zijn.

Raadpleeg voor meer informatie over de beschikbare tools:Blog:Top PG Clustering HA-oplossingen voor PostgreSQL.

Load Balancing en Connection Pooling

Er zijn verschillende load balancer-tools die kunnen worden gebruikt om het verkeer van uw toepassing te beheren om het meeste uit uw database-architectuur te halen. Op dezelfde manier zijn er nog andere die u kunnen helpen bij het beheren van de manier waarop de toepassing verbinding maakt met de database, door deze verbindingen te bundelen en ze opnieuw te gebruiken tussen verschillende verzoeken.

Sommige producten worden voor beide doeleinden gebruikt, zoals het bekende pgpool, en andere die zich op slechts één van deze functies richten, zoals pgbouncer (pooling van verbindingen) en HAProxy (gebruikt voor taakverdeling).