PostgreSQL høj tilgængelighed med Master-Slave &Master-Master-arkitekturer

Nedenfor er et uddrag fra vores hvidbog "PostgreSQL Management and Automation with ClusterControl", som kan downloades gratis.

Revisionsbemærkning: Husk, at de termer, der bruges i denne blog Master-Slave, er synonyme med Master-Standby-termer, der bruges af PostgreSQL. Vi bruger Master-Slave til at bevare paralleliteten med andre teknologier.

Til HA-konfiguration kan vi have flere arkitekturer, men de grundlæggende ville være master-slave og master-master-arkitekturer. Databaseservere kan arbejde sammen for at tillade en anden server at tage over hurtigt, hvis den primære server fejler (høj tilgængelighed) ), eller for at tillade flere computere at betjene de samme data (belastningsbalancering).

PostgreSQL Master-Slave Architectures

Disse arkitekturer gør det muligt for os at vedligeholde en masterdatabase med en eller flere standby-servere klar til at overtage driften, hvis den primære server svigter. Disse standby-databaser forbliver synkroniserede (eller næsten synkroniserede) med masteren.

Replikationen mellem masteren og slaverne kan foretages via SQL-sætninger (logiske standbys) eller via de interne datastrukturændringer (fysiske standbys). PostgreSQL bruger en strøm af WAL-poster (Write-ahead-log) til at holde standby-databaserne synkroniserede. Hvis hovedserveren svigter, indeholder standby næsten alle data fra hovedserveren og kan hurtigt gøres til den nye masterdatabaseserver. Dette kan være synkront eller asynkront og kan kun gøres for hele databaseserveren.

Opsætning af streamingreplikering er en opgave, der kræver nogle trin, der skal følges grundigt. For disse trin og lidt mere baggrund om dette emne, se venligst:Bliv en PostgreSQL DBA - Sådan konfigureres streamingreplikering for høj tilgængelighed.

Fra version 10 inkluderer PostgreSQL muligheden for at opsætte logisk replikering.

Logisk replikering gør det muligt for en databaseserver at sende en strøm af dataændringer til en anden server. PostgreSQL logisk replikering konstruerer en strøm af logiske datamodifikationer fra WAL. Logisk replikering gør det muligt at replikere dataændringer fra individuelle tabeller. Det kræver ikke, at en bestemt server udpeges som en master eller en replika, men tillader data at flyde i flere retninger.

Du kan finde flere oplysninger om logisk replikering:Blog:En oversigt over logisk replikering i PostgreSQL.

For effektivt at sikre høj tilgængelighed er det ikke nok at have en master-slave-arkitektur. Vi skal også aktivere en eller anden automatisk form for failover, så hvis noget fejler, kan vi have den mindst mulige forsinkelse i at genoptage normal funktionalitet. PostgreSQL inkluderer ikke en automatisk failover-mekanisme til at identificere fejl på masterdatabasen og underrette salven om at tage ejerskab, så det vil kræve lidt arbejde på DBA's side. Du bør arbejde på et script, der inkluderer kommandoen pg_ctl promote, som vil promovere slaven som en ny master. Der er også nogle tredjepartsværktøjer til denne automatisering. Mange sådanne værktøjer findes og er godt integrerede med de operativsystemfaciliteter, der kræves for vellykket failover, såsom IP-adressemigrering.

Efter en failover sker, skal du ændre din applikation i overensstemmelse hermed for at arbejde med den nye master. Du vil også kun have én server, der virker, så genskabelse af master-slave-arkitekturen skal udføres, så vi vender tilbage til den samme normale situation, som vi havde før problemet.

PostgreSQL Master-Master-arkitekturer

Denne arkitektur giver en måde at minimere virkningen af ​​en fejl i en af ​​noderne, da den anden node kan tage sig af al trafikken, måske en smule påvirke ydeevnen, men aldrig miste funktionalitet. Det bruges også til at opnå (og måske er dette endda et mere interessant punkt) horisontal skalerbarhed (udskalering), modsat konceptet med vertikal skalerbarhed, hvor vi tilføjer flere ressourcer til en server (opskalering).

For at implementere denne arkitektur skal du bruge eksterne værktøjer, da denne funktion (endnu) ikke er indbygget understøttet af PostgreSQL.

Du skal være meget forsigtig, når du vælger en løsning til implementering af master-master, da der findes mange forskellige produkter. Mange af dem er stadig "grønne" med få seriøse brugere eller successager. Nogle andre projekter er til gengæld blevet opgivet, da der ikke er nogen aktive vedligeholdere.

For mere information om de tilgængelige værktøjer henvises til:Blog:Top PG Clustering HA Solutions for PostgreSQL.

Belastningsbalancering og forbindelsespooling

Der er flere load balancer-værktøjer, der kan bruges til at styre trafikken fra din applikation for at få mest muligt ud af din databasearkitektur. På samme måde er der nogle andre, der kan hjælpe dig med at administrere den måde, applikationen opretter forbindelse til databasen på, ved at samle disse forbindelser og genbruge dem mellem forskellige anmodninger.

Der er nogle produkter, der bruges til begge formål, såsom den velkendte pgpool, og nogle andre, der kun vil fokusere på én af disse funktioner, såsom pgbouncer (forbindelsespooling) og HAProxy (bruges til belastningsbalancering).