Replikasi PostgreSQL 9.0

PostgreSQL 9.0.x mungkin merupakan satu lompatan yang mampu menyejukkan 'kekeringan' para penggemar PostgreSQL akan satu fitur yang paling sangat dinantikan. Replikasi. Semenjak saya mulai keranjingan PostgreSQL pada tahun 2006, hal yang paling sering mengganggu adalah masalah replikasi data. Tak usahlah sampai ke active-active, active-passive pun terasa amat sulit mendapatkan pemecahannya. Memang teramat banyak pilihan replikasi untuk postgres, namun, ataghfirullah, reliability nya sangat-sangat rentan. Terutama bila dipegang oleh orang yang tidak terlalu menguasai. Sebut saja pgCluster, pgPool, sequoia, atau Slony. Hampir semua nyaris bikin frustasi, kecuali Slony. Hanya proses inisiasi Slony teramat-amat sangat ribet dan menghasilkan rieut yang sangat. Nah ribet, rieut inilah kemudian yang dicoba untuk dipangkas oleh Replikasi PostgreSQL 9.0.

Streaming Replication
Streaming Replication? Kenapa streaming? PostgresSQl 9.0.x memanfaatkan XLOG (pg_xlog) untuk melakukan replikasi. Rekaman XLOG ini secara terus-menerus perbagian dikirimkan ke standby site dengan mengimplementasikan record-based log-shipping. Ini akan menjamin semakin kecilnya data-loss. Isi dari XLOG akan dituliskan di standby dan secara tepat akan sama dengan primary. Dengan menggunakan streaming replication ini kita bisa membuat suatu konfigurasi redundant untuk standby site, dimana dengan satu primary kita bisa setup lebih dari satu standby. Jumlah maksimum dari standby bisa ditentukan melalui variable GUC. Oleh karena standby site akan selalu mereplay seluruh log yang dikirim oleh primary maka bisa dharapkan setiap perubahan di sisi primary akan segera direplay di sisi standby atau posisi standby akan selalu (hampir) sama dengan primary, tentunya oleh karena adanya antrian dan pengiriman melalui jaringan akan menimbulkan latensi.

Installasi PostgreSQL 9.0
Untuk mendapatkan keuntungan replikasi PostgreSQL 9.0.x mau gak mau kita harus menginstall PostgreSQL 9.0. Source PostgreSQL 9.0.x bisa didapat di sini. Download source,extract, configure, make all, dan make install dengan perintah.

postgres@firsthost:~/postgresql-9.0.1$cd $HOME
postgres@firsthost:~$echo "export PATH=$HOME/pgsql/bin:$PATH" >>.profile [atau file profile lainnya]

Logout dan Login lagi dan jalankan initdb untuk mengisiasi database.

postgres@firsthost:~$nano ~/data1/postgresql.conf

cari bagian listen_addresses, edit dan sesuaikan dengan kondisi. Untuk kasus kita kali ini listen_address akan kita isi dengan '*', dan port = 5432

#untuk mengaktifkan konfigurasi "hot standby" dan meng-enable-kan read-only query pada standby
#server maka parameter "wal_level" kita beri nilai "hot_standby".

wal_level = hot_standby

#kemudian untuk memberikan nilai concurrent connection dari standby server kita beri nilai integer
#sejumlah standby server yang akan terkoneksi ke primary. dalam konfigurasi ini karena hanya
#mempunyai satu standby server maka kita masukan integer "1"

max_wal_sender = 1

#Untuk mencegah primary server membuang WAL segment yang dibutuhkan untuk standby server
#maka nilai minimum segment yang dipegang dalam direktori "pg_xlog" harus ditentukan
#pada parameter "wal_keep_segments". Dalam hal ini setidaknya nilai dari wal_keep_segments
#lebih besar dari segment yang dibentuk antara online backup dan permulaan (startup) dari
#streaming replication. Bila anda meng-enable-kan WAL archiving pada suatu direktory yang bisa
#diakses dari standby site, parameter ini bisa diabaikan.

wal_keep_segments = 32

#Enable-kan WAL archiving pada primary pada suatu direktory yang bisa diakses dari standby.
#Jika wal_keep_segments cukup besar untuk menjaga WAL segment yang dibutuhkan oleh standby server,
#maka parameter ini bisa diabaikan

archive_mode = on
archive_command = 'cp -i %p $HOME/archive/%f'

Catatan :
Perhatikan bagian yang dicetak tebal. Kita harus menyiapkan direktori $HOME/archive untuk menghindari kesalahan.

Setelah kita lakukan editing terhadap file postgresql.conf, kemudian kita jalankan server dengan perintah:

postgres@firsthost:~$psql -c "SELECT pg_start_backup('label',true)"
postgres@firsthost:~$rsync -a $HOME/data1/ secondhost:$HOME/data1/ --exclude postmaster.pid
postgres@firsthost:~$psql -c "SELECT pg_stop_backup()"

Note:
Perhatikan bagian yang dicetak tebal. Untuk menjalankan perintah ini, $HOME directory antara primary (firsthost) dan standby (secondhost) harus menunjuk ke direktori yang sama. Atau bisa diganti dengan menggunakan absolute path.

Selanjutnya kita pindah ke secondhost (standby). Edit file postgresql.conf, cari parameter "hot_standby" dan berikan nilai "on" padanya.

postgres@secondhost:~$nano ~/data1/recovery.conf
--
#Karena server akan berjalan sebagai standby maka tentukan standby_mode = on

standby_mode = on

#Tentukan parameter koneksi ke primary server

primary_conninfo = 'host=firsthost port=5432 user=postgres'

#tentukan suatu trigger file yang keberadaannya akan menyebabkan streaming replication akan
#terhenti (contohnya pada failover).

trigger_file = '$HOME/trigger'

#Tentukan perintah untuk me-load segment-segment archives dari WAL archive. Bila nilai dari
#wal_keep_segments cukup besar untuk menampung segment WAL yang dibutuhkan oleh standby server,
#parameter ini mungkin tidak dibutuhkan. Namun workload yang cukup tinggi bisa menyebabkan
#segment akan diresaikel sebelum standby tersinkronisasi secara penuh dan menyebabkan kita harus
#mulai dari basec backup.

restore_command = 'cp $HOME/archives/%f %p'

Catatan
Perhatikan bahwa kita harus membuatkan direktori $HOME/trigger. Sebaiknya direktori kita buat pada dua sisi baik di primary maupun standby

Terakhir, untuk memberikan informasi koneksi antara primary dan standby, maka kita harus merubah file pg_hba.conf baik di primary maupun di standby. Kenapa kedua-duanya? Karena pada beberapa kondisi mungkin perlu dilakukan switch dari primary menjadi standby atau sebaliknya.

Pada primary:
Tambahkan baris ini:

#bila IP second host adalah 10.10.10.2 maka:

host replication postgres 10.10.10.2/32 trust

Untuk memastikan kita restart primary dan jalankan standby. Pada log di standby harus bisa dilihat kepastian terkoneksi ke primary dengan munculnya message berikut:

Pada log standby:

..
..
LOG: replication connection authorized: user=postgres host=10.10.10.3 port=XXXX

Bila kedua server sudah memberikan message seperti di atas maka replikasi sudah bisa dijalankan.

Test Replikasi
Secara gampangnya untuk meyakini bahwa replikasi telah terinstall kita bisa menjalankan perintah berikut di sisi primary. Ingat hanya primary yang bisa melakukan transaksi!!!!!

postgres@fisthost:~$psql -c "select datname from pg_stat_database where datname='testdb'" -h firsthost
datname
---------
testdb
(1 row)

Test di secondhost seharusnya akan memberikan hasil yang sama.

postgres@fisthost:~$psql -c "select datname from pg_stat_database where datname='testdb'" -h secondhost

datname
---------
testdb
(1 row)

Test create table dan insert data

postgres@fisthost:~$psql -c "create testtable(no integer, nama character varying(76))" -h firsthost
postgres@fisthost:~$psql -c "insert into testtable(no, nama) values (1,'nama saya')" -h firsthost
postgres@fisthost:~$psql -c "insert into testtable(no, nama) values (2,'nama kamu')" -h firsthost

Test hasilnya di primary

postgres@fisthost:~$psql -c "select * from testtable" -h firsthost
no | nama
----+-----------
1 | nama saya
2 | nama kamu
(2 rows)

Lakukan yang sama terhadap secondhost dan seharusnya bisa memberikan hasil yang sama.

postgres@fisthost:~$psql -c "select * from testtable" -h secondhost no | nama
----+-----------
1 | nama saya
2 | nama kamu
(2 rows)

Jika telah benar telah memberikan hasil yang sama maka bisa dikatakan bahwa installasi replikasi kita telah berhasil.

Tambahan
Dari ujicoba, untuk merubah standby menjadi primary maka langkah-langkah yang harus dilakukan:

1. Rubah parameter hot_standby menjadi off pada sisi standby sehingga standy akan bertindak menjadi primary dan menjadi on pada primary sehingga primary akan mejadi secondary.
2. Pindahkan recovery.conf dari secondary ke primary, atau copy ke primary sementara di secondary direname menjadi bukan recovery.conf

Beberapa Catatan Penting

1. Untuk melakukan materialisasi pada sisi standby tidak bisa dilakukan dengan menggunakan pg_dump/pg_restore harus dengan menggunakan base backup seperti dilakukan di atas.
2. Pemindahan material dari primary ke standby tidak harus dengan menggunakan rsync.
3. Penggunaan rsync pada beberapa kondisi harus menggunakan akses passwordless.