Switchover/Switchback di Slony-I saat memutakhirkan PostgreSQL versi utama 8.4.x/9.3.x

Setiap rilis baru PostgreSQL hadir dengan berbagai fitur menarik. Untuk memanfaatkan fitur baru, server database harus ditingkatkan. Memilih jalur pemutakhiran tradisional seperti pg_dump/pg_restore atau pg_upgrade memerlukan waktu henti aplikasi yang signifikan. Saat ini, jika Anda mencari jalur pemutakhiran waktu henti minimum di antara versi PostgreSQL utama dengan rencana rollback sempurna, maka itu akan diselesaikan dengan replikasi Slony-I asinkron. Karena Slony-I (tahu lebih banyak tentangnya di sini) memiliki kemampuan untuk mereplikasi antara versi PostgreSQL, OS, dan arsitektur bit yang berbeda dengan mudah, jadi pemutakhiran dapat dilakukan tanpa memerlukan waktu henti yang signifikan. Selain itu, ia memiliki fungsionalitas switchover dan switchback yang konsisten dalam desainnya.

IMO, saat melakukan peningkatan versi utama harus ada rencana cadangan yang tepat karena untuk berjaga-jaga jika aplikasi menjadi buggy atau gagal berfungsi dengan baik pada versi yang ditingkatkan, maka kita harus dapat segera mengembalikan ke versi yang lebih lama. Slony-I menyediakan fungsionalitas seperti itu dengan cara switchback. Posting ini menunjukkan, peningkatan waktu henti minimum termasuk langkah peralihan/pengalihan.

Sebelum menuju ke demo, satu langkah penting yang perlu diperhatikan, sebelumnya untuk PG 9.0.x versi bytea datatype kolom digunakan untuk menyimpan data dalam format ESCAPE dan versi selanjutnya dalam format HEX. Saat melakukan switchback (versi yang lebih baru ke versi yang lebih lama), perbedaan format byte semacam ini tidak didukung oleh Slony-I sehingga format ESCAPE harus dipertahankan selama durasi pemutakhiran, jika tidak, Anda mungkin mengalami kesalahan:

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

Untuk memperbaikinya, tidak ada perubahan yang diperlukan pada PG 8.4.x tetapi pada PG 9.3.5 parameter bytea_output harus diatur dari HEX ke ESCAPE seperti yang ditunjukkan. Kita dapat mengaturnya di tingkat cluster ($PGDATA/postgresql.conf) atau tingkat pengguna (ALTER TABLE…SET), saya lebih suka menggunakan perubahan tingkat pengguna.

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

Mari kita lanjutkan dengan langkah-langkah peningkatan. Di bawah ini adalah dua versi detail server saya yang digunakan dalam demo ini, ubah sesuai dengan pengaturan server Anda jika Anda mencoba:

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

Untuk pemahaman yang sederhana dan implementasi yang mudah, saya telah membagi demo menjadi tiga bagian

1. Kompilasi untuk binari Slony-I terhadap versi PostgreSQL
2. Membuat Script Replikasi dan mengeksekusi
3. Menguji Peralihan/Pengalihan.

1. Kompilasi untuk binari Slony-I terhadap versi PostgreSQL
Unduh sumber Slony-I dari sini, dan lakukan instalasi sumber terhadap binari PostgreSQL di node Asal dan Pelanggan.

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. Membuat Script Replikasi dan mengeksekusi
Untuk mengatur replikasi, kita perlu membuat beberapa skrip yang menangani replikasi termasuk switchover/switchback.

1. initialize.slonik – Script ini menyimpan informasi koneksi node Origin/Subscriber.
2. create_set.slonik – Skrip ini menampung semua Tabel PK Asal yang mereplikasi ke Node Pelanggan.
3. subscribe_set.slonik – Script ini mulai mereplikasi set data ke Subscriber Node.
4. switchover.slonik – Script ini membantu untuk memindahkan kontrol dari Origin ke Subscriber.
5. switchback.slonik – Skrip ini membantu mengontrol mundur dari Pelanggan ke Asal.

Akhirnya, dua skrip startup lagi “start_OriginNode.sh” dan “start_SubscriberNode.sh” yang memulai proses slon sesuai dengan binari yang dikompilasi di Origin/Subscriber Nodes.

Unduh semua skrip dari sini.

Berikut contoh data Origin Node(8.4.22) di Foo Table dengan kolom tipe data bytea, yang akan kita replika ke Subscriber Node(9.3.5) dengan bantuan script yang dibuat.

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

Mari kita panggil skrip satu per satu untuk mengatur replikasi. INGAT SEMUA SCRIPT SLONIK HARUS DILAKUKAN PADA ORIGIN NODE SAJA, KECUALI “start_OriginNode.sh” DAN “start_SubscriberNode.sh” YANG HARUS DILAKUKAN SECARA INDIVIDU.

-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

Setelah eksekusi skrip di atas berhasil, Anda dapat melihat data di Origin(masterdb) telah direplikasi ke Subscriber(slavedb). Juga tidak mengizinkan operasi DML pada node Pelanggan:

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

Keren… Kami telah memindahkan data ke versi PostgreSQL 9.3.5 yang lebih baru. Pada tahap ini jika Anda merasa semua data telah direplikasi ke Subscriber Node, maka Anda dapat melakukan switchover.

3. Menguji Peralihan/Pengalihan.

Mari beralih ke versi terbaru dengan skrip dan coba masukkan data di Node Pelanggan/Asal.

-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

Sempurna… Inilah yang kita cari, sekarang slavedb(Subscriber Node) menjalankan versi PG 9.3.5 menerima data dan masterdb(Origin Node) menerima data slavedb. Juga menolak DML yang dieksekusi di masterdb.

Slony-I Logs menunjukkan pergerakan id node asal/pelanggan pada saat Switchover:

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

Jika Anda mengalami masalah pada tahap ini, Anda dapat beralih kembali ke versi yang lebih lama. Setelah beralih kembali, Anda dapat melanjutkan dengan versi yang lebih lama hingga aplikasi Anda atau masalah lainnya diperbaiki. Ini adalah rencana pengembalian yang sempurna tanpa membuang banyak waktu jika terjadi masalah setelah peralihan..

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

Bagus sekali…!!! Apakah ini bukan kemunduran yang tepat dengan waktu henti minimum? Ya, ini adalah peralihan sempurna antar node tanpa melewatkan transaksi.

Log yang menunjukkan peralihan dari Subscriber ke 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

Pada saat ini Anda mungkin telah memperhatikan, tidak ada transaksi yang hilang selama operasi peralihan antara versi PostgreSQL. Hanya waktu henti yang mungkin menjadi aplikasi Anda untuk memulai/berhenti untuk menghubungkan ke node Asal dan Pelanggan, tetapi sedangkan node Asal/Pelanggan tidak pernah diturunkan, mereka hanya aktif dan berjalan.

Ingat, metode yang ditampilkan di sini tidak hanya berguna untuk peningkatan tetapi metode yang sama di Slony-I untuk berpindah antar Node.

Terima kasih atas kesabaran Anda :). Semoga postingan ini membantu Anda meningkatkan PostgreSQL dengan waktu henti minimum menggunakan Slony-I termasuk rencana rollback yang tepat.