Denne artikel beskriver, hvordan setup PostgreSQL Replication og Hot Standby på to Amazon EC2 forekomster, der kører Ubuntu. Jeg tilbragte god luns af tid på at lære disse tricks i sidste to uger, for at gennemføre High Availability løsning til 3DTin databaseserver. Standby node kan tage over, når main node går ned, som den gjorde sidste måned under elektrisk udfald på Amazon EC2 østkyst datacentre. 3DTin var nede i 6 timer under nedbruddet, og siden da har vi været gennemførelsen foranstaltninger for at undgå, at det sker igen i fremtiden. Dette indlæg kan hjælpe andre web-udviklere at bygge robuste cloud backends så godt.
Replikation teknik, der anvendes her, er blevet tilgængelige i PostgreSQL kun siden version 9.1. Der er flere blogindlæg og få bøger, der beskriver det, men de forklarer ikke alt, hvad der er nødvendigt. Jeg fandt en forklaring af disse opsætninger i “PostgreSQL 9 Administration Kogebog” meget nyttig. Jeg prøvede alle de replikation opskrifter er beskrevet i denne bog om to VM’er på min bærbare computer. Efter at have gået gennem 7 forskellige database klynger, der hver bruges til at teste anden opskrift, jeg fik en god styr på de ting. I dag har vi med succes oprettet denne replikering løsning på 3DTin produktions-database. Med detaljerne frisk i tankerne vil jeg gerne dokumentere alle trinene for fremtidig reference, og i håb om at det også kan hjælpe andre, eftersom dokumentationen om dette emne endnu ikke er rigelige.
Opsætning
Instruktionerne her bruger Ubuntu 11.10 32-bit server med PostgreSQL 9.1.4 (Ubuntu 12.04 vil gøre det så godt med alle PostgreSQL versionen 9.1.x).
Vi kommer til at forberede 2 værter, en master og en anden standby. Hvis du bruger Amazon EC2 ligesom os, du ønsker at køre disse to værter i to forskellige Tilgængelighed zoner. Det er vigtigt, hvis dit mål er høj tilgængelighed. Enhver utilsigtet nedetid er ikke meningen at berøre mere end én Amazon EC2 tilgængelighed zoner samtidigt. Derfor, hvis en af værten går ned, kan du bringe dine applikationsservere i en anden zone, hvor dit standby DB server kører. Du kan også sætte dem i to forskellige regioner, men det vil koste dig mere i netværk båndbredde.
Forberedelse
Installer følgende pakker på Ubuntu 11.10/12.04
postgresql-9.1
postgresql-client-9.1
postgresql-bidraget 9.1
Postgres brugerkonto
Installation disse pakker vil automatisk skabe Postgres brugerkonto.
Alle følgende kommandoer formodes at blive henrettet som Postgres bruger. Af sikkerhedsmæssige årsager denne konto ikke har nogen adgangskode (ligesom root-kontoen på Ubuntu). Hvis du arbejder i testmiljø, kan du angive en adgangskode for Postgres med
sudo passwd Postgres
Derefter udføre alle følgende kommandoer ved at logge ind som Postgres
su – Postgres
Hvis du er på produktions server selv, kan du ønsker at forlade Postgres passwordless. I stedet køre alle følgende kommandoer med sudo-u Postgres forangivet. Jeg kommer til at udelade det fra alle kommando for bekvemmelighed.
Password-mindre ssh logins
MASTER server skal kunne få adgang til STANDBY løbet ssh uden password. Mere præcist – Postgres konto på MASTER bør være i stand til at få adgang Postgres konto på STANDBY uden password. Dette er nødvendigt for rsync operation i bunden-backup trin (forklares nedenfor)
Du kan gøre det ved hjælp af ssh-copy-id nytte.
På Master løb
ssh-copy-id <IP_OF_STANDBY_SERVER>
Du kan også angive brugeren i ovenstående kommando, men jeg bevidst udeladt det, fordi det anbefales, at på begge maskiner du gør disse operationer under samme brugerkonto Postgres. Ikke at nævne, at brugeren vil gøre kommandoen login til remote maskine med samme brugernavn, som du i øjeblikket er logget ind på denne maskine (eller nævnt i sudo-u).
I tilfælde af failover, MASTER server og STANDBY server vil være at skifte roller, derfor løbe ssh-copy-id fra den nuværende STANDBY server, så den kan få adgang til aktuelle MASTER server uden password også.
Ubuntu specifikke PostgreSQL konventioner
På ubuntu en PostgreSQL database instans kaldes klynge. Må ikke forveksle det med multi-node konfiguration af servere eller endda en vis SQL søgeord. Det er simpelthen en forekomst af PostgreSQL-server, der kører på en bestemt port og gemmer sine data i sin egen mappe (standard er / var/lib/postgresql/9.1 / <cluster-name> – også indstillet til PGDATA miljøvariabel i forskellige scripts).
Ubuntu kommer med pg_createcluster, pg_ctlcluster, pg_lscluster CLI kommandoer til at hjælpe dig med at administrere disse klynger. Du skal bruge pg_ctlcluster til at starte, stoppe, genindlæse databasen instans.
Hver klynge har også sit eget sæt af konfigurationsfiler gemt i / etc/postgresql/9.1 / <cluster-name>. Vi bliver nødt til at ændre kun to af dem: pg_hba.conf og postgresql.conf.
For at holde tingene enkle, er det bedre, hvis du sørge for, at $ PGDATA er ens på både MASTER-og standby-servere. (Side note: Om produktion server $ PGDATA forventes at blive monteret på en separat bog)
Replication med streaming Log Shipping og Hot Standby
Der er mange forskellige konfigurationer, som du kan følge for at opnå replikation på tværs af to PostgreSQL tilfælde. Hver har sine egne fordele og faldgruber. Den teknik, vi vil bruge, er kendt som ‘streaming Log Shipping “og” Hot Standby “i Admin kogebog jeg nævnte tidligere. Denne opsætning virker mest optimalt i form af umiddelbar replikation (dvs. mindste vindue for tab af data), og minimum networking trafik (og dermed billigere).
Denne konfiguration er Master-Slave art. Slaven eller STANDBY server kan bruges til at søge i databasen, men du kan ikke gøre nogen skriver til den. Denne konfiguration er ikke, hvad der er kendt som “Multi Master” konfiguration. Mesteren vil acceptere alle læse og skrive forespørgsler fra dine applikationsservere. Standby server vil kopiere nye ændringer fra Master med minimal forsinkelse. Det vil kun være tilgængelig for read-only forespørgsler i Standby-tilstand. Når Master går ned, eller vi bringer det ned af andre årsager, kan vi fortælle Standby server til at blive Master ved at oprette en touch-fil (forklaret senere). Efter dette punkt ab Standby server vil stoppe efter den oprindelige master og vil nu være klar til at acceptere læse-skrive forespørgsler, vil det så være den nye Master.
Lad os starte
Hvis du allerede har en PostgreSQL-database, der kører på produktions-server, vil det være din nuværende MASTER server. Men bemærk, at vi kommer til at konfigurere både MASTER og standbytiden maskiner identisk som muligt, fordi du ønsker at gøre en af dem MASTER i tilfælde anden går ned og skifte tilbage, når det kommer op igen.
Lad os starte med den nuværende MASTER løbe og STANDBY stoppet.
På MASTER skaber replicator bruger. STANDBY server vil logge på MASTER ved hjælp af denne konto til at læse seneste ændringer, som det har at replikere. Du bør ikke gøre dette skridt på nuværende STANDBY server, selv om det måske engang blive en ny mester. Det er fordi i løbet af basen backup trin Replicator brugerrolle vil blive kopieret til STANDBY server automatisk.
psql-c “CREATE USER duplikatorer superbruger LOG FORBINDELSE LIMIT 1 krypterede password ‘changeme« “
Rediger pg_hba.conf på både MASTER og STANDBY server ved at tilføje denne linje. Det fortæller de respektive PostgreSQL forekomster til at acceptere forbindelse fra andet knudepunkt for replikation formål.
host replikation replikator <IP_OF_OTHER_HOST> / 32 md5
Rediger postgresql.conf på både MASTER og standbytiden servere og føje følgende linjer til det. (Check, om disse muligheder allerede er indstillet til forskellige værdier andre steder i filen)
hot_standby = on
max_wal_senders = 1
wal_level = ‘hot_standby’
archive_mode = on
archive_command = ‘cd’.
listen_addresses = ‘localhost, <IP_ADDRESS_OF_THIS_NODE>’
På dette tidspunkt genstart MASTER. Må ikke begynde STANDBY endnu
Næste vi kommer til at udføre basen backup fra MASTER til STANDBY
BACKUP_LABEL = “base-backup”
psql-p $ PORT-c “select pg_start_backup (‘$ BACKUP_LABEL’);”
rsync-CVA – inplace – exclude = * pg_xlog * $ PGDATA / <IP_OF_OTHER_HOST>: $ PGDATA /
psql-p $ PORT-c “select pg_stop_backup ();”
Det anbefales, at du sætte dette i et bash script, så det kan køres hurtigt og gentagne gange uden fejl.
På STANDBY oprette en recovery.conf fil i $ PGDATA og tilføje følgende linier til det.
standby_mode = ‘on’
primary_conninfo = ‘host = <IP_OF_OTHER_HOST> port = $ PORT user = replikator password = changeme’
trigger_file = ‘/ tmp / postgresql.trigger. $ PORT’
Nu starter STANDBY server.
På dette tidspunkt kan du tjekke logfilen (/ var/log/postgresql/postgresql-9.1- <cluster-name>. Log) for at kontrollere tingene
På STANDBY kigge efter en beskeden “streaming replikation forbundet til primær”.
Ligeledes bør du se “wal receiver-processen” på standby og “wal afsender processen” på MASTER.
Endelig køre nogle forespørgsler mod STANDBY server for at verificere den indeholder samme data som MASTER.
Hvis det ikke virker, skal du kontrollere firewall regler i Amazon EC2 Security Groups.
Sådan gør Failover / Switchover
Opsætning af systemet til høj tilgængelighed er til nogen nytte, hvis du kommer til at vente til selve katastrofen til at strejke, før du prøver inddrivelsen. Derfor bør du prøve ovenstående trin i testmiljøet og simulere katastrofer.
Hvis MASTER ikke er nede, skal du sørge for at stoppe det først, før du fortæller STANDBY at tage den rolle. Dette er for at undgå, at MASTER fra at behandle yderligere spørgsmål, der fører til en split-hjerne problem.
Du kan slå STANDBY til en MASTER ved blot at røre en trigger-fil, der blev nævnt i recovery.conf, / tmp / postgresql.trigger. $ PORT.
Nu, STANDBY har forvandlet til MASTER, punkt dine applikationsservere til det. Selv hvis din gamle MASTER kører på dette tidspunkt, er den nye MASTER ikke kommer til at replikere eventuelle ændringer fra det. Derfor er det nødvendigt, at du stopper den gamle mester, før du spørger STANDBY at blive den nye MASTER.
Du kan fortælle, at STANDBY blevet MASTER fra meddelelserne i logfilen, der læser “arkiv recovery færdig. database system er klar til at acceptere forbindelser. “
Sådan gør Switchback
Efter nogle nedetid eller vedligeholdelse periode er din master-node op igen, og du ønsker at gøre rutschebane. Du kommer til at først dreje denne knude i standby. I denne tilstand vil det hamle op med den aktuelle MASTER kopiere de ændringer, der fandt sted, mens det var nede. Så vi henvise til det som den nuværende STANDBY nu.
Peform Base backup fra den aktuelle MASTER til aktuelle STANDBY
BACKUP_LABEL = “base-backup”
psql-p $ PORT-c “select pg_start_backup (‘$ BACKUP_LABEL’);”
rsync-CVA – inplace – exclude = * pg_xlog * $ PGDATA / <IP_OF_OTHER_HOST>: $ PGDATA /
psql-p $ PORT-c “select pg_stop_backup ();”
Opret recovery.conf i $ PGDATA på aktuel STANDBY
standby_mode = ‘on’
primary_conninfo = ‘host = <IP_OF_OTHER_HOST> port = $ PORT user = replikator password = changeme’
trigger_file = ‘/ tmp / postgresql.trigger. $ PORT’
Efter fangsten op er overstået, kan du slå den aktuelle STANDBY ind MASTER ved at følge ovenstående overgangen procedure – ved udløseren fil.
Ud over at være en forsikring mod katastrofer, kan STANDBY server også bruges til load balancing formål. Du kan konfigurere app servere for at sprede deres læse forespørgsler på tværs af Mesteren og Standby servere. Værktøjer som pgpool giver den slags anlæg.
Når du får behagelige omgivelser op en grundlæggende to node replikation og hot standby-ordningen, kan du gå videre til avancerede konfigurationer også.
Hvis du finder nogen fejl eller forslag til forbedringer i denne artikel kan du efterlade en kommentar.
Har du tjekket ud Repmgr. (Http://www.repmgr.org/).
Selvom PostgreSQL 9 + understøtter replikeret Hot Standby servere, som vi kan forespørge og / eller bruge til høj tilgængelighed., Er brugeren forventes at styre høj tilgængelighed del af det.