Přepnutí/přepnutí v Slony-I při upgradu PostgreSQL hlavních verzí 8.4.x/9.3.x

Každá nová verze PostgreSQL přichází s řadou zajímavých funkcí. Aby bylo možné využívat nové funkce, je třeba upgradovat databázový server. Volba tradičních cest upgradu jako pg_dump/pg_restore nebo pg_upgrade vyžaduje značné prostoje aplikace. Pokud dnes hledáte cestu upgradu s minimálními prostoji mezi hlavními verzemi PostgreSQL s dokonalým plánem vrácení zpět, pak toho bude dosaženo asynchronní replikací Slony-I. Protože Slony-I (více o něm zde) má schopnost snadno se replikovat mezi různými verzemi PostgreSQL, OS a bitovými architekturami, takže upgrady jsou proveditelné, aniž by vyžadovaly podstatné prostoje. Kromě toho má ve svém designu konzistentní funkce přepínání a přepínání.

IMO, při provádění hlavních upgradů verzí by měl existovat správný záložní plán, protože v případě, že se aplikace ukáže jako chybná nebo selže na upgradované verzi, měli bychom být schopni okamžitě vrátit zpět na starší verzi. Slony-I poskytuje takovou funkcionalitu způsobem přepínání. Tento příspěvek demonstruje minimální upgradování prostojů včetně kroků přepnutí/přepnutí zpět.

Než přejdete na ukázku, je třeba poznamenat jeden důležitý krok, dříve k verzi PG 9.0.x se sloupce datového typu byte používají k ukládání dat ve formátu ESCAPE a novější verze ve formátu HEX. Při provádění přechodu (novější verze na starší verzi) Slony-I tento druh rozdílů ve formátu bajtů nepodporuje, proto by měl být formát ESCAPE zachován po celou dobu trvání upgradu, jinak se můžete setkat s chybou:

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

Chcete-li opravit, na PG 8.4.x nejsou vyžadovány žádné změny, ale na PG 9.3.5 bytea_output parametr by měl být nastaven z HEX na ESCAPE, jak je znázorněno. Můžeme to nastavit na úrovni clusteru ($PGDATA/postgresql.conf) nebo na úrovni uživatele (ALTER TABLE…SET), já jsem preferoval změny na úrovni uživatele.

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

Pokračujme kroky upgradu. Níže jsou uvedeny podrobnosti o mých dvou verzích serveru použité v této ukázce, pokud se pokoušíte, změňte je podle nastavení serveru:

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

Pro snadné pochopení a snadnou implementaci jsem demo rozdělil do tří sekcí

1. Kompilace pro binární soubory Slony-I proti verzím PostgreSQL
2. Vytváření replikačních skriptů a spouštění
3. Testování Switchover/Switchback.

1. Kompilace pro binární soubory Slony-I proti verzi PostgreSQL
Zde si stáhněte zdroje Slony-I a proveďte instalaci zdroje proti binárním souborům PostgreSQL na uzlech Origin a Subscriber.

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. Vytváření a spouštění replikačních skriptů
K nastavení replikace potřebujeme vytvořit několik skriptů, které se postarají o replikaci včetně přepnutí/přepnutí.

1. initialize.slonik – Tento skript obsahuje informace o připojení uzlů Origin/Subscriber.
2. create_set.slonik – Tento skript obsahuje všechny tabulky Origin PK, které se replikují do Subscriber Node.
3. subscribe_set.slonik – Tento skript zahájí replikaci dat sad do Subscriber Node.
4. switchover.slonik – Tento skript pomáhá přesunout ovládání z Origin na Subscriber.
5. switchback.slonik – Tento skript pomáhá se záložním řízením z Subscriber to Origin.

Nakonec další dva spouštěcí skripty “start_OriginNode.sh” a „start_SubscriberNode.sh“ který spustí slon procesy podle binárních souborů zkompilovaných na Origin/Subscriber Node.

Zde si stáhněte všechny skripty.

Zde jsou ukázková data na Origin Node (8.4.22) ve Foo Table se sloupcem datového typu bajt, která je pomocí vytvořených skriptů replikujeme do Subscriber Node (9.3.5).

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

Zavolejme skripty jeden po druhém, abychom nastavili replikaci. PAMATUJTE SI VŠECHNY SKRIPTY SLONIK BY MĚLY BÝT PROVÁDĚNY POUZE NA ORIGIN UZLU, S VÝJIMKOU „start_OriginNode.sh“ A „start_SubscriberNode.sh“, KTERÉ BY MĚLY BÝT PROVÁDĚNY INDIVIDUÁLNĚ.

-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

Po úspěšném provedení výše uvedeného skriptu si můžete všimnout, že se data na Origin (masterdb) replikovala do Subscriber (slavedb). Rovněž nepovoluje žádnou operaci DML na uzlu předplatitele:

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

Skvělé… Data jsme přesunuli do novější verze PostgreSQL 9.3.5. V této fázi, pokud máte pocit, že se všechna data replikovala do Subscriber Node, můžete provést přepnutí.

3. Testování přepnutí/přepnutí.

Pojďme se skriptem přepnout na nejnovější verzi a zkusit vložit data do uzlů 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

Perfektní… To je to, co hledáme, nyní slavedb (předplatitelský uzel) běží na verzi PG 9.3.5 přijímající data a masterdb (původní uzel) přijímá data slavedb. Také jeho odmítnutí DML prováděné na masterdb.

Protokoly Slony-I zobrazují pohyby ID uzlu původu/předplatitele v době přechodu:

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

Pokud v této fázi narazíte na nějaké problémy, můžete přejít zpět na starší verzi. Po přepnutí můžete pokračovat se starší verzí, dokud nebude vaše aplikace nebo jiné problémy vyřešeny. Toto je perfektní plán návratu bez ztráty času v případě problémů po přechodu..

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

Velmi hezké…!!! Není to přesný rollback s minimálními prostoji? Ano, je to perfektní přepínání mezi uzly, aniž byste zmeškali transakci.

Protokoly zobrazující přepnutí z předplatitelského do původního uzlu:

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

Do této doby jste si možná všimli, že žádná z transakcí se během přepínání mezi verzemi PostgreSQL neztratí. Jediným výpadkem může být spuštění/zastavení vaší aplikace pro připojení k uzlům Origin a Subscriber, ale zatímco uzly Origin/Subscriber nejsou nikdy odstraněny, jsou pouze v provozu.

Pamatujte, že zde uvedená metoda není užitečná pouze pro upgrady, ale je to stejná metoda v Slony-I pro pohyb mezi uzly.

Děkujeme vám za vaši trpělivost :). Doufám, že vám tento příspěvek pomůže upgradovat PostgreSQL s minimálními prostoji pomocí Slony-I včetně správného plánu vrácení.