Denne artikel beskriver, hvordan setup PostgreSQL Replication og Hot Standby p\u00e5 to Amazon EC2 forekomster, der k\u00f8rer Ubuntu. Jeg tilbragte god luns af tid p\u00e5 at l\u00e6re disse tricks i sidste to uger, for at gennemf\u00f8re High Availability l\u00f8sning til 3DTin databaseserver. Standby node kan tage over, n\u00e5r main node g\u00e5r ned, som den gjorde sidste m\u00e5ned under elektrisk udfald p\u00e5 Amazon EC2 \u00f8stkyst datacentre. 3DTin var nede i 6 timer under nedbruddet, og siden da har vi v\u00e6ret gennemf\u00f8relsen foranstaltninger for at undg\u00e5, at det sker igen i fremtiden. Dette indl\u00e6g kan hj\u00e6lpe andre web-udviklere at bygge robuste cloud backends s\u00e5 godt.<\/p>\n\n
Replikation teknik, der anvendes her, er blevet tilg\u00e6ngelige i PostgreSQL kun siden version 9.1. Der er flere blogindl\u00e6g og f\u00e5 b\u00f8ger, der beskriver det, men de forklarer ikke alt, hvad der er n\u00f8dvendigt. Jeg fandt en forklaring af disse ops\u00e6tninger i “PostgreSQL 9 Administration Kogebog” meget nyttig. Jeg pr\u00f8vede alle de replikation opskrifter er beskrevet i denne bog om to VM’er p\u00e5 min b\u00e6rbare computer. Efter at have g\u00e5et gennem 7 forskellige database klynger, der hver bruges til at teste anden opskrift, jeg fik en god styr p\u00e5 de ting. I dag har vi med succes oprettet denne replikering l\u00f8sning p\u00e5 3DTin produktions-database. Med detaljerne frisk i tankerne vil jeg gerne dokumentere alle trinene for fremtidig reference, og i h\u00e5b om at det ogs\u00e5 kan hj\u00e6lpe andre, eftersom dokumentationen om dette emne endnu ikke er rigelige.
\nOps\u00e6tning<\/p>\n\n
Instruktionerne her bruger Ubuntu 11.10 32-bit server med PostgreSQL 9.1.4 (Ubuntu 12.04 vil g\u00f8re det s\u00e5 godt med alle PostgreSQL versionen 9.1.x).<\/p>\n\n
Vi kommer til at forberede 2 v\u00e6rter, en master og en anden standby. Hvis du bruger Amazon EC2 ligesom os, du \u00f8nsker at k\u00f8re disse to v\u00e6rter i to forskellige Tilg\u00e6ngelighed zoner. Det er vigtigt, hvis dit m\u00e5l er h\u00f8j tilg\u00e6ngelighed. Enhver utilsigtet nedetid er ikke meningen at ber\u00f8re mere end \u00e9n Amazon EC2 tilg\u00e6ngelighed zoner samtidigt. Derfor, hvis en af \u200b\u200bv\u00e6rten g\u00e5r ned, kan du bringe dine applikationsservere i en anden zone, hvor dit standby DB server k\u00f8rer. Du kan ogs\u00e5 s\u00e6tte dem i to forskellige regioner, men det vil koste dig mere i netv\u00e6rk b\u00e5ndbredde.
\nForberedelse<\/p>\n\n
Installer f\u00f8lgende pakker p\u00e5 Ubuntu 11.10\/12.04<\/p>\n\n
postgresql-9.1
\npostgresql-client-9.1
\npostgresql-bidraget 9.1<\/p>\n\n
Postgres brugerkonto<\/p>\n\n
Installation disse pakker vil automatisk skabe Postgres brugerkonto.<\/p>\n\n
Alle f\u00f8lgende kommandoer formodes at blive henrettet som Postgres bruger. Af sikkerhedsm\u00e6ssige \u00e5rsager denne konto ikke har nogen adgangskode (ligesom root-kontoen p\u00e5 Ubuntu). Hvis du arbejder i testmilj\u00f8, kan du angive en adgangskode for Postgres med<\/p>\n\n
sudo passwd Postgres<\/p>\n\n
Derefter udf\u00f8re alle f\u00f8lgende kommandoer ved at logge ind som Postgres<\/p>\n\n
su – Postgres<\/p>\n\n
Hvis du er p\u00e5 produktions server selv, kan du \u00f8nsker at forlade Postgres passwordless. I stedet k\u00f8re alle f\u00f8lgende kommandoer med sudo-u Postgres forangivet. Jeg kommer til at udelade det fra alle kommando for bekvemmelighed.
\nPassword-mindre ssh logins<\/p>\n\n
MASTER server skal kunne f\u00e5 adgang til STANDBY l\u00f8bet ssh uden password. Mere pr\u00e6cist – Postgres konto p\u00e5 MASTER b\u00f8r v\u00e6re i stand til at f\u00e5 adgang Postgres konto p\u00e5 STANDBY uden password. Dette er n\u00f8dvendigt for rsync operation i bunden-backup trin (forklares nedenfor)<\/p>\n\n
Du kan g\u00f8re det ved hj\u00e6lp af ssh-copy-id nytte.<\/p>\n\n
P\u00e5 Master l\u00f8b
\nssh-copy-id <IP_OF_STANDBY_SERVER><\/p>\n\n
Du kan ogs\u00e5 angive brugeren i ovenst\u00e5ende kommando, men jeg bevidst udeladt det, fordi det anbefales, at p\u00e5 begge maskiner du g\u00f8r disse operationer under samme brugerkonto Postgres. Ikke at n\u00e6vne, at brugeren vil g\u00f8re kommandoen login til remote maskine med samme brugernavn, som du i \u00f8jeblikket er logget ind p\u00e5 denne maskine (eller n\u00e6vnt i sudo-u).<\/p>\n\n
I tilf\u00e6lde af failover, MASTER server og STANDBY server vil v\u00e6re at skifte roller, derfor l\u00f8be ssh-copy-id fra den nuv\u00e6rende STANDBY server, s\u00e5 den kan f\u00e5 adgang til aktuelle MASTER server uden password ogs\u00e5.
\nUbuntu specifikke PostgreSQL konventioner<\/p>\n\n
P\u00e5 ubuntu en PostgreSQL database instans kaldes klynge. M\u00e5 ikke forveksle det med multi-node konfiguration af servere eller endda en vis SQL s\u00f8geord. Det er simpelthen en forekomst af PostgreSQL-server, der k\u00f8rer p\u00e5 en bestemt port og gemmer sine data i sin egen mappe (standard er \/ var\/lib\/postgresql\/9.1 \/ <cluster-name> – ogs\u00e5 indstillet til PGDATA milj\u00f8variabel i forskellige scripts).<\/p>\n\n
Ubuntu kommer med pg_createcluster, pg_ctlcluster, pg_lscluster CLI kommandoer til at hj\u00e6lpe dig med at administrere disse klynger. Du skal bruge pg_ctlcluster til at starte, stoppe, genindl\u00e6se databasen instans.<\/p>\n\n
Hver klynge har ogs\u00e5 sit eget s\u00e6t af konfigurationsfiler gemt i \/ etc\/postgresql\/9.1 \/ <cluster-name>. Vi bliver n\u00f8dt til at \u00e6ndre kun to af dem: pg_hba.conf og postgresql.conf.<\/p>\n\n
For at holde tingene enkle, er det bedre, hvis du s\u00f8rge for, at $ PGDATA er ens p\u00e5 b\u00e5de MASTER-og standby-servere. (Side note: Om produktion server $ PGDATA forventes at blive monteret p\u00e5 en separat bog)
\nReplication med streaming Log Shipping og Hot Standby<\/p>\n\n
Der er mange forskellige konfigurationer, som du kan f\u00f8lge for at opn\u00e5 replikation p\u00e5 tv\u00e6rs af to PostgreSQL tilf\u00e6lde. 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\u00e6vnte tidligere. Denne ops\u00e6tning virker mest optimalt i form af umiddelbar replikation (dvs. mindste vindue for tab af data), og minimum networking trafik (og dermed billigere).<\/p>\n\n
Denne konfiguration er Master-Slave art. Slaven eller STANDBY server kan bruges til at s\u00f8ge i databasen, men du kan ikke g\u00f8re nogen skriver til den. Denne konfiguration er ikke, hvad der er kendt som “Multi Master” konfiguration. Mesteren vil acceptere alle l\u00e6se og skrive foresp\u00f8rgsler fra dine applikationsservere. Standby server vil kopiere nye \u00e6ndringer fra Master med minimal forsinkelse. Det vil kun v\u00e6re tilg\u00e6ngelig for read-only foresp\u00f8rgsler i Standby-tilstand. N\u00e5r Master g\u00e5r ned, eller vi bringer det ned af andre \u00e5rsager, kan vi fort\u00e6lle 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\u00e6re klar til at acceptere l\u00e6se-skrive foresp\u00f8rgsler, vil det s\u00e5 v\u00e6re den nye Master.
\nLad os starte<\/p>\n\n
Hvis du allerede har en PostgreSQL-database, der k\u00f8rer p\u00e5 produktions-server, vil det v\u00e6re din nuv\u00e6rende MASTER server. Men bem\u00e6rk, at vi kommer til at konfigurere b\u00e5de MASTER og standbytiden maskiner identisk som muligt, fordi du \u00f8nsker at g\u00f8re en af \u200b\u200bdem MASTER i tilf\u00e6lde anden g\u00e5r ned og skifte tilbage, n\u00e5r det kommer op igen.<\/p>\n\n
Lad os starte med den nuv\u00e6rende MASTER l\u00f8be og STANDBY stoppet.<\/p>\n\n
P\u00e5 MASTER skaber replicator bruger. STANDBY server vil logge p\u00e5 MASTER ved hj\u00e6lp af denne konto til at l\u00e6se seneste \u00e6ndringer, som det har at replikere. Du b\u00f8r ikke g\u00f8re dette skridt p\u00e5 nuv\u00e6rende STANDBY server, selv om det m\u00e5ske engang blive en ny mester. Det er fordi i l\u00f8bet af basen backup trin Replicator brugerrolle vil blive kopieret til STANDBY server automatisk.<\/p>\n\n
psql-c “CREATE USER duplikatorer superbruger LOG FORBINDELSE LIMIT 1 krypterede password ‘changeme\u00ab “<\/p>\n\n
Rediger pg_hba.conf p\u00e5 b\u00e5de MASTER og STANDBY server ved at tilf\u00f8je denne linje. Det fort\u00e6ller de respektive PostgreSQL forekomster til at acceptere forbindelse fra andet knudepunkt for replikation form\u00e5l.<\/p>\n\n
host replikation replikator <IP_OF_OTHER_HOST> \/ 32 md5<\/p>\n\n
Rediger postgresql.conf p\u00e5 b\u00e5de MASTER og standbytiden servere og f\u00f8je f\u00f8lgende linjer til det. (Check, om disse muligheder allerede er indstillet til forskellige v\u00e6rdier andre steder i filen)<\/p>\n\n
hot_standby = on
\nmax_wal_senders = 1
\nwal_level = ‘hot_standby’
\narchive_mode = on
\narchive_command = ‘cd’.
\nlisten_addresses = ‘localhost, <IP_ADDRESS_OF_THIS_NODE>’<\/p>\n\n
P\u00e5 dette tidspunkt genstart MASTER. M\u00e5 ikke begynde STANDBY endnu<\/p>\n\n
N\u00e6ste vi kommer til at udf\u00f8re basen backup fra MASTER til STANDBY<\/p>\n\n
BACKUP_LABEL = “base-backup”<\/p>\n\n
psql-p $ PORT-c “select pg_start_backup (‘$ BACKUP_LABEL’);”
\nrsync-CVA – inplace – exclude = * pg_xlog * $ PGDATA \/ <IP_OF_OTHER_HOST>: $ PGDATA \/
\npsql-p $ PORT-c “select pg_stop_backup ();”<\/p>\n\n
Det anbefales, at du s\u00e6tte dette i et bash script, s\u00e5 det kan k\u00f8res hurtigt og gentagne gange uden fejl.<\/p>\n\n
P\u00e5 STANDBY oprette en recovery.conf fil i $ PGDATA og tilf\u00f8je f\u00f8lgende linier til det.<\/p>\n\n
standby_mode = ‘on’
\nprimary_conninfo = ‘host = <IP_OF_OTHER_HOST> port = $ PORT user = replikator password = changeme’
\ntrigger_file = ‘\/ tmp \/ postgresql.trigger. $ PORT’<\/p>\n\n
Nu starter STANDBY server.<\/p>\n\n
P\u00e5 dette tidspunkt kan du tjekke logfilen (\/ var\/log\/postgresql\/postgresql-9.1- <cluster-name>. Log) for at kontrollere tingene<\/p>\n\n
P\u00e5 STANDBY kigge efter en beskeden “streaming replikation forbundet til prim\u00e6r”.
\n Ligeledes b\u00f8r du se “wal receiver-processen” p\u00e5 standby og “wal afsender processen” p\u00e5 MASTER.
\n Endelig k\u00f8re nogle foresp\u00f8rgsler mod STANDBY server for at verificere den indeholder samme data som MASTER.<\/p>\n\n
Hvis det ikke virker, skal du kontrollere firewall regler i Amazon EC2 Security Groups.
\nS\u00e5dan g\u00f8r Failover \/ Switchover<\/p>\n\n
Ops\u00e6tning af systemet til h\u00f8j tilg\u00e6ngelighed er til nogen nytte, hvis du kommer til at vente til selve katastrofen til at strejke, f\u00f8r du pr\u00f8ver inddrivelsen. Derfor b\u00f8r du pr\u00f8ve ovenst\u00e5ende trin i testmilj\u00f8et og simulere katastrofer.<\/p>\n\n
Hvis MASTER ikke er nede, skal du s\u00f8rge for at stoppe det f\u00f8rst, f\u00f8r du fort\u00e6ller STANDBY at tage den rolle. Dette er for at undg\u00e5, at MASTER fra at behandle yderligere sp\u00f8rgsm\u00e5l, der f\u00f8rer til en split-hjerne problem.<\/p>\n\n
Du kan sl\u00e5 STANDBY til en MASTER ved blot at r\u00f8re en trigger-fil, der blev n\u00e6vnt i recovery.conf, \/ tmp \/ postgresql.trigger. $ PORT.<\/p>\n\n
Nu, STANDBY har forvandlet til MASTER, punkt dine applikationsservere til det. Selv hvis din gamle MASTER k\u00f8rer p\u00e5 dette tidspunkt, er den nye MASTER ikke kommer til at replikere eventuelle \u00e6ndringer fra det. Derfor er det n\u00f8dvendigt, at du stopper den gamle mester, f\u00f8r du sp\u00f8rger STANDBY at blive den nye MASTER.<\/p>\n\n
Du kan fort\u00e6lle, at STANDBY blevet MASTER fra meddelelserne i logfilen, der l\u00e6ser “arkiv recovery f\u00e6rdig. database system er klar til at acceptere forbindelser. “
\nS\u00e5dan g\u00f8r Switchback<\/p>\n\n
Efter nogle nedetid eller vedligeholdelse periode er din master-node op igen, og du \u00f8nsker at g\u00f8re rutschebane. Du kommer til at f\u00f8rst dreje denne knude i standby. I denne tilstand vil det hamle op med den aktuelle MASTER kopiere de \u00e6ndringer, der fandt sted, mens det var nede. S\u00e5 vi henvise til det som den nuv\u00e6rende STANDBY nu.<\/p>\n\n
Peform Base backup fra den aktuelle MASTER til aktuelle STANDBY<\/p>\n\n
BACKUP_LABEL = “base-backup”<\/p>\n\n
psql-p $ PORT-c “select pg_start_backup (‘$ BACKUP_LABEL’);”
\nrsync-CVA – inplace – exclude = * pg_xlog * $ PGDATA \/ <IP_OF_OTHER_HOST>: $ PGDATA \/
\npsql-p $ PORT-c “select pg_stop_backup ();”<\/p>\n\n
Opret recovery.conf i $ PGDATA p\u00e5 aktuel STANDBY<\/p>\n\n
standby_mode = ‘on’
\nprimary_conninfo = ‘host = <IP_OF_OTHER_HOST> port = $ PORT user = replikator password = changeme’
\ntrigger_file = ‘\/ tmp \/ postgresql.trigger. $ PORT’<\/p>\n\n
Efter fangsten op er overst\u00e5et, kan du sl\u00e5 den aktuelle STANDBY ind MASTER ved at f\u00f8lge ovenst\u00e5ende overgangen procedure – ved udl\u00f8seren fil.<\/p>\n\n
Ud over at v\u00e6re en forsikring mod katastrofer, kan STANDBY server ogs\u00e5 bruges til load balancing form\u00e5l. Du kan konfigurere app servere for at sprede deres l\u00e6se foresp\u00f8rgsler p\u00e5 tv\u00e6rs af Mesteren og Standby servere. V\u00e6rkt\u00f8jer som pgpool giver den slags anl\u00e6g.<\/p>\n\n
N\u00e5r du f\u00e5r behagelige omgivelser op en grundl\u00e6ggende to node replikation og hot standby-ordningen, kan du g\u00e5 videre til avancerede konfigurationer ogs\u00e5.<\/p>\n\n
Hvis du finder nogen fejl eller forslag til forbedringer i denne artikel kan du efterlade en kommentar.<\/p>\n\n