Switchover/Switchback i Slony-I medan du uppgraderar PostgreSQL huvudversioner 8.4.x/9.3.x

Varje ny version av PostgreSQL kommer med ett paket med spännande funktioner. För att dra nytta av nya funktioner bör databasservern uppgraderas. Att välja traditionella uppgraderingsvägar som pg_dump/pg_restore eller pg_upgrade kräver en betydande stilleståndstid för applikationen. Idag, om du letar efter minsta uppgraderingsväg för driftstopp bland större PostgreSQL-versioner med perfekt återställningsplan, kommer det att åstadkommas genom asynkron Slony-I-replikering. Eftersom Slony-I (vet mer om det här) har förmågan att enkelt replikera mellan olika PostgreSQL-versioner, OS och bitarkitekturer, så uppgraderingar är genomförbara utan att det krävs en betydande stilleståndstid. Dessutom har den en konsekvent switchover- och switchback-funktion i sin design.

IMO, när man gör större versionsuppgraderingar bör det finnas en ordentlig reservplan, för bara om applikationen visar sig vara buggig eller inte fungerar bra på den uppgraderade versionen, så borde vi kunna återställa till äldre version omedelbart. Slony-I tillhandahåller sådan funktionalitet i vägen för switchback. Det här inlägget visar uppgradering av minsta stilleståndstid inklusive steg för övergång/återkoppling.

Innan du går till demo, ett viktigt steg att notera, tidigare till PG 9.0.x version bytea datatyp kolumner använder för att lagra data i ESCAPE-format och senare version i HEX-format. När du utför återställning (nyare version till äldre version) stöds inte denna typ av bytea-formatskillnader av Slony-I, därför bör ESCAPE-formatet bibehållas under uppgraderingens varaktighet, annars kan du stöta på ett fel:

ERROR  remoteWorkerThread_1_1: error at end of COPY IN: ERROR:  invalid input syntax for type bytea
CONTEXT:  COPY sl_log_1, line 1: "1     991380  1       100001  public  foo I       0       {id,500003,name,"A         ",b,"\\x41"}"
ERROR  remoteWorkerThread_1: SYNC aborted

För att fixa, inga ändringar krävs på PG 8.4.x men på PG 9.3.5 bytea_output parameter bör ställas in från HEX till ESCAPE som visas. Vi kan ställa in det på klusternivå ($PGDATA/postgresql.conf) eller användarnivå (ALTER TABLE...SET), jag har föredragit att gå med ändringar på användarnivå.

slavedb=# alter user postgres set bytea_output to escape;
ALTER ROLE

Låt oss fortsätta med uppgraderingsstegen. Nedan är mina serverdetaljer för två versioner som används i den här demon, ändra den i enlighet med din serverkonfiguration om du försöker:

Origin Node (Master/Primary are called as Origin)                     Subscriber Node (Slave/Secondary are called as Subscriber)
-------------------------------------------------                     ----------------------------------------------------------
Host IP     : 192.168.22.130                                          192.168.22.131
OS Version  : RHEL 6.5 64 bit                                         RHEL 6.5 64 bit 
PG Version  : 8.4.22 (5432 Port)                                      9.3.5 (5432 Port)
Slony Vers. : 2.2.2                                                   2.2.2
PG Binaries : /usr/local/pg84/bin                                     /opt/PostgreSQL/9.3/
Database    : masterdb                                                slavedb 
PK Table    : foo(id int primary key, name char(20), image bytea)     ...restore PK tables structure from Origin...

För enkel förståelse och enkel implementering har jag delat in demo i tre avsnitt

1. Kompilera för Slony-I-binärer mot PostgreSQL-versioner
2. Skapa replikeringsskript och exekvera
3. Testar Switchover/Switchback.

1. Kompilera för Slony-I-binärer mot PostgreSQL-version
Ladda ner Slony-I-källor härifrån och utför källinstallation mot PostgreSQL-binärfiler på Origin- och Subscriber-noder.

On Origin Node:
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgbindir=/usr/local/pg84/bin 
            --with-pglibdir=/usr/local/pg84/lib 
            --with-pgincludedir=/usr/local/pg84/include 
            --with-pgpkglibdir=/usr/local/pg84/lib/postgresql 
            --with-pgincludeserverdir=/usr/local/pg84/include/postgresql/
make 
make install

On Subscriber Node: (assuming PG 9.3.5 installed)
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgconfigdir=/opt/PostgreSQL/9.3/bin 
            --with-pgbindir=/opt/PostgreSQL/9.3/bin 
            --with-pglibdir=/opt/PostgreSQL/9.3/lib 
            --with-pgincludedir=/opt/PostgreSQL/9.3/include 
            --with-pgpkglibdir=/opt/PostgreSQL/9.3/lib/postgresql 
            --with-pgincludeserverdir=/opt/PostgreSQL/9.3/include/postgresql/server/ 
            --with-pgsharedir=/opt/PostgreSQL/9.3/share
make 
make install

2. Skapa replikeringsskript och exekvera
För att ställa in replikering behöver vi skapa ett fåtal skript som tar hand om replikering inklusive byte/switchback.

1. initialize.slonik – Det här skriptet innehåller anslutningsinformationen för Origin/Subscriber-noderna.
2. create_set.slonik – Det här skriptet innehåller alla Origin PK-tabeller som replikerar till Subscriber Node.
3. subscribe_set.slonik – Det här skriptet börjar replikera setdata till Subscriber Node.
4. switchover.slonik – Det här skriptet hjälper till att flytta kontrollen från Origin till Subscriber.
5. switchback.slonik – Det här skriptet hjälper till med reservkontroll från prenumerant till Origin.

Slutligen, ytterligare två startskript “start_OriginNode.sh” och “start_SubscriberNode.sh” som startar slon-processer enligt binärfilerna som kompileras på Origin/Subscriber Nodes.

Ladda ner alla skript härifrån.

Här är exempeldata om Origin Node(8.4.22) i Foo Table med en kolumn med bytea-datatyp, som vi kommer att replikera till Subscriber Node(9.3.5) med hjälp av skapade skript.

masterdb=# select * from foo;
 id |         name         | image
----+----------------------+-------
  1 | Raghav               | test1
  2 | Rao                  | test2
  3 | Rags                 | test3
(3 rows)

Låt oss anropa skripten ett efter ett för att ställa in replikering. KOM IHÅG ATT ALLA SLONIK-SKRIPT SKA UTFÖRAS ENDAST PÅ ORIGIN NODE, UTOM "start_OriginNode.sh" OCH "start_SubscriberNode.sh" SOM SKA UTFÖRAS INDIVIDUELLT.

-bash-4.1$ slonik initalize.slonik
-bash-4.1$ slonik create_set.slonik
create_set.slonik:13: Set 1 ...created
create_set.slonik:16: PKey table *** public.foo *** added.
-bash-4.1$ sh start_OriginNode.sh      
-bash-4.1$ sh start_SubscriberNode.sh  //ON SUBSCRIBER NODE   
-bash-4.1$ slonik subscribe_set.slonik

Efter framgångsrik exekvering av ovanstående skript kan du märka att data på Origin(masterdb) har replikerats till Subscriber(slavedb). Tillåter inte heller någon DML-operation på abonnentnod:

slavedb=# select * from foo;
 id |         name         | image
----+----------------------+-------
  1 | Raghav               | test1
  2 | Rao                  | test2
  3 | Rags                 | test3
(3 rows)

slavedb=# insert into foo values (4,'PG-Experts','Image2');
ERROR:  Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

Coolt... Vi har flyttat data till en nyare version av PostgreSQL 9.3.5. Om du i det här skedet känner att all data har replikerats till Subscriber Node, kan du göra en övergång.

3. Testar Switchover/Switchback.

Låt oss byta till den senaste versionen med skriptet och prova att infoga data på abonnent-/ursprungsnoder.

-bash-4.1$ slonik switchover.slonik
switchover.slonik:8: Set 1 has been moved from Node 1 to Node 2

slavedb=# insert into foo values (4,'PG-Experts','Image2');
INSERT 0 1

masterdb=# select * from foo ;
 id |         name         | image
----+----------------------+-------
  1 | Raghav               | test1
  2 | Rao                  | test2
  3 | Rags                 | test3
  4 | PG-Experts           | Image2
(4 rows)

masterdb=# insert into foo values (5,'PG-Experts','Image3');
ERROR:  Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

Perfekt... Det här är vad vi letar efter, nu slavedb(Subscriber Node) kör PG 9.3.5 version som accepterar data och masterdb(Origin Node) tar emot slavedb-data. Även dess avvisande DML:er exekveras på masterdb.

Slony-I Logs visar ursprungs-/abonnentnod-id-rörelserna vid tidpunkten för övergången:

2014-12-12 04:55:06 PST CONFIG moveSet: set_id=1 old_origin=1 new_origin=2
2014-12-12 04:55:06 PST CONFIG storeListen: li_origin=1 li_receiver=2 li_provider=1
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: update provider configuration
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: helper thread for provider 1 terminated
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: disconnecting from data provider 1
...
...
2014-12-12 04:55:11 PST INFO   start processing ACCEPT_SET
2014-12-12 04:55:11 PST INFO   ACCEPT: set=1
2014-12-12 04:55:11 PST INFO   ACCEPT: old origin=1
2014-12-12 04:55:11 PST INFO   ACCEPT: new origin=2
2014-12-12 04:55:11 PST INFO   ACCEPT: move set seq=5000006393
2014-12-12 04:55:11 PST INFO   got parms ACCEPT_SET

Om du stöter på några problem i detta skede kan du byta tillbaka till äldre version. Efter återgång kan du fortsätta med äldre version tills din ansökan eller andra problem har åtgärdats. Detta är den perfekta återställningsplanen utan att slösa mycket tid i händelse av problem efter övergången...

-bash-4.1$ slonik switchback.slonik
switchback.slonik:8: Set 1 has been moved from Node 2 to Node 1

slavedb=# insert into foo values (5,'PG-Experts','Image3');
ERROR:  Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

masterdb=# insert into foo values (5,'PG-Experts','Image3');
INSERT 0 1

slavedb=# select * from foo ;
 id |         name         | image
----+----------------------+-------
  1 | Raghav               | test1
  2 | Rao                  | test2
  3 | Rags                 | test3
  4 | PG-Experts           | Image2
  5 | PG-Experts           | Image3
(5 rows)

Mycket trevligt…!!! Är inte detta den exakta återställningen med minsta stilleståndstid? Ja, det är en perfekt växling mellan noder utan att missa en transaktion.

Loggar som visar återgången från prenumerant till ursprungsnod:

2014-12-12 04:58:45 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
2014-12-12 04:58:45 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: update provider configuration
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: helper thread for provider 2 terminated
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: disconnecting from data provider 2
2014-12-12 04:58:46 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
...
...
2014-12-12 04:58:47 PST INFO   start processing ACCEPT_SET
2014-12-12 04:58:47 PST INFO   ACCEPT: set=1
2014-12-12 04:58:47 PST INFO   ACCEPT: old origin=2
2014-12-12 04:58:47 PST INFO   ACCEPT: new origin=1
2014-12-12 04:58:47 PST INFO   ACCEPT: move set seq=5000006403
2014-12-12 04:58:47 PST INFO   got parms ACCEPT_SET
2014-12-12 04:58:48 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1

Vid det här laget kanske du har märkt att inga av transaktionerna går förlorade under växling mellan PostgreSQL-versioner. Endast driftstopp kan vara din ansökan om att starta/stoppa för att ansluta till Origin- och Subscriber-noder, men medan Origin/Subscriber-noder aldrig tas ner är de bara igång.

Kom ihåg att metoden som visas här inte bara är användbar för uppgraderingar, men det är samma metod i Slony-I för att flytta mellan noder.

Tack för ditt tålamod :). Hoppas att det här inlägget hjälper dig att uppgradera PostgreSQL med minsta möjliga driftstopp med Slony-I inklusive korrekt återställningsplan.