PostgreSQL hög tillgänglighet med Master-Slave &Master-Master-arkitekturer

Nedan finns ett utdrag ur vårt whitepaper "PostgreSQL Management and Automation with ClusterControl" som kan laddas ner gratis.

Revisionsnotering: Tänk på att termerna som används i den här bloggen Master-Slave är synonyma med Master-Standby-termer som används av PostgreSQL. Vi använder Master-Slave för att behålla parallelliteten med andra teknologier.

För HA-konfiguration kan vi ha flera arkitekturer, men de grundläggande skulle vara master-slave och master-master-arkitekturer. Databasservrar kan arbeta tillsammans för att tillåta en andra server att ta över snabbt om den primära servern misslyckas (hög tillgänglighet ), eller för att tillåta flera datorer att betjäna samma data (belastningsbalansering).

PostgreSQL Master-Slave Architectures

Dessa arkitekturer gör det möjligt för oss att upprätthålla en huvuddatabas med en eller flera standbyservrar redo att ta över driften om den primära servern misslyckas. Dessa standby-databaser förblir synkroniserade (eller nästan synkroniserade) med mastern.

Replikeringen mellan mastern och slavarna kan göras via SQL-satser (logiska standbys) eller via de interna datastrukturändringarna (fysiska standbys). PostgreSQL använder en ström av WAL-poster (write-ahead log) för att hålla standby-databaserna synkroniserade. Om huvudservern misslyckas innehåller standby-läget nästan all data från huvudservern och kan snabbt göras till den nya huvuddatabasservern. Detta kan vara synkront eller asynkront och kan endast göras för hela databasservern.

Att ställa in streamingreplikering är en uppgift som kräver att vissa steg måste följas noggrant. För dessa steg och lite mer bakgrund om detta ämne, se:Bli en PostgreSQL DBA - Hur man ställer in strömmande replikering för hög tillgänglighet.

Från version 10 innehåller PostgreSQL möjligheten att ställa in logisk replikering.

Logisk replikering tillåter en databasserver att skicka en ström av datamodifieringar till en annan server. PostgreSQL logisk replikering konstruerar en ström av logiska datamodifieringar från WAL. Logisk replikering gör att dataändringarna från enskilda tabeller kan replikeras. Det kräver inte att en viss server utses som en master eller en replik, men tillåter data att flöda i flera riktningar.

Du kan hitta mer information om logisk replikering:Blogg:En översikt över logisk replikering i PostgreSQL.

För att effektivt säkerställa hög tillgänglighet räcker det inte med en master-slave-arkitektur. Vi måste också aktivera någon automatisk form av failover, så om något misslyckas kan vi ha minsta möjliga fördröjning med att återuppta normal funktionalitet. PostgreSQL inkluderar inte en automatisk failover-mekanism för att identifiera fel på huvuddatabasen och meddela salven att ta ägarskap, så det kommer att kräva lite arbete på DBA:s sida. Du bör arbeta med ett skript som innehåller kommandot pg_ctl promote, som kommer att marknadsföra slaven som en ny master. Det finns också några tredjepartsverktyg för denna automatisering. Många sådana verktyg finns och är väl integrerade med de operativsystem som krävs för framgångsrik failover, såsom IP-adressmigrering.

Efter en failover måste du ändra din applikation för att fungera med den nya mastern. Du kommer också att ha bara en server som fungerar, så återskapandet av master-slave-arkitekturen måste göras, så att vi återgår till samma normala situation som vi hade innan problemet.

PostgreSQL Master-Master-arkitekturer

Denna arkitektur ger ett sätt att minimera effekten av ett fel i en av noderna, eftersom den andra noden kan ta hand om all trafik, kanske påverka prestandan något, men aldrig förlora funktionalitet. Det används också för att åstadkomma (och kanske är detta till och med en mer intressant punkt) horisontell skalbarhet (utskalning), i motsats till konceptet med vertikal skalbarhet där vi lägger till mer resurser till en server (uppskalning).

För att implementera den här arkitekturen måste du använda externa verktyg, eftersom den här funktionen inte (ännu) stöds av PostgreSQL.

Du måste vara mycket försiktig när du väljer en lösning för implementering av master-master, eftersom det finns många olika produkter. Många av dem är fortfarande "gröna", med få seriösa användare eller framgångsfall. Vissa andra projekt har å andra sidan övergivits, eftersom det inte finns några aktiva underhållare.

För mer information om tillgängliga verktyg, se:Blogg:Top PG Clustering HA Solutions for PostgreSQL.

Lastbalansering och anslutningspoolning

Det finns flera lastbalanseringsverktyg som kan användas för att hantera trafiken från din applikation för att få ut det mesta av din databasarkitektur. På samma sätt finns det några andra som kan hjälpa dig att hantera hur applikationen ansluter till databasen, genom att slå samman dessa anslutningar och återanvända dem mellan olika förfrågningar.

Det finns några produkter som används för båda ändamålen, som den välkända pgpool, och några andra som kommer att fokusera på endast en av dessa funktioner, som pgbouncer (anslutningspooling) och HAProxy (används för lastbalansering).