Превключване/Обратно превключване в Slony-I при надграждане на основните версии на PostgreSQL 8.4.x/9.3.x

Всяка нова версия на PostgreSQL идва с пълен набор от вълнуващи функции. За да се възползвате от новите функции, сървърът на базата данни трябва да бъде надстроен. Изборът на традиционни пътища за надграждане като pg_dump/pg_restore или pg_upgrade изисква значително време на престой на приложението. Днес, ако търсите минимален път за надграждане на престой сред основните версии на PostgreSQL с перфектен план за връщане назад, тогава това ще бъде постигнато чрез асинхронна Slony-I репликация. Тъй като Slony-I (знайте повече за него тук) има способността да се репликира между различни версии на PostgreSQL, ОС и битови архитектури лесно, така че надстройките са изпълними, без да се изисква значителен престой. В допълнение, той има последователна функционалност за превключване и обратно в своя дизайн.

IMO, докато правим големи надстройки на версията, трябва да има подходящ резервен план, защото само в случай, че приложението се окаже, че има грешки или не работи добре с надстроена версия, тогава трябва да можем да се върнем към по-стара версия незабавно. Slony-I предоставя такава функционалност като превключване. Тази публикация демонстрира минимално надграждане при престой, включително стъпки за превключване/обратно превключване.

Преди да преминете към демонстрация, трябва да се отбележи една важна стъпка, по-рано до версията PG 9.0.x колоните bytea тип данни използват за съхраняване на данни във формат ESCAPE и по-нова версия в HEX формат. Докато извършвате превключване (по-нова версия към по-стара версия), този вид разлики във формата на байт не се поддържат от Slony-I, следователно ESCAPE форматът трябва да се поддържа през времетраенето на надстройката, в противен случай може да срещнете грешка:

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

За да коригирате, не са необходими промени на PG 8.4.x, но на PG 9.3.5 параметърът bytea_output трябва да бъде зададен от HEX на ESCAPE, както е показано. Можем да го настроим на ниво клъстер ($PGDATA/postgresql.conf) или потребителско ниво (ALTER TABLE…SET), аз предпочетох да отида с промени на ниво потребител.

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

Нека продължим със стъпките за надграждане. По-долу са данните за моите две версии на сървъра, използвани в тази демонстрация, променете го съответно според настройката на вашия сървър, ако се опитвате:

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

За лесно разбиране и лесно изпълнение разделих демонстрацията на три секции

1. Компилиране за двоични файлове Slony-I срещу PostgreSQL версии
2. Създаване на репликационни скриптове и изпълнение
3. Тестване на превключване/обратно превключване.

1. Компилиране за двоични файлове Slony-I срещу версия на PostgreSQL
Изтеглете източниците на Slony-I от тук и извършете инсталация на източника срещу двоични файлове на PostgreSQL на възли Origin и 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. Създаване на репликационни скриптове и изпълнение
За да настроим репликацията, трябва да създадем няколко скрипта, които се грижат за репликацията, включително превключване/обратно превключване.

1. initialize.slonik – Този скрипт съдържа информация за връзката на възлите Origin/Subscriber.
2. create_set.slonik – Този скрипт съдържа всички Origin PK Tables, които се репликират на Subscriber Node.
3. subscribe_set.slonik – Този скрипт започва да репликира данни от набори към абонатния възел.
4. switchover.slonik – Този скрипт помага да се премести контрола от Origin към Subscriber.
5. switchback.slonik – Този скрипт помага да се управлява обратното управление от Subscriber към Origin.

И накрая, още два скрипта за стартиране “start_OriginNode.sh” и “start_SubscriberNode.sh” който стартира slon процеси в съответствие с двоичните файлове, компилирани на Origin/Subscriber Nodes.

Изтеглете всички скриптове от тук.

Ето примерните данни за Origin Node (8.4.22) във Foo Table с колона от тип данни bytea, които ще ги репликираме в Subscriber Node (9.3.5) с помощта на създадени скриптове.

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

Нека извикаме скриптовете един по един, за да настроим репликацията. ЗАПОМНЕТЕ ВСИЧКИ SLONIK SCRIPT ТРЯБВА ДА СЕ ИЗПЪЛНЯВАТ САМО НА ORIGIN NODE, ОСВЕН „start_OriginNode.sh“ И „start_SubscriberNode.sh“, КОИТО ТРЯБВА ДА СЕ ИЗПЪЛНЯТ ОТДЕЛНО.

-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

След успешно изпълнение на горния скрипт, можете да забележите, че данните в Origin(masterdb) са репликирани на Subscriber(slavedb). Също така не позволява никакви DML операции на абонатния възел:

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

Страхотно… Преместихме данните в по-нова версия на PostgreSQL 9.3.5. На този етап, ако смятате, че всички данни са репликирани в абонатния възел, тогава можете да извършите превключване.

3. Тестване на превключване/обратно превключване.

Нека да преминем към най-новата версия със скрипта и да опитаме да вмъкнем данни в абонатни/изходни възли.

-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

Перфектно... Това е, което търсим, сега slavedb (абонатен възел), работещ с PG 9.3.5 версия, приемаща данни и masterdb (изходен възел) получаващ slavedb данните. Също така неговото отхвърляне на DML, изпълнено на masterdb.

Slony-I Logs показва движенията на произхода/абонатния възел по време на превключване:

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

Ако срещнете някакви проблеми на този етап, можете да се върнете към по-стара версия. След обратното превключване можете да продължите с по-стара версия, докато приложението ви или други проблеми не бъдат отстранени. Това е идеалният план за връщане назад, без да губите много време в случай на проблеми след превключване...

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

Много добре…!!! Това не е ли точното връщане назад с минимално време на престой? Да, това е перфектно превключване между възли, без да пропускате транзакция.

Регистри, показващи превключването от абонат към изходен възел:

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

По това време може би сте забелязали, че нито една от транзакциите не се губи по време на операцията по превключване между версиите на PostgreSQL. Единственото време на престой може да бъде вашето приложение за стартиране/спиране за свързване с възли Origin и Subscriber, но докато възлите Origin/Subscriber никога не се свалят, те просто се стартират и работят.

Не забравяйте, че методът, показан тук, не е полезен само за надстройки, но е същият метод в Slony-I за придвижване между възли.

Благодаря ви за търпението :). Надяваме се, че тази публикация ви помогне да надстроите PostgreSQL с минимално време на престой, като използвате Slony-I, включително подходящ план за връщане назад.