Switchover/Switchback i Slony-I under opgradering af PostgreSQL større versioner 8.4.x/9.3.x

Hver ny udgivelse af PostgreSQL kommer med en række spændende funktioner. For at drage fordel af nye funktioner bør databaseserveren opgraderes. At vælge traditionelle opgraderingsstier som pg_dump/pg_restore eller pg_upgrade kræver en betydelig nedetid for applikationen. I dag, hvis du leder efter minimal nedetid opgraderingssti blandt større PostgreSQL-versioner med perfekt tilbagerulningsplan, så vil det blive opnået ved asynkron Slony-I-replikering. Da Slony-I (ved mere om det her) har evnen til nemt at replikere mellem forskellige PostgreSQL-versioner, OS og bit-arkitekturer, så opgraderinger er mulige uden at kræve en væsentlig nedetid. Derudover har den en konsekvent switchover og switchback funktionalitet i sit design.

IMO, mens du laver større versionsopgraderinger, bør der være en ordentlig reserveplan, fordi bare hvis applikationen viser sig at være fejlbehæftet eller ikke klarer sig godt på opgraderet version, så burde vi være i stand til at rulle tilbage til ældre version med det samme. Slony-I giver en sådan funktionalitet i vejen for switchback. Dette indlæg demonstrerer opgradering af minimum nedetid inklusive overgangs-/tilbagekoblingstrin.

Før du går til demo, et vigtigt skridt, der skal bemærkes, tidligere til PG 9.0.x version bytea datatype kolonner bruger til at gemme data i ESCAPE format og senere version dens i HEX format. Mens du udfører tilbageskiftning (nyere version til ældre version), understøttes denne form for bytea-formatforskelle ikke af Slony-I, og ESCAPE-formatet bør derfor opretholdes gennem hele opgraderingens varighed, ellers kan du støde på en fejl:

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

For at rette, skal der ikke kræves ændringer på PG 8.4.x, men på PG 9.3.5 bytea_output parameteren skal indstilles fra HEX til ESCAPE som vist. Vi kan indstille det på klyngeniveau ($PGDATA/postgresql.conf) eller brugerniveau (ALTER TABLE…SET), jeg har foretrukket at gå med ændringer på brugerniveau.

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

Lad os fortsætte med opgraderingstrinene. Nedenfor er mine to versioner serveroplysninger, der bruges i denne demo, ændre det i overensstemmelse hermed i henhold til din serveropsætning, hvis du prøver:

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...

For enkel forståelse og nem implementering har jeg opdelt demo i tre sektioner

1. Kompilere for Slony-I binære filer mod PostgreSQL-versioner
2. Oprettelse af replikeringsscripts og eksekvering
3. Test af Switchover/Switchback.

1. Kompilere for Slony-I binære filer mod PostgreSQL version
Download Slony-I kilder herfra, og udfør kildeinstallation mod PostgreSQL binære filer på Origin og 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. Oprettelse af replikeringsscripts og udførelse
For at konfigurere replikering skal vi lave nogle få scripts, der tager sig af replikering, inklusive omskiftning/omskiftning.

1. initialize.slonik – Dette script indeholder oprindelses-/abonnentknudeforbindelsesoplysninger.
2. create_set.slonik – Dette script indeholder alle Origin PK-tabeller, der replikeres til Subscriber Node.
3. subscribe_set.slonik – Dette script begynder at replikere sæt data til Subscriber Node.
4. switchover.slonik – Dette script hjælper med at flytte kontrol fra Origin til Subscriber.
5. switchback.slonik – Dette script hjælper med at genvinde kontrol fra abonnent til oprindelse.

Til sidst to opstartsscripts mere “start_OriginNode.sh” og “start_SubscriberNode.sh” der starter slon-processer i henhold til de binære filer kompileret på Origin/Subscriber Nodes.

Download alle scripts herfra.

Her er eksempeldataene om Origin Node (8.4.22) i Foo Table med en kolonne med bytea-datatype, som vi vil replikere til Subscriber Node (9.3.5) ved hjælp af oprettede scripts.

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

Lad os kalde scripts en efter en for at opsætte replikering. HUSK ALLE SLONIK SCRIPT SKAL KUN UDFØRES PÅ ORIGIN NODE, UNDTAGET "start_OriginNode.sh" OG "start_SubscriberNode.sh", SOM SKAL UDFØRES INDIVIDUELT.

-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 vellykket udførelse af ovenstående script kan du bemærke, at dataene på Origin(masterdb) er replikeret til Subscriber(slavedb). Tillader heller ikke nogen DML-handling på Subscriber node:

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

Cool... Vi har flyttet data til nyere version af PostgreSQL 9.3.5. Hvis du på dette tidspunkt føler, at alle data er replikeret til Subscriber Node, så kan du skifte.

3. Tester Switchover/Switchback.

Lad os skifte til den nyeste version med scriptet og prøve at indsætte data på Subscriber/Origin Nodes.

-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 er det, vi leder efter, nu slavedb(Subscriber Node) kører PG 9.3.5-versionen og accepterer data og masterdb(Origin Node) modtager slavedb-dataene. Også dens afvisende DML'er udført på masterdb.

Slony-I Logs viser oprindelses-/abonnentknude-id-bevægelserne på tidspunktet for overgangen:

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

Hvis du støder på problemer på dette trin, kan du skifte tilbage til den ældre version. Efter tilbageskiftning kan du fortsætte med ældre version, indtil din applikation eller andre problemer er løst. Dette er den perfekte tilbagerulningsplan uden at spilde meget tid i tilfælde af problemer efter overgangen...

-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)

Meget fint…!!! Er dette ikke den nøjagtige tilbagerulning med minimal nedetid? Ja, det er et perfekt skift mellem noder uden at gå glip af en transaktion.

Logfiler, der viser tilbageskiftet fra abonnent til oprindelsesknude:

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

På dette tidspunkt har du måske bemærket, at ingen af transaktionerne går tabt under skift mellem PostgreSQL-versioner. Kun nedetid kan være din ansøgning om at starte/stoppe for at oprette forbindelse til Origin- og Subscriber-noder, men mens Origin-/Subscriber-noder aldrig bliver fjernet, er de bare oppe og køre.

Husk, metoden vist her er ikke kun nyttig til opgraderinger, men den er den samme metode i Slony-I til at flytte mellem noder.

Tak for din tålmodighed :). Håber, at dette indlæg hjælper dig med at opgradere PostgreSQL med minimal nedetid ved hjælp af Slony-I, inklusive korrekt tilbagerulningsplan.