\n
\nDatareplikering \u00e4r en automatiserad s\u00e4kerhetskopierings-process d\u00e4r dina data upprepade g\u00e5nger kopieras fr\u00e5n huvuddatabasen till en annan, avl\u00e4gsen plats f\u00f6r f\u00f6rvaring. Det \u00e4r en integrerad teknik f\u00f6r alla webbplatser eller appar som k\u00f6r en databasserver<\/a>. Du kan \u00e4ven utnyttja den replikerade databasen f\u00f6r att bearbeta skrivskyddad SQL, vilket g\u00f6r att fler processer kan k\u00f6ras i systemet.<\/p>\n
Att st\u00e4lla in replikering mellan tv\u00e5 databaser ger en feltolerans mot ov\u00e4ntade miss\u00f6den. Det anses vara den b\u00e4sta strategin f\u00f6r att uppn\u00e5 en h\u00f6g tillg\u00e4nglighet vid katastrofer.<\/p>\n
I den h\u00e4r artikeln s\u00e5 kommer vi att djupdyka i de olika strategier som kan implementeras av backend-utvecklare<\/a> f\u00f6r s\u00f6ml\u00f6s PostgreSQL-replikering. PostgreSQL-replikering definieras som processen f\u00f6r kopiering av data fr\u00e5n en PostgreSQL-databasserver<\/a> till en annan server. K\u00e4lldatabasservern kallas \u00e4ven f\u00f6r den ”prim\u00e4ra” servern. Databasservern som tar emot de kopierade uppgifterna kallas f\u00f6r ”replika”-servern.<\/p>\n PostgreSQL-databasen f\u00f6ljer en enkel replikerings-modell d\u00e4r alla skrivningar g\u00e5r till en prim\u00e4r nod. Den prim\u00e4ra noden kan sedan till\u00e4mpa dessa \u00e4ndringar och s\u00e4nda dem till sekund\u00e4ra noder.<\/p>\n Failover \u00e4r en metod f\u00f6r att \u00e5terst\u00e4lla data om den prim\u00e4ra servern av n\u00e5gon anledning ger upp<\/a>. S\u00e5 l\u00e4nge som du har konfigurerat PostreSQL f\u00f6r att hantera din fysiska str\u00f6mmande replikering s\u00e5 kommer du – och dina anv\u00e4ndare – att vara skyddade fr\u00e5n driftsstopp p\u00e5 grund av en prim\u00e4rserver som kr\u00e5nglar.<\/p>\n Observera att failover-processen kan ta lite tid att konfigurera och initiera. Det finns inga inbyggda verktyg f\u00f6r att \u00f6vervaka och avgr\u00e4nsa serverfel i PostgreSQL, s\u00e5 du m\u00e5ste vara kreativ.<\/p>\n Du beh\u00f6ver som tur \u00e4r inte vara beroende av PostgreSQL f\u00f6r failover. Det finns dedikerade verktyg som m\u00f6jligg\u00f6r automatisk failover och automatisk v\u00e4xling till standby, vilket minskar nertiden f\u00f6r databasen<\/a>.<\/p>\n Genom att st\u00e4lla in failover-replikering s\u00e5 garanterar du n\u00e4stan en h\u00f6g tillg\u00e4nglighet genom att se till att reserver finns tillg\u00e4ngliga om den prim\u00e4ra servern n\u00e5gonsin kollapsar.<\/p>\n H\u00e4r \u00e4r n\u00e5gra viktiga f\u00f6rdelar med att anv\u00e4nda PostgreSQL-replikering:<\/p>\n Folk tror generellt att det bara finns ett s\u00e4tt att konfigurera s\u00e4kerhetskopior<\/a> och replikering, n\u00e4r man h\u00e5ller p\u00e5 med en prim\u00e4r och sekund\u00e4r arkitektur. PostgreSQL-implementeringar kan dock f\u00f6lja n\u00e5gon av dessa tre metoder<\/a>:<\/p>\n PostgreSQL str\u00f6mnings-replikering, \u00e4ven k\u00e4nt som WAL-replikering, kan konfigureras s\u00f6ml\u00f6st efter installation av PostgreSQL p\u00e5 alla servrar. Detta tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r replikering bygger p\u00e5 att WAL-filerna flyttas fr\u00e5n den prim\u00e4ra databasen till m\u00e5ldatabasen.<\/p>\n Du kan implementera PostgreSQL str\u00f6mnings-replikering genom att anv\u00e4nda en prim\u00e4r-sekund\u00e4r konfiguration. Den prim\u00e4ra servern \u00e4r den huvudinstans som hanterar den prim\u00e4ra databasen och all dess verksamhet. Den sekund\u00e4ra servern fungerar som den kompletterande instansen och utf\u00f6r alla \u00e4ndringar som g\u00f6rs i den prim\u00e4ra databasen p\u00e5 sig sj\u00e4lv. Detta genererar en identisk kopia i processen. Den prim\u00e4ra servern \u00e4r en l\u00e4s- och skrivserver medan den sekund\u00e4ra servern endast \u00e4r skrivskyddad.<\/p>\n F\u00f6r den h\u00e4r metoden s\u00e5 m\u00e5ste du b\u00e5de konfigurera den prim\u00e4ra noden och reservnoden. I f\u00f6ljande avsnitt s\u00e5 beskrivs de steg som kr\u00e4vs f\u00f6r att konfigurera dem p\u00e5 ett enkelt s\u00e4tt.<\/p>\n Du kan konfigurera den prim\u00e4ra noden f\u00f6r str\u00f6mmande replikering genom att utf\u00f6ra f\u00f6ljande steg:<\/p>\n F\u00f6r att initialisera databasen<\/a> s\u00e5 kan du anv\u00e4nda kommandot Anv\u00e4ndaren m\u00e5ste ange ett l\u00f6senord och ett anv\u00e4ndarnamn f\u00f6r den givna s\u00f6kfr\u00e5gan. Nyckelordet replikering anv\u00e4nds f\u00f6r att ge anv\u00e4ndaren de n\u00f6dv\u00e4ndiga privilegierna. En exempelfr\u00e5ga exempelvis kunna se ut s\u00e5 h\u00e4r:<\/p>\n D\u00e4refter s\u00e5 kan du konfigurera str\u00f6mnings-egenskaperna med PostgreSQL-konfigurationsfilen (postgresql.conf<\/strong>) som kan \u00e4ndras p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n H\u00e4r \u00e4r lite bakgrundsinformation om de parametrar som anv\u00e4ndes i f\u00f6reg\u00e5ende utdrag:<\/p>\n N\u00e4r du har \u00e4ndrat parametrarna i filen postgresql.conf<\/strong> s\u00e5 sker n\u00e5t viktigt. D\u00e5 kan n\u00e4mligen en ny replikeringspost i filen pg_hba.conf<\/strong> g\u00f6ra det m\u00f6jligt f\u00f6r servrarna att uppr\u00e4tta en anslutning med varandra f\u00f6r replikering.<\/p>\n Du hittar vanligtvis den h\u00e4r filen i PostgreSQL’s datakatalog. Du kan anv\u00e4nda f\u00f6ljande kodutdrag f\u00f6r samma sak:<\/p>\n N\u00e4r kodstycket exekveras s\u00e5 till\u00e5ter den prim\u00e4ra servern en anv\u00e4ndare som heter F\u00f6lj de h\u00e4r stegen f\u00f6r att konfigurera standby-noden f\u00f6r str\u00f6mnings-replikering:<\/p>\n F\u00f6r att konfigurera standby-noden s\u00e5 anv\u00e4nder du verktyget De parametrar som anv\u00e4nds i syntaxen ovan \u00e4r f\u00f6ljande:<\/p>\n D\u00e4refter s\u00e5 m\u00e5ste du kontrollera om replikeringskonfigurationsfilen finns. Om den inte existerar s\u00e5 kan du generera replikeringskonfigurationsfilen som recovery.conf<\/strong>.<\/p>\n Du b\u00f6r skapa den h\u00e4r filen i datakatalogen i PostgreSQL-installationen. Den kan genereras automatiskt genom alternativet Filen recovery.conf<\/strong> b\u00f6r inneh\u00e5lla f\u00f6ljande kommandon:<\/p>\n De parametrar som anv\u00e4nds i de ovann\u00e4mnda kommandona \u00e4r f\u00f6ljande:<\/p>\n Om du vill uppr\u00e4tta en anslutning s\u00e5 m\u00e5ste du ange anv\u00e4ndarnamn, IP-adress och l\u00f6senord som hosten f\u00f6r parametern primary_conninfo. Exempelvis:<\/p>\n Slutligen s\u00e5 kan du starta om den sekund\u00e4ra servern f\u00f6r att slutf\u00f6ra konfigurationen.<\/p>\n Str\u00f6mnings-replikering inneb\u00e4r dock flera utmaningar, exempelvis:<\/p>\n Metoden med replikerad blockenhet \u00e4r beroende av diskspegling (\u00e4ven k\u00e4nt som volymreplikering). I detta tillv\u00e4gag\u00e5ngss\u00e4tt s\u00e5 skrivs \u00e4ndringar till en best\u00e4ndig volym som speglas synkront till en annan volym.<\/p>\n F\u00f6rdelen med den h\u00e4r metoden \u00e4r dess kompatibilitet och datadurabilitet i molnmilj\u00f6er med alla relationsdatabaser. Detta inkluderar exempelvis PostgreSQL, MySQL och SQL Server<\/a>, f\u00f6r att n\u00e4mna n\u00e5gra.<\/p>\n Diskspeglingsmetoden f\u00f6r PostgreSQL-replikering kr\u00e4ver dock att du b\u00e5de replikerar WAL-logg- och tabelldata. Eftersom varje skrivning till databasen nu m\u00e5ste g\u00e5 \u00f6ver n\u00e4tverket synkront s\u00e5 har du inte r\u00e5d att f\u00f6rlora en enda byte. Som ett resultat s\u00e5 kan detta n\u00e4mligen leda till att din databas hamnar i ett korrupt tillst\u00e5nd.<\/p>\n Den h\u00e4r metoden anv\u00e4nds normalt med Azure PostgreSQL och Amazon RDS.<\/p>\n WAL best\u00e5r av segmentfiler (16 MB som standard). Varje segment har en eller flera poster. En loggsekvenspost (LSN) \u00e4r en pekare mot en post i WAL, som ger dig information om positionen\/platsen d\u00e4r posten har sparats i loggfilen.<\/p>\n En standby-server utnyttjar WAL-segmenten – \u00e4ven kallade XLOGS i PostgreSQL-terminologi – f\u00f6r att kontinuerligt replikera \u00e4ndringar fr\u00e5n den prim\u00e4ra servern. Du kan anv\u00e4nda write-ahead logging f\u00f6r att ge h\u00e5llbarhet och atomicitet i ett DBMS. Detta g\u00f6rs genom serialisering av delar av byte-array-data (var och en med ett unikt LSN) till stabil lagring innan de till\u00e4mpas i en databas.<\/p>\n Att till\u00e4mpa en mutation p\u00e5 en databas kan leda till olika filsystemoperationer. En relevant fr\u00e5ga som dyker upp \u00e4r f\u00f6ljande: Hur kan en databas garantera atomicitet i h\u00e4ndelse av ett serverfel p\u00e5 grund av str\u00f6mavbrott medan den \u00e4r mitt uppe i en filsystemuppdatering. N\u00e4r en databas startar upp s\u00e5 k\u00f6r den en start- eller \u00e5terspelningsprocess som kan l\u00e4sa de tillg\u00e4ngliga WAL-segmenten och j\u00e4mf\u00f6ra dem med det LSN som finns lagrat p\u00e5 varje datasida. Varje datasida \u00e4r markerad med LSN f\u00f6r den senaste WAL-posten som p\u00e5verkar sidan.<\/p>\n Str\u00f6mnings-replikering f\u00f6rfinar loggf\u00f6rs\u00e4ndelseprocessen. I motsats till att v\u00e4nta p\u00e5 WAL-omkopplingen s\u00e5 skickas posterna n\u00e4r de skapas, vilket minskar replikeringsf\u00f6rdr\u00f6jningen.<\/p>\n Str\u00f6mnings-replikering \u00e4r \u00e4ven b\u00e4ttre \u00e4n loggf\u00f6rs\u00e4ndelse eftersom reservservern \u00e4r kopplad till den prim\u00e4ra servern via n\u00e4tverket. Den utnyttjar ett replikeringsprotokoll. Som ett resultat s\u00e5 kan den prim\u00e4ra servern sedan skicka WAL-poster direkt \u00f6ver denna anslutning. Den \u00e4r inte beroende av skript som tillhandah\u00e5lls av slutanv\u00e4ndaren.<\/p>\n Loggf\u00f6rs\u00e4ndelse definieras som kopiering av loggfiler till en annan PostgreSQL-server f\u00f6r att generera en annan reservserver. Detta g\u00f6rs genom att spela om WAL-filer. Denna server \u00e4r konfigurerad f\u00f6r att arbeta i \u00e5terst\u00e4llningsl\u00e4ge och dess enda syfte \u00e4r att till\u00e4mpa nya WAL-filer n\u00e4r de dyker upp.<\/p>\n Som ett resultat s\u00e5 blir den sekund\u00e4ra servern sedan en varm s\u00e4kerhetskopia av den prim\u00e4ra PostgreSQL-servern. Den kan \u00e4ven konfigureras f\u00f6r att vara en l\u00e4skopia, d\u00e4r den kan erbjuda skrivskyddade f\u00f6rfr\u00e5gningar, \u00e4ven kallat hot standby.<\/p>\n WAL-arkivering \u00e4r en duplicering av WAL-filer n\u00e4r de skapas till en annan plats \u00e4n underkatalogen Skriptet kan utnyttja kommandot Andra loggbaserade konfigurationer inkluderar:<\/p>\n En process som kallas WAL-mottagare och som k\u00f6rs p\u00e5 reservservern utnyttjar de anslutningsuppgifter som anges i parametern F\u00f6r att starta str\u00f6mnings-replikering s\u00e5 kan frontend skicka replikeringsparametern i startmeddelandet. Ett boolskt v\u00e4rde p\u00e5 true, yes, 1 eller ON l\u00e5ter backend<\/a> veta att den m\u00e5ste g\u00e5 in i fysiskt replikeringsl\u00e4ge f\u00f6r Wal-s\u00e4ndaren.<\/p>\n WAL-s\u00e4ndaren \u00e4r en annan process som k\u00f6rs p\u00e5 den prim\u00e4ra servern och som ansvarar f\u00f6r att skicka WAL-posterna till reservservern n\u00e4r de genereras. Som ett resultat s\u00e5 sparar WAL-mottagaren WAL-posterna i WAL som om de skapades av klientaktivitet av lokalt anslutna klienter.<\/p>\n N\u00e4r WAL-posterna v\u00e4l n\u00e5r WAL-segmentfilerna s\u00e5 forts\u00e4tter standby-servern st\u00e4ndigt att spela upp WAL-posterna s\u00e5 att prim\u00e4r- och standby-servern \u00e4r uppdaterade.<\/p>\n I det h\u00e4r avsnittet s\u00e5 f\u00e5r du en djupare f\u00f6rst\u00e5else f\u00f6r de vanligaste modellerna (replikering med en och flera huvudm\u00e4n), typerna (fysisk och logisk replikering) och s\u00e4tten (synkron och asynkron) f\u00f6r PostgreSQL-replikering.<\/p>\n Skalbarhet inneb\u00e4r att man l\u00e4gger till mer resurser\/h\u00e5rdvara till befintliga noder f\u00f6r att \u00f6ka databasens f\u00f6rm\u00e5ga att lagra och bearbeta mer data. Detta kan uppn\u00e5s horisontellt och vertikalt. PostgreSQL-replikering \u00e4r ett exempel p\u00e5 horisontell skalbarhet som \u00e4r mycket sv\u00e5rare att genomf\u00f6ra \u00e4n vertikal skalbarhet. Vi kan uppn\u00e5 horisontell skalbarhet fr\u00e4mst genom replikering med en enda huvudman (SMR) och replikering med flera huvudm\u00e4n (MMR).<\/p>\n Replikering med en enda huvudman g\u00f6r det m\u00f6jligt att \u00e4ndra data i en enda nod, och dessa \u00e4ndringar replikeras till en eller flera noder. De replikerade tabellerna i replikeringsdatabasen f\u00e5r inte ta emot n\u00e5gra \u00e4ndringar, f\u00f6rutom de som kommer fr\u00e5n den prim\u00e4ra servern. \u00c4ven om de g\u00f6r detta s\u00e5 replikeras \u00e4ndringarna inte tillbaka till den prim\u00e4ra servern.<\/p>\n F\u00f6r det mesta s\u00e5 r\u00e4cker SMR f\u00f6r applikationen. Det \u00e4r n\u00e4mligen mindre komplicerat att konfigurera och hantera och det finns ingen risk f\u00f6r konflikter. Replikering med en enda huvudserver \u00e4r \u00e4ven enkelriktad, eftersom replikeringsdata huvudsakligen fl\u00f6dar i en riktning, fr\u00e5n den prim\u00e4ra till replikdatabasen.<\/p>\n I vissa fall r\u00e4cker det inte bara med SMR. Du kan beh\u00f6va implementera MMR. MMR g\u00f6r det m\u00f6jligt f\u00f6r fler \u00e4n en nod att agera som prim\u00e4r nod. Som ett resultat s\u00e5 replikeras \u00e4ndringar av tabellrader i mer \u00e4n en utsedd prim\u00e4rdatabas till motsvarande tabeller i alla andra prim\u00e4ra databaser. I den h\u00e4r modellen s\u00e5 anv\u00e4nds ofta konfliktl\u00f6sningsmetoder f\u00f6r att undvika problem som dubbla prim\u00e4rnycklar.<\/p>\n Det finns n\u00e5gra f\u00f6rdelar med att anv\u00e4nda MMR:<\/p>\n Nackdelen med att inf\u00f6ra MMR \u00e4r dock komplexiteten och sv\u00e5righeten att l\u00f6sa konflikter.<\/p>\n Flera grenar och program tillhandah\u00e5ller MMR-l\u00f6sningar eftersom PostgreSQL inte har n\u00e5got inbyggt st\u00f6d f\u00f6r detta. Dessa l\u00f6sningar kan vara med \u00f6ppen k\u00e4llkod<\/a>, kostnadsfria eller betalda. Ett s\u00e5dant till\u00e4gg<\/a> \u00e4r bidirektionell replikering (BDR) som \u00e4r asynkron och bygger p\u00e5 PostgreSQL’s logiska avkodningsfunktion.<\/p>\n Eftersom BDR-applikationen \u00e5terger transaktioner p\u00e5 andra noder s\u00e5 kan \u00e5tergivningsoperationen misslyckas om det finns en konflikt mellan den transaktion som till\u00e4mpas och den transaktion som har bekr\u00e4ftats p\u00e5 den mottagande noden.<\/p>\n Det finns tv\u00e5 typer av PostgreSQL-replikering: logisk och fysisk replikering.<\/p>\n En enkel logisk<\/em> operation – Fysisk replikering handlar vanligtvis om filer och kataloger. Den vet inte vad dessa filer och kataloger representerar. Som ett resultat av dessa metoder s\u00e5 uppr\u00e4tth\u00e5lls en fullst\u00e4ndig kopia av alla data i ett enskilt kluster. Det sker vanligtvis p\u00e5 en annan maskin, och g\u00f6rs p\u00e5 filsystemniv\u00e5 eller diskniv\u00e5 och anv\u00e4nder exakta blockadresser.<\/p>\n Logisk replikering \u00e4r ett s\u00e4tt att reproducera dataenheter och deras \u00e4ndringar, baserat p\u00e5 deras replikeringsidentitet (vanligtvis en prim\u00e4rnyckel). Till skillnad fr\u00e5n fysisk replikering s\u00e5 handlar den om databaser, tabeller och DML-operationer och utf\u00f6rs p\u00e5 databasklusterniv\u00e5. Den anv\u00e4nder en publicerings-<\/em> och prenumerationsmodell<\/em> d\u00e4r en eller flera prenumeranter<\/em> prenumererar p\u00e5 en eller flera publikationer<\/em>\u00a0 av en publiceringsnod<\/em>.<\/p>\n Replikeringsprocessen b\u00f6rjar med att ta en \u00f6gonblicksbild av data i publiceringsdatabasen och sedan kopiera den till prenumeranten. Prenumeranterna h\u00e4mtar data fr\u00e5n de publikationer som de prenumererar p\u00e5 och kan publicera data p\u00e5 nytt senare. De kan exempelvis m\u00f6jligg\u00f6ra kaskad-replikering eller mer komplexa konfigurationer. Prenumeranten till\u00e4mpar data i samma ordning som utgivaren s\u00e5 att transaktionskonsistens garanteras f\u00f6r publikationer inom en enda prenumeration, \u00e4ven kallat transaktions-replikering.<\/p>\n De typiska anv\u00e4ndningsomr\u00e5dena f\u00f6r logisk replikering \u00e4r f\u00f6ljande:<\/p>\n Prenumerant-databasen beter sig p\u00e5 samma s\u00e4tt som alla andra PostgreSQL-instanser. Den kan anv\u00e4ndas som utgivare f\u00f6r andra databaser genom att definiera dess publikationer.<\/p>\n N\u00e4r prenumeranten behandlas som skrivskyddad av applikationen s\u00e5 blir det inga konflikter fr\u00e5n en enda prenumeration. Om det d\u00e4remot finns andra skrivningar som antingen g\u00f6rs av en applikation eller av andra prenumeranter till samma upps\u00e4ttning tabeller kan s\u00e5 konflikter uppst\u00e5.<\/p>\n PostgreSQL st\u00f6der b\u00e5da mekanismerna samtidigt. Logisk replikering till\u00e5ter finkornig kontroll \u00f6ver b\u00e5de datareplikering och s\u00e4kerhet.<\/p>\n Det finns huvudsakligen tv\u00e5 l\u00e4gen f\u00f6r PostgreSQL-replikering: synkron och asynkron. Synkron replikering till\u00e5ter att data skrivs till b\u00e5de den prim\u00e4ra och sekund\u00e4ra servern samtidigt. Asynkron replikering s\u00e4kerst\u00e4ller att data f\u00f6rst skrivs till hosten och sedan kopieras till den sekund\u00e4ra servern.<\/p>\n Vid replikering i synkront l\u00e4ge s\u00e5 anses transaktioner i den prim\u00e4ra databasen vara avslutade f\u00f6rst n\u00e4r \u00e4ndringarna har replikerats till alla replikor. Replikerings-servrarna m\u00e5ste vara tillg\u00e4ngliga hela tiden f\u00f6r att transaktionerna ska kunna slutf\u00f6ras p\u00e5 den prim\u00e4ra. Det synkrona replikerings-l\u00e4get anv\u00e4nds i avancerade transaktionsmilj\u00f6er med krav p\u00e5 omedelbar v\u00e4xling vid fel.<\/p>\n I asynkront l\u00e4ge s\u00e5 \u00e4r transaktioner p\u00e5 den prim\u00e4ra servern slutf\u00f6rda n\u00e4r \u00e4ndringarna har gjorts p\u00e5 endast den prim\u00e4ra servern. Dessa \u00e4ndringar replikeras senare i replikorna. Replikerings-servrarna kan f\u00f6rbli osynkroniserade under en viss tid, vilket kallas replikerings-f\u00f6rdr\u00f6jning. Vid en krasch s\u00e5 kan det uppst\u00e5 dataf\u00f6rlust. Det \u00f6verskott som asynkron replikering ger \u00e4r dock v\u00e4ldigt litet, s\u00e5 det \u00e4r acceptabelt i de flesta fall (det \u00f6verbelastar inte hosten). Failover fr\u00e5n den prim\u00e4ra databasen till den sekund\u00e4ra databasen tar l\u00e4ngre tid \u00e4n synkron replikering.<\/p>\n I det h\u00e4r avsnittet s\u00e5 kommer vi att demonstrera hur man st\u00e4ller in PostgreSQL-replikeringsprocessen p\u00e5 ett Linux-operativsystem. I det h\u00e4r fallet s\u00e5 anv\u00e4nder vi Ubuntu 18.04 LTS och PostgreSQL 10.<\/p>\n
\nVad \u00e4r PostgreSQL-replikering?<\/h2>\n
![\"Illustration](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Vad \u00e4r automatisk v\u00e4xling?<\/h3>\n
F\u00f6rdelar med att anv\u00e4nda PostgreSQL-replikering<\/h2>\n
\n
Hur PostgreSQL-replikering fungerar<\/h2>\n
\n
Metod 1: Str\u00f6mning<\/h3>\n
Konfigurera den prim\u00e4ra noden<\/h4>\n
Steg 1: Initialisera databasen<\/h5>\n
initdb<\/code>. D\u00e4refter s\u00e5 kan du skapa en ny anv\u00e4ndare med replikerings-r\u00e4ttigheter med hj\u00e4lp av f\u00f6ljande kommando:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nSteg 2: Konfigurera egenskaper f\u00f6r str\u00f6mning<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code>:<\/strong> Den h\u00e4r parametern kr\u00e4vs f\u00f6r pg_rewind<\/code>-funktionen som \u00e4r praktisk n\u00e4r reservservern inte \u00e4r synkroniserad med den prim\u00e4ra servern.<\/li>\nwal_level<\/code>:<\/strong> Du kan anv\u00e4nda den h\u00e4r parametern f\u00f6r att aktivera PostgreSQL str\u00f6mings-replikering, med m\u00f6jliga v\u00e4rden som minimal<\/code>, replica<\/code> eller logical<\/code>.<\/li>\nmax_wal_size<\/code>:<\/strong> Detta kan anv\u00e4ndas f\u00f6r att ange storleken p\u00e5 WAL-filer som kan beh\u00e5llas i loggfiler.<\/li>\nhot_standby<\/code>:<\/strong> Du kan utnyttja den h\u00e4r parametern f\u00f6r en anslutning till den sekund\u00e4ra datorn n\u00e4r den \u00e4r inst\u00e4lld p\u00e5 ON.<\/li>\nmax_wal_senders<\/code>:<\/strong> Du kan anv\u00e4nda max_wal_senders<\/code> f\u00f6r att ange det maximala antalet samtidiga anslutningar som kan uppr\u00e4ttas med reserv-servrarna.<\/li>\n<\/ul>\nSteg 3: Skapa en ny post<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> att ansluta och agera som reserv-server genom att anv\u00e4nda den angivna IP-adressen f\u00f6r replikering. Exempelvis:<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nKonfigurera standby-nod<\/h4>\n
Steg 1: S\u00e4kerhetskopiera den prim\u00e4ra noden<\/h5>\n
pg_basebackup<\/code> f\u00f6r att skapa en s\u00e4kerhetskopia av den prim\u00e4ra noden. Detta kommer att fungera som utg\u00e5ngspunkt f\u00f6r standby-noden. Du kan anv\u00e4nda det h\u00e4r verktyget med f\u00f6ljande syntax:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code>:<\/strong> Du kan anv\u00e4nda detta f\u00f6r att ange den prim\u00e4ra hosten.<\/li>\n-D<\/code>:<\/strong> Den h\u00e4r parametern anger den katalog som du f\u00f6r n\u00e4rvarande arbetar i.<\/li>\n-C<\/code>:<\/strong> Du kan anv\u00e4nda den h\u00e4r parametern f\u00f6r att ange kontrollpunkter.<\/li>\n-X<\/code>:<\/strong> Den h\u00e4r parametern kan anv\u00e4ndas f\u00f6r att inkludera de n\u00f6dv\u00e4ndiga transaktionsloggfilerna.<\/li>\n-W<\/code>:<\/strong> Du kan anv\u00e4nda den h\u00e4r parametern f\u00f6r att uppmana anv\u00e4ndaren att ange ett l\u00f6senord innan anslutning till databasen.<\/li>\n<\/ul>\nSteg 2: Konfigurera konfigurationsfilen f\u00f6r replikering<\/h5>\n
-R<\/code> i verktyget pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'\n\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'\n\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n\n
primary_conninfo<\/code>:<\/strong> Du kan anv\u00e4nda detta f\u00f6r att skapa en anslutning mellan den prim\u00e4ra och sekund\u00e4ra servern genom att anv\u00e4nda en anslutningsstr\u00e4ng.<\/li>\nstandby_mode<\/code>:<\/strong> Den h\u00e4r parametern kan f\u00e5 den prim\u00e4ra servern att starta som standby-server n\u00e4r den sl\u00e5s p\u00e5.<\/li>\nrecovery_target_timeline<\/code>:<\/strong> Du kan anv\u00e4nda den h\u00e4r parametern f\u00f6r att st\u00e4lla in \u00e5terh\u00e4mtningstiden.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nSteg 3: Starta om den sekund\u00e4ra servern<\/h5>\n
\n
Metod 2: Replikerad blockenhet<\/h3>\n
Metod 3: WAL<\/h3>\n
Replikering baserad p\u00e5 loggtransport (blockniv\u00e5)<\/h4>\n
Replikering baserad p\u00e5 loggtransport (filniv\u00e5)<\/h4>\n
Kontinuerlig arkivering av WAL-filer<\/h4>\n
pg_wal<\/code> f\u00f6r att arkiveras. PostgreSQL anropar ett skript som anv\u00e4ndaren har angett f\u00f6r arkivering varje g\u00e5ng som en WAL-fil skapas.<\/p>\nscp<\/code> f\u00f6r att duplicera filen till en eller flera platser, t.ex. en NFS-montering. Som ett resultat av arkiveringen s\u00e5 kan WAL-segmentfilerna anv\u00e4ndas f\u00f6r att \u00e5terst\u00e4lla databasen vid vilken tidpunkt som helst.<\/p>\n\n
Detaljer om WAL-str\u00f6mningsprotokollet<\/h4>\n
primary_conninfo<\/code> i recovery.conf<\/strong>. Den ansluter till den prim\u00e4ra servern genom att utnyttja en TCP\/IP-anslutning.<\/p>\n![\"Fl\u00f6desdiagram](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Element av PostgreSQL-replikering<\/h2>\n
Modeller f\u00f6r PostgreSQL-databasreplikering<\/h3>\n
\n
Typer av PostgreSQL-replikering<\/h3>\n
initdb<\/code> – skulle exempelvis utf\u00f6ra den fysiska operationen att skapa en baskatalog f\u00f6r ett kluster. P\u00e5 samma s\u00e4tt s\u00e5 skulle en enkel logisk<\/em> operation CREATE DATABASE<\/code> utf\u00f6ra den fysiska<\/em> operationen att skapa en underkatalog i baskatalogen.<\/p>\n\n
Replikeringsmetoder<\/h3>\n
S\u00e5 h\u00e4r st\u00e4ller du in PostgreSQL-replikering<\/h2>\n