Overschakelen/terugschakelen in Slony-I tijdens het upgraden van PostgreSQL-hoofdversies 8.4.x/9.3.x

Elke nieuwe release van PostgreSQL wordt geleverd met een heleboel opwindende functies. Om van nieuwe functies te profiteren, moet de databaseserver worden geüpgraded. Het kiezen van traditionele upgradepaden zoals pg_dump/pg_restore of pg_upgrade vereist een aanzienlijke downtime van de applicatie. Als u tegenwoordig op zoek bent naar een minimaal downtime-upgradepad tussen de belangrijkste PostgreSQL-versies met een perfect terugdraaiplan, dan wordt dit bereikt door asynchrone Slony-I-replicatie. Aangezien Slony-I (hier meer over te weten) de mogelijkheid heeft om gemakkelijk te repliceren tussen verschillende PostgreSQL-versies, besturingssystemen en bit-architecturen, zijn upgrades mogelijk zonder een substantiële downtime. Bovendien heeft het een consistente omschakel- en terugschakelfunctionaliteit in zijn ontwerp.

IMO, tijdens het uitvoeren van grote versie-upgrades zou er een goed fallback-plan moeten zijn, want voor het geval dat de applicatie bugs vertoont of niet goed presteert op de geüpgradede versie, dan zouden we in staat moeten zijn om onmiddellijk terug te gaan naar de oudere versie. Slony-I biedt dergelijke functionaliteit in de vorm van terugschakelen. Dit bericht demonstreert, minimale downtime-upgrade inclusief stappen voor omschakelen/terugschakelen.

Alvorens naar de demo te gaan, moet een belangrijke stap worden opgemerkt, eerder in PG 9.0.x-versie worden bytea-gegevenstypekolommen gebruikt om gegevens op te slaan in ESCAPE-indeling en latere versie in HEX-indeling. Tijdens het uitvoeren van switchback (nieuwere versie naar oudere versie), worden dit soort bytea-indelingsverschillen niet ondersteund door Slony-I, daarom moet de ESCAPE-indeling behouden blijven tijdens de upgradeduur, anders kunt u een fout tegenkomen:

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

Om dit op te lossen, zijn er geen wijzigingen vereist op PG 8.4.x, maar op PG 9.3.5 moet de bytea_output-parameter worden ingesteld van HEX naar ESCAPE, zoals weergegeven. We kunnen het op clusterniveau ($PGDATA/postgresql.conf) of gebruikersniveau (ALTER TABLE...SET) instellen, ik heb liever veranderingen op gebruikersniveau doorgevoerd.

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

Laten we doorgaan met de upgradestappen. Hieronder staan de servergegevens van mijn twee versies die in deze demo worden gebruikt. Wijzig deze dienovereenkomstig volgens uw serverconfiguratie als u het probeert:

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

Voor een eenvoudig begrip en gemakkelijke implementatie heb ik de demo in drie secties verdeeld

1. Compileren voor Slony-I binaries tegen PostgreSQL-versies
2. Replicatiescripts maken en uitvoeren
3. Omschakeling/Switchback testen.

1. Compileren voor Slony-I binaries tegen PostgreSQL-versie
Download Slony-I-bronnen van hier en voer de broninstallatie uit tegen PostgreSQL-binaire bestanden op Origin- en Subscriber-knooppunten.

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. Replicatiescripts maken en uitvoeren
Om replicatie in te stellen, hebben we enkele scripts nodig die voor replicatie zorgen, inclusief switchover/switchback.

1. initialize.slonik – Dit script bevat de verbindingsinformatie van de Origin/Abonnee-knooppunten.
2. create_set.slonik – Dit script bevat alle Origin PK-tabellen die repliceren naar Subscriber Node.
3. subscribe_set.slonik – Dit script begint setgegevens te repliceren naar Subscriber Node.
4. switchover.slonik – Dit script helpt om de besturing van Origin naar Abonnee te verplaatsen.
5. switchback.slonik – Dit script helpt bij het terugvallen van controle van Abonnee naar Origin.

Tot slot nog twee opstartscripts “start_OriginNode.sh” en “start_SubscriberNode.sh” die slon-processen start volgens de binaire bestanden die zijn gecompileerd op Origin/Subscriber Nodes.

Download hier alle scripts.

Hier zijn de voorbeeldgegevens op Origin Node (8.4.22) in Foo Table met een kolom met bytea-gegevenstype, die we zullen repliceren naar Subscriber Node (9.3.5) met behulp van gemaakte scripts.

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

Laten we de scripts een voor een aanroepen om replicatie in te stellen. DENK ERAAN ALLE SLONIK-SCRIPT UITSLUITEND OP ORIGIN NODE MOET WORDEN UITGEVOERD, BEHALVE "start_OriginNode.sh" EN "start_SubscriberNode.sh" DIE INDIVIDUEEL MOETEN WORDEN UITGEVOERD.

-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

Na succesvolle uitvoering van het bovenstaande script, kunt u zien dat de gegevens op Origin (masterdb) zijn gerepliceerd naar Subscriber (slavedb). Ook geen enkele DML-bewerking op het abonneeknooppunt toestaan:

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... We hebben gegevens verplaatst naar een nieuwere versie van PostgreSQL 9.3.5. Als u in dit stadium denkt dat alle gegevens zijn gerepliceerd naar Subscriber Node, kunt u overstappen.

3. Overschakelen/terugschakelen testen.

Laten we overschakelen naar de nieuwste versie met het script en proberen gegevens in te voegen op abonnee-/oorsprongsknooppunten.

-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

Perfect ... Dit is wat we zoeken, nu slavedb (Subscriber Node) met PG 9.3.5-versie die gegevens accepteert en masterdb (Origin Node) die de slavedb-gegevens ontvangt. Ook het afwijzen van DML's uitgevoerd op masterdb.

Slony-I Logs toont de oorsprong/abonnee node id bewegingen op het moment van omschakeling:

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

Als u in dit stadium problemen ondervindt, kunt u terugschakelen naar een oudere versie. Na terugschakelen kunt u doorgaan met de oudere versie totdat uw toepassing of andere problemen zijn opgelost. Dit is het perfecte terugdraaiplan zonder veel tijd te verspillen in het geval van problemen na de omschakeling..

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

Erg fijn…!!! Is dit niet de exacte rollback met minimale downtime? Ja, het is perfect schakelen tussen knooppunten zonder een transactie te missen.

Logboeken met de terugschakeling van Abonnee naar Origin Node:

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

Tegen die tijd is het je misschien opgevallen dat geen van de transacties verloren gaat tijdens het schakelen tussen PostgreSQL-versies. Enige downtime kan uw applicatie zijn om te starten/stoppen om verbinding te maken met Origin- en Subscriber-knooppunten, maar terwijl Origin/Abonnee-knooppunten nooit worden verwijderd, zijn ze gewoon in gebruik.

Onthoud dat de hier getoonde methode niet alleen handig is voor upgrades, maar het is dezelfde methode in Slony-I voor het verplaatsen tussen Nodes.

Bedankt voor je geduld :). Ik hoop dat dit bericht je helpt om PostgreSQL te upgraden met minimale downtime met behulp van Slony-I, inclusief een goed terugdraaiplan.