Save Point Oh Save Point (bukan check point)

Kemarin, sore hari, dah mau pulang, gak jadi. Ada sedikit tantangan yang muncul dari masalah salah seorang kawan di kantor. Masalahnya adalah; beliau punya stored procedure yang dijalankan pada Sybase Adaptive Server Enterprise (Sybase ASE), tetapi ada 'ketidak-konsisten-an' ketika Stored Procedure itu dijalankan.  Nah, mungkin, karena dianggap sebagai salah seorang yang tahu mengenai seluk beluk Sybase ASE, atau sekedar cari temen diskusi, temen ini ngajak diskusi sambil membuka source dari stored procedure beliau punya. Phh...., pening juga aku melihat source script yang bukan tumpahan pemikiranku.

Sambil membuka-buka source beliau mulai bercerita bahwa stored procedure nya yang telah beliau set chained mode nya menjadi anymode (bisa chained, bisa juga unchained) dengan harapan sifat procedure dalam menangani variable bisa lebih flexible ternyata masih menyisakan misteri yang agak (ya memang sekedar agak, karena aku tahu kapasitas beliau) sulit untuk dipecahkan.
Jadi begini, beliau punya dua stored procedure.  Satu stored procedure dipanggil oleh stored procedure yang lainnya. Gambarannya bisa dilihat pada frame berikut:

1. declare proc...
2. .
3. .
4. begin
5.   set chained on
6. end
7. .
8. .
9. .
10. begin transaction alltran
11. begin
12.   call my_sp (@status)-->sp ini ada transaksi insert, tidak mengandug commit di dalamnya
13.   if @status = -1
14.    begin
15.     rollback
16.     raise error
17.     return(1) -->return error
18.    end
19. end
20. 
    
21. insert ...
22. if @@rowcount > 0 and status != -1 -->commit di sini.
23. begin
24.   commit tran
25.   return(0)
26. end
27. else
28. begin
29.   rollback
30.   return(1)
31. end

Dan beliau cerita juga bahwa beberapa test yang beliau lakukan terhadap stored procedurenya, memberikan pesan kesalahan bahwa seakan dalam stored procedure beliau ada rollback/commit yang tidak didahului dengan begin. Padahal, menurut beliau dan sesuai penglihatanku juga, semua sudah setangkup. Gak ada yang nyelonong sendirian.  Hasil test memberikan pesan bahwa commit/rollback tidak didahului oleh save point. Dan lebih jauh lagi, ternyata, setelah menjalankan/call my_sp dan secara keseluruhan stored_procedure seharusnya rollback, ternyata insert yang dijalankan oleh my_sp tetap commit.

Save point, aku yang lebih banyak berkutat dengan masalah replikasi, awalnya, nangkepnya save point itu sama dengan check point (setelah masalah terselesaikan, dalam hati, kemudian, aku tertawa ngikik, karena sok tahu menyamakan save point sama check point).  Ya aku bilang, apa hubungannya dengan stored procedure.  Tambah lagi, example save point yang didapat juga bunyinya 'save transaction precentagesave'.  Vvvh.., masa harus ngukur persentasi proses yang mau disimpan di log sih?

Setelah puter otak kanan kiri dan ngomong ini ngomong itu dalam diskusi, akhirnya intuisiku berjalan.  Save point, hmm... pastinya ini bukan masalah replikasi.  Tetapi masalah session transaksi. Hmmm terus aku usul bagaimana kalau ada perubahan begini:

1. declare proc...
2. .
3. .
4. begin
5.   set chained on
6. end
7. .
8. .
9. .
10. begin transaction alltran
11. begin
12. save transaction  currTran
13.   call my_sp (@status)-->sp ini ada transaksi insert, tidak mengandug commit di dalamnya
14.   if @status = -1
15.    begin
16.     rollback currTran
17.     raise error
18.     return(1) -->return error
19.    end
20. end
21. 
    
22. insert ...
23. if @@rowcount > 0 and status != -1 ->commit di sini.
24. begin
25.   commit tran
26.   release currTran
27.   return(0)
28. end
29. else
30. begin
31.   rollback tran
32.   release currTran
33.   return(1)
34. end

Setelah ditambahkan beberapa baris seperti di atas, akhirnya masalah terpecahkan.  Eksekusi nested stored procedure my_sp seperti di dalam contoh sudah bisa terkontrol sepenuhnya dengan menerapkan save point yang bukan check point.  Kesimpulannya, karena tidak menerapkan save point maka nested procedure yang secara anatominya memakai satu blok tersendiri, maka, bila aplikasi menerapkan autocommit dalam mengeksekusi stored procedure induknya, nested stored procedure secara otonom akan menginsert dan commit tanpa mengabaikan rule yang didisain dalam mengeksekusi stored procedure tersebut.  Oleh karena proses telah di commit, maka proses rollback akan memberikan pesan kesalahan.  Untuk itulah maka diperlukan save point yang akan memegang status transaksi.
Itu aja. He he he...

S.M.A.R.T policy dan procedure

Jika kita terbiasa dalam pembentukan kebijakan terkait pengamanan informasi itu harus mengikuti pola S.M.A.R.T yang boleh di panjangin jadi Specifics untuk S, Measureable untuk M, Achievable untuk A, Realistic untuk R, dan Time Based untuk T.

Namun sebelum tahu banyak tentang SMART ada baiknya mengenal 5Ws.

1. What, apa, prosedurnya sendiri itu prosedur apa?
2. Who, siapa, siapa yang menjalankan prosedur?
3. When, kapan, kapan suatu prosedure harus dijalankan?
4. Where, dimana, dimana suatu prosedure harus dijalankan?
5. Why, mengapa, mengapa suatu prosedure harus dijalankan?

Ya, 5Ws yang selalu diawali dengan 'Wh' sama dengan 5Ws dari dunia jurnalistik.  Lalu, kenapa kita menggunakan ini untuk membangun suatu prosedure? Karena dengan mejawab pertanyaan-pertanyaan di atas maka kita akan bisa mendapat gambaran secara utuh tentang suatu prosedur, baik tentang prosedur apa yang akan dijalankan, siapa yang harus menjalankannya, kapan harus dijalankan, dimana harus dijalankan, dan yang pasti adalah mengapa suatu prosedur harus dijalankan. Yang pasti dalam menilai SMART atau membentuk kebijakan secara SMART maka kira harus menggunakan kaidah jurnalistik di atas.

Kembali ke SMART.
S, Specifics. Sespesifik apakah kebijakan tentang pengamanan informasi yang akan kita buat? Pada dasarnya suatu kebijakan pengamanan  bisa dibuat sangat spesifik atau sangat umum bergantung pada kemampuan organisasi itu mengadaptasi perubahan dan tentunya bergantung pula pada kebijakan dari organisasi itu sendiri untuk melakukan review terhadap seluruh kebijakan yang berlaku di dalam organisasi itu sendiri.
Pada suatu organisasi, oleh karena sifatnya yang sangat fleksible untuk mengantisipasi ancaman-ancaman, sangat mungkin untuk membuat suatu policy sedetail mungkin. Dalam organisasi seperti ini, mungkin perubahan policy hanya membutuhkan waktu dalam hitungan hari.  Bisa 3 hari, bisa 4 hari atau mungkin kurang dari itu.  Namun, pada organisasi lain, yang karena ukurannya dan jenjang birokrasi, atau karena kebutuhan akan kepastian kebijakan; perubahan suatu kebijakan bisa membutuhkan waktu lebih lama dan siklus perubahannya bisa mencapai 1 tahun ata bergantung pada kebijakan dari oragnisasi itu sendiri. Pada organisasi ini, mungkin kebijakan pengamanan informasi  tidak dibuat dengan sangat detail karena luasnya cakupan yang memang tidak bisa dihindari oleh karena sifat dan ukuran organisasi. Namun, kenyataan bahwa tidak pernah ada satu jawaban untuk menjawab semua pertanyaan, maka penting bagi organisasi untuk melakukan review untuk melakukan perubahan-perubahan yang dirasa perlu.

M, Measurable. Pernyataan-pernyataan di dalam membentuk suatu kebijakan pengamanan informasi harus bisa terukur dalam arti jelas dan tidak bersayap. Sebagai contoh point-point pengamanan informasi mengenai password berikut

• Tidak diperkenankan menggunakan singkatan-singkatan yang umum sebagai bagian dari password
• Tidak diperkenankan menggunakan kata-kata umum atau kebalikan dari kata-kata umum sebagai bagian dari password
• Tidak diperkenankan menggunakan nama orang atau nama tempat sebagai bagian dari password
• Tidak diperkenankan menggunakan seluruh atau sebagian dari login name (user name) sebagai bagian dari password
• Tidak diperkenankan menggunakan angka-angka yang mudah ditebak seperti tanggal lahir, nomor telepon, nomor NPWP dan nomor-nomor sejenis lainnya sebagai bagian dari password.

Perhatikan penggunaan kata-kata "tidak diperkenankan".  Penggunaan kata-kata ini bisa masuk dalam katagori measurable.  Di sini, user atau object dari kebijakan bisa menerima dengan jelas maksud dari kebijakan.

Bandingkan dengan contoh berikut:

• Pada kondisi dimana password dibutuhkan, setiap user harus mempunyai passwordnya sendiri yang hanya diketahui oleh yang bersangkutan.  Masing-masing user bertanggung-jawab terhadap kerahasiaan dari passwordnya masing-masing dan untuk setiap penyalahgunaan passwordnya oleh pihak lain.

Pada contoh kedua ini, kebijakan tidak menyebutkan dengan jelas tentang bagaimana password yang rahasia dan tidak mudah ditebak tetapi menyerahkan tanggung-jawab kerahasiannya kepada user.

A, Achievable. Suatu kebijakan seharusnya bisa dijalankan. Sebagai contoh bisa dilihat pada frasa kebijakan berikut;

"Apabila suatu data dan sistem baru telah terpasang, maka personel dari application security bisa melakukan evaluasi dan menentukan metode, proses, kelengkapan, dan prosedur untuk meminimalkan resiko."

Frasa di atas kelihatan sangat ideal, sangat mudah bagi seorang Application Security untuk menuliskan frasa seperti itu. Akan tetapi, pada kondisi yang sebenarnya, akan sangat sulit bagi seorang Application Security untuk menentukan point-point kebijakan yang akan dituliskan agar memenuhi persayaratan spesifik dan measurable.  Bila seorang Application Security bisa dengan mudah menuliskan point kebijakannya, sangat boleh jadi itu akan menjadi tidak achievable.  Contoh di atas adalah point kebijakan yang tidak spesifik, measurable, dan acievable. Contoh di atas terlalu mengambang dan tidak spesifik, tidak secara jelas menyebutkan tindakan yang harus dilakukan oleh seorang Application Security dan tentunya tidak akan achievable karena tolok ukurnya yang tidak jelas.

R, Realistic.  Suatu kebijakan seharusnya mempunyai pandangan yang realistik terhadap setiap point yang diuraikan. Contoh berikut adalah contoh point yang kurang realistik.

"Seluruh karyawan yang memperoleh sambungan internet hanya boleh menggunakannya hanya untuk kepentingan bisnis perusahaan."

Frasa di atas kelihatannya memang indah, namun kurang realistik. Kenapa tidak realistik? Karena user akan berpikir, bagaimana dengan karyawan yang bepergian dengan laptop perusahaan? Bisa jadi mereka mempunyai account facebook, dan menggunakan laptop perusahaan plus sambungan internetnya untuk ber-facebook-ria.

T, Time Based.  Harus jelas waktunya, dan karena harus memperhatikan faktor achievable maka untuk mendukung kebijakan terkait Time Based harus juga dilengkapi dengan prosedur. Perhatikan contoh berikut:

"Terminasi Account: Setiap supervisor dari karyawan yang mengundurkan diri harus melaporkan pengunduran diri karyawan bersangkutan kepada Security Admin sebelum atau pada hari pengunduran diri karyawan yang bersangkutan, sehingga semua account milik karyawan bisa di-inaktifkan dengan baik"

Paragraf kebijakan di atas bagus namun frasa "sebelum atau pada hari" atau "secepatnya" hanya akan bisa berjalan bila dilengkapi dengan prosedure yang bisa menjelaskan dengan pasti mengenai apa yang harus dilakukan oleh seorang supervisor terkait pengunduran diri staff-nya.

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.

Berpikir Ulang Tentang Java

Mungkin sedikit agak telat kalo aku nulis ini. Ini terkait akuisisi Sun Microsystem oleh Oracle kemudian diikuti oleh keluarnya Jonathan Schwartz serta keluarnya James Gosling salah satu co-creator Java dari Oracle April 2010 dan jika kita mengikuti blognya, maka kita sungguh akan sangat berpikir bahwa ada yang "kurang baik" yang mengikuti akuisisi SUN Microsystem oleh Oracle. Yang paling hangat saat ini adalah mengenai pertengaran Oracle dan Google khususnya pada Android sebuah opensource project dengan bahasa pemrograman Dalvix yang notabene opensource turunan java. Kenapa Google dikejar sementara baik Android dan Dalvix adalah opensources? Karena Google menyatakan bahwa mereke berdiri di belakang Android. Dor! Plak ada sasaran! Dan jadilah ada "pertengkaran rumit" antara Oracle adn Google.
Sejauh ini, "pertengkaran" antara Oracle Google memang belum memberikan imbas negatif terhadap perkembangan java. Namun saya yakin dari kondisi seperti ini, lama-kelamaan akan terpengaruh juga. Dan dari berita-berita terakhir ternyata peperangan Oracle dan Google masih berlangsung.
"Konfrontasi ini, bukan tentang perusahaan yang baik atau perusahaan yang jahat adlam situasi ini." Kata Douglas Lea, seorang ilmuwan dari State University of New York. "Tetapi ini tentang perusahaan-perusahaan yang bersaing secara jahat (viciously) dan mempunyai tujuan yang berbeda. Dan dalam kasus ini, anda bisa melihat 2 perusahaan/korporasi yang mengkampanyekan 2 bentuk yang berbeda dari open-sources"
Yang menjadi terombang-ambing dalam kasus ini adalah orang yang tidak terlibat dalam peperangan ini, c.q. para pengembang open-sources. Mereka tentunya sangat berharap agar segera terwujud gencatan senjata antara kedua-belah pihak, atau setidaknya kedua-belah pihak menhindari hal-hal yang tidak perlu. Dan kata Lea, "Akan sangat sulit untuk memprediksikan konsekuensi dari dua perusahaan yang saling bentrok satu sama lain". Dan bagi saya sendiri, saya yang bukan programmer java tetapi banyak bergantung sama java, sangat berharap untuk tidak perlu berpikir ulang tentang Java.

Oracle v.s. Google berantem di Android karena Java

Siapa yang gak kenal Google? Saya bisa menuduh bahwa semua internet surfer pasti kenal Google. Bahkan untuk troubleshooting sesuatu orang udah bisa bilang, 'tar... aku googling dulu ya...'. Kemudian, siapa yang gak kenal Android? Sebuah operating system baru yang lagi naik daun dan dikenal secara umum di ponsel.Hampir semua orang tahu bahwa Android itu bikinan Google.
Siapa yang gak kenal Oracle? Ah yang ini mungkin cuma sedikit orang yang kenal karena dia memang gak seperti Google apalagi Android. Cuma orang yang sebagian hidupnya di IT dan apalagi berususan dengan database lah yang rata-rata kenal sama Oracle.
Siapa yang gak kenal dengan Java? Ah, hampir seluruh orang Indonesia pasti kenal java. Apalagi salah seorang tokohnya baru meninggal kemaren. Mbah Maridjan! Upppss! Salah! Bukan! Bukan java yang ini. Ha ha ha... tapi java yang memang sejarahnya gak lepas dari java coffee alias kopi jawa. Bahasa pemrograman komputer yang paling populer saat ini.
Siapa yang gak kenal Sun? Bukan Sun bubur susu yang suka dibeli beberapa ibu yang emang merasa cocok dengan produk ini. Tapi Sun Microsystem yang pertama kali bikin Java.
Terus apa urusannya sama Google, Android, Oracle, Java, Sun?
Jadi gini.... Google bikin basa pemrograman yang namanya Dalvix. Bahasa dalvix ini mirip java. Sangat mirip java J2ME (Java 2 Micro Edition yang memang buat embedded platform). Awalnya si, kayaknya anteng-anteng aja. Apalagi waktu Sun masih sendiri, belum dicaplok sama Oracle. Yap, mungkin masih dianggep enteng kali. Google yang cuma mesin pencari bikin basa pemrograman. Nah gejolak mulai berasa ketika Android mulai tampil ngganteng di dunia Gadget. Bahkan ada yang bilang mulai mengancam kedigjayaan blackberry. Nah lo....
Oleh karena itu, saat ini Oracle tengah melancarkan serangan-serangannya ke Google terkait Android melalui Dalvix. Tengok saja link-link berikut:
"Oracle says Google directly copied Java code: Here's the line-by-line comparison"
Why Oracle, not Sun, sued Google over Java
Oracle vs. Google over Java
Dan masih banyak lagi.....

Installasi Replikasi PostgreSQL

PostgreSQL merupakan salah satu open ssource database yang cukup mature dan cukup luas digunakan untuk berbagai keperluan dari tradisional OLTP atau OLAP. Dari sisi kinerja, sebagai database yang telah mature teknologinya, PostgreSQL sudah tidak lagi diragukan. Untuk kemampuan mengolah/menyimpan data, menurut laporan ComputerWorld, Yahoo Inc. telah menggunakan PostgreSQL yang dimodifikasi untuk keperluan Data Ware House. Dari hasil modifikasi yang merubah penyimpanan dari row based menjadi column based, Yahoo Inc. telah mengoperasikan PostgreSQL dengan besar data 2 peta-byte, atau 2.000 terra-byte, atau 2.000.000 giga-byte, atau 2.000.000.000 mega-byte!!! Kita doakan saja Yahoo Inc. bersedia merilis postgreSQL yang telah mereka modifikasi ke komunitas pengguna postgreSQL. Hal yang masih menghantui para pengguna PostgreSQL adalah masalah replikasi. Sebenarnya banyak alternatif yang ditawarkan untuk mengimplementasikan replikasi pada PostgreSQL. Setidaknya beberapa yang sudah kita kenal diantaranya: PGCluster, PGPool, Sequoia, Slony-I. Namun, di sini saya hanya akan membahas secara mendalam untuk 2 teknologi replikasi. PGCluster dan Slony-I, karena kebanyakan referensi mengarah kepada PGCluster dan Slony.


PGCluster
Merupakan statement based multi master replication, namun tidak melakukan pooling terhdap statement. PGCluster melakukan modifikasi terhadap paket source PostgreSQL sehingga memungkinkan melakukan komunikasi antar node untuk saling me-replay setiap statement yang diterima dari node lain. Sesuai dengan namanya, PGCluster mempunyai kemampuan load balancing, sehingga bias melakukan pembagian tugas antar node. Hal yang dirasa kurang dari PGCluster adalah ketidakhadiran statement queuing yang akan mengatur queue suatu statement yang akan direplay oleh suatu node. Hal ini akan menuntut suatu transaksi untuk bisa commit pada semua node yang terlibat, atau, stag! Oleh karena itu pada konfigurasi pgCluster ada satu item yang memungkinkan untuk merubah satu node menjadi hanya readonly (untuk superuser sekalipun) pada kondisi standalone (tidak terhubung dengan node lain). Ini dilakukan untuk menjaga integritas data oleh karena ketidak hadiran statement queuing yang bisa menggaransi data sampai kepada subscriber bagaimanapun kualitas jaringan komunikasi yang ada (pada batas logis tentunya).
Gambar Logic PGCluster

Gambar 1. Konfigurasi lengkap pgCluster

Pada gambar terlihat bahwa secara logic pada suatu cluster yang melibatkan dua database (ClusterDB), akan menyertakan 3 server lain yang meliputi Load Balancer, Replicator 1, dan Replicator 2.
Pada kondisi riil, bergantung kepada kebutuhan, gambar di atas bisa disederhanakan menjadi hanya 2 server. Replicator 1 bisa digabung dengan ClusterBD 1 sementara Replicator 2 digabung dengan ClusterDB 2. Load Balancer, bergantung kepada kebutuhan, apa bila koneksi diarahkan dari ClusterDB 1, maka load balancer bisa dibenamkan kedalam installasi ClusterDb 1. Pada kondisi dimana justeru load balancer tidak dibutuhkan, maka Load Balancer bisa ditiadakan.

1. Installasi PGCluster
PGCluster bukan merupakan aplikasi terpisah dari PostgreSQL, namun merupakan modifikasi dari PostgreSQL dengan tujuan memberikan fitur clustering/replication. Untuk itu hal yang harus diperhatikan adalah, jika kita akan melakukan clustering terhadap existing database maka kita harus mengambil PGCluster yang sesuai dengan versi dari existing database kita. Misal, kita menggunakan PostgreSQL 8.3, maka kita harus menggunakan PGCluster ver. 1.9 yang dibangun berdasar versi 8.3.
Kita bisa mendownload PGCluster dari link berikut ini http://pgfoundry.org/projects/pgcluster/
Dalam contoh kali ini, akan digunakan PostgreSQL 8.3 sehingga versi PGCluster yang digunakan adalah versi 1.9 Link http://pgfoundry.org/frs/download.php/2408/pgcluster-1.9.0rc7.tar.gz
Untuk lab kita kali ini, akan melibatkan 1 PC (1 IP address) dengan dua PostgreSQL, 1 Load Balancer dan 1 replicator. Gambaran dari konfigurasi untuk lab ini bisa dilihat pada gambar berikut:

Gambar 2: Test pgCluster denganhanya memanfaatkan 1. PC.

Pertimbangan untuk memilih strategi ini adalah bahwa kondisi aplikasi yang akan kita tangani tidak mendukung dijalankannya load balancer yang memungkinkan result diambil bukan dari satu tempat tertentu. Ini berbahaya untuk pembentukan nomor pendaftaran pada aplikasi yang akan ditangani.

Langkah installasi
Persiapan
Untuk menjalankan pgcluster, sangat disarankan untuk tidak menggunakan root user, dan untuk itu kita harus menyediakan user pgcluster dengan menjalankan perintah

root@myhost~$: su – pgcluster [change user ke pgcluster]
pgcluster@myhost~$:cd pgcluster-1.9.0rc7 [masuk ke direktori source]
pgcluster@myhost~$:./configure --enable-thread-safety -–prefix=/opt/pgc/pgcluster
[konfigure kompilasi source. --prefix akan mengarah proses installasi kepada direktory /opt/pgc/pgcluster. Jika tidak disebutkan, maka akan diarahkan ke /usr/local/pgsql]
pgcluster@myhost~$:make all [compail source menjadi executable dan library]
pgcluster@myhost~$:make install [install executable ke direktory yang telah disebutkan di prefix]

Inisiasi Database

pgcluster@myhost~$:vi ~/data2/postgresql.conf [edit postgresql.conf untuk data2]

Cari line untuk config value port [pada line 60]. Hapus '#' character di depan 'port' dan rubah 5432 menjadi 5433.
Catatan: Untuk onfigurasi riil dengan lebih dari 1 mesin atau slave terinstall di mesin yang lain maka listener port masih boleh dipertahankan pada port 5432 (default port postgreSQL)

Edit cluster.conf untuk master (~/data1) dan slave (~/data2)

<replicate_server_info>
<host_name> replicat1.pgcluster.org </host_name>
<port> 8001 </port>
<recovery_port> 8101 </recovery_port>

menjadi

#-------------------------------------------------------------
<host_name> localhost </host_name>
<recovery_port> 7001 </recovery_port>
<rsync_path> /usr/bin/rsync </rsync_path>
<rsync_option> ssh -2 </rsync_option>
<rsync_compress> yes </rsync_compress>
<rsync_timeout> 10min </rsync_timeout>
<rsync_bwlimit> 0KB </rsync_bwlimit>
<pg_dump_path> /usr/local/pgsql/bin/pg_dump </pg_dump_path>
<ping_path> /bin/ping </ping_path>
<when_stand_alone> read_only </when_stand_alone>
<replication_timeout> 1min </replication_timeout>
<lifecheck_timeout> 3s </lifecheck_timeout>
<lifecheck_interval> 11s </lifecheck_interval>

Menjadi

pgcluster@myhost~$:cp /opt/pgc/pgcluster/share/pgreplicate.conf.sample ~/data1/pgreplicate.conf

Catatan: Pada kondisi riil, kopikan ke direktori data pada mesin master.

Edit dengan menggunakan vi

<cluster_server_info>
<host_name> master.pgcluster.org </host_name>
<port> 5432 </port>
<recovery_port> 7001 </recovery_port>
</cluster_server_info>
<cluster_server_info>
<host_name> clusterdb2.pgcluster.org </host_name>
<port> 5432 </port>
<recovery_port> 7001 </recovery_port>
</cluster_server_info>

menjadi

#-------------------------------------------------------------
<host_name> localhost </host_name>
<replication_port> 8001 </replication_port>
<recovery_port> 8101 </recovery_port>
<rlog_port> 8301 </rlog_port>
<use_replication_log> no </use_replication_log>
<replication_timeout> 1min </replication_timeout>
<lifecheck_timeout> 3s </lifecheck_timeout>
<lifecheck_interval> 15s </lifecheck_interval>
#-------------------------------------------------------------

Bagian yang dicetak tebal akan digunakan untuk menentukan setting pada cluster.conf

Test Konfigurasi
Jalankan database

pgcluster@myhost~$:/opt/pgc/pgcluster/bin/psql -h localhost -d postgres [menjalankan interactive sql ke localhost port 5432 user pgcluster (sesuai login os) database postgres]
Welcome to psql 8.3.8, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

postgres=#
[koneksi berhasil]

pgcluster@myhost~$:/opt/pgcluster/bin/psql -h localhost [menjalankan interactive sql tersambung ke localhost default port (5432) user pgcluster (default sesuai login os) db pgcluster (default sesuai db user)]
psql: FATAL: database "pgcluster" does not exist [pesan kesalahan menunjukan bahwa database pgcluster tidak diketemukan pada localhost port 5432 (master) ]
pgcluster@myhost~$:/opt/pgcluster/bin/psql -h localhost -p 5433 [menjalankan interactive sql tersambung ke localhost port 5433 user pgcluster (default sesuai login os) db pgcluster (default sesuai db user)]
psql: FATAL: database "pgcluster" does not exist [pesan kesalahan menunjukan bahwa database pgcluster tidak diketemukan pada localhost port 5433 (slave) ]

Test Replikasi

pgcluster@myhost~$:/opt/pgcluster/bin/psql -h localhost | [ -p 5433]
Welcome to psql 8.3.8, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

pgcluster=#

Seharusnya baik ke port 5432 maupun ke port 5433 (master maupun slave) akan memberikan hasil yang sama.

Untuk memastikan jalankan perintah berikut

CREATE TABLE
[response dari server database]

Check ke dataserver 5432.

no | nama
----+------
(0 rows)

Check ke dataserver 5433

pgcluster@mastoyo:~$ /opt/pgc/pgcluster/bin/psql -h localhost -p 5433 -c "select * from testtable"
no | nama
----+------
(0 rows)

Test insert data

INSERT 0 1

Check ke dataserver 5432

no | nama
----+-----------
1 | test nama
(1 row)

Check ke dataserver 5433

no | nama
----+-----------
1 | test nama
(1 row)

Slony
Slony merupakan aplikasi yang murni berfungsi sebagai replication server. Berbeda dengan pgCluster, slony tidak mendukung load balancing. Slony bukanlah statement based replication meskipun yang direplikasikan merupakan statement, tetapi hanya transaksional statement., sedangkan DDL tidak akan direplikasikan. slony adalah table based replication dan setiap table yang akan direplikasikan harus didefinisikan terlebih dahulu. Statement yang akan direplikasikan terlebih dahulu akan disimpan dalam dalam suatu skema yang didefinisikan dalam 'Cluster'. Adanya skema ini akan mampu menggaransi bahwa data yang akan direplikasi akan sampai ke subscriber. Artinya dalam situasi terjadi gangguan terhadap komunikasi, statement masih tersimpan didalam 'Cluster'. Ketika komunikasi telah pulih, proses replikasi akan kembali diteruskan untuk setiap statement yang belum tereplikasi. Secara garis besarnya proses replikasi dengan menggunakan Slony bisa dikatakan masih lebih bisa lebih diandalkan.
Sampai saat ini, slony menjalankan 2 project. Slony-I replication project master-slave. Slony-II replication project untuk master-master.
Untuk kepentingan saat ini, kita akan menggunakan Slony-I. Hampir sama dengan konfigurasi yang kita pakai dalam membentuk replikasi dengan menggunakan pgCluster, applikasi yang akan kita replikasikan datanya memang masih belum mendukung diimplementasikannya load balancing yang membutuhkan konfigurasi master-master. Disamping itu dalam situasi bencana di DC, tentunya juga tidak membutuhkan replikasi balik dari situs DRC ke situs DC karena DC nya sendiri tidak operasional.


Gambar logic Slony




Gambar 3. Konfigurasi komunikasi Slony

Gambar di atas digambarkan untuk kondisi lab yang menggunakan satu server dengan satu IP (localhost).
Dari gambar di atas bisa dilihat bahwa Master database akan dijalankan dan listening di port 5432 sedang Slave database listening di port 5433. Replication agen (slon) kemudian dijalankan untuk terkoneksi ke slave (jika master) dan ke master (jika slave).

Persiapan
Sebelum kita lanjutkan untuk setup replikasi terlebih dahulu kita harus mengenal beberapa hal mengenai slony.
Cluster kumpulan node yang berpartisipasi pada proses replikasi dengan menggunakan slony.
Node adalah entity yang unik yang terdiri dari kombinasi IP address, Port, dan database.
Path adalah informasi koneksi antara cluster dan node.
Replication Set adalah sekumpulan table, dan secara opsional sequence object dimana data akan direplikasikan.
Master adalah asal dari data yang akan direplikasikan.
Slave atau juga sering disebut sebagai subscriber.
Provider adalah node yang menyediakan data yang akan direplikasikan
Cascaded Subscription adalah konfigurasi dengan minimal ada satu node yang berfungsi sebagai Provider sekaligus Subscriber.
Slon. Slony daemon yang akan mengontrol proses replikasi. Untuk linux setiap node memiliki slon – nya masing-masing, sedangkan untuk Windows hanya ada 1 slon service dalam satu host.
Slonik, program utility yang digunakan untuk memproses perintah untuk membuat dan mengupdate konfigurasi.

Penyiapan postgreSQL engine.
PostgreSQL engine bisa kita dapatkan dari berbagai sumber. Saya lebih menyarankan untuk menginstall langsung dari source program daripada binary. Source program bisa didapatkan langsung dari http://www.postgresql.org maupun dari beberapa repository local seperti http://kambing.ui.ac.id. Dalam lab ini, kita akan menggunakan PostgreSQL versi 8.3.0 dengan Slony-I versi 1.2.21.
Berbeda dengan pgCluster, Slony-I adalah aplikasi terpisah dari PostgreSQL atau dengan kata lain, dikembangkan terpisah bukan pengembangan PostgreSQL, sehingga kita bisa menggunakan source normal PostgreSQL.
Sebagaimana pgCluster, untuk menjalankan postgreSQL sangat disarankan untuk menggunakan non-root user sehingga kita harus mempersiapkan terlebih dahulu user yang akan kita pergunakan untuk menjalankan postgreSQL. Apabila, kita melakukan installasi dari sumber binary (tanpa melalui proses kompilasi), maka bisa kita lihat bahwa user 'postgres' otomatis akan terbentuk. Kita bisa meniru dengan menyediakan user 'postgres' untuk installasi postgreSQL kita.

root@myhost~$useradd -d /opt/pgs -s /bin/bash postgres [Menambahkan user postgres dengan home directory dan bash shell]
root@myhost~$:mkdir /opt/pgs [buat home direktory postgres]
root@myhost~$chown postgres:postgres /opt/pgs [Change Ownership dari /opt/pgs kepada postgres]
root@myhost~$:cp /home/myuser/Download/postgresql-8.3.0.tar.bz2 /opt/pgs [kopikan source postgreSQL dari direktori download ke direktori /opt/pgs]
root@myhost~$:cd /opt/pgs [masuk ke direktory /opt/pgs]
root@myhost~$:bunzip2 postgresql-8.3.10.tar.bz2 [extract file menjadi tarball file]
root@myhost~$:tar -xvf postgresql-8.3.10.tar [extract tarball file]
root@myhost~$chown postgres:postgres /opt/pgs -Rv [Change Ownership dari semua file di bawah /opt/pgs kepada postgres]
root@myhost~$:su – postgres [switch user ke postgres]
postgres@myhost~$:cd postgresql-8.3.10 [masuk ke direktori postgresql-8.3.10]
postgres@myhost~$:./configure --prefix /opt/pgs/pgsql [konfigurasi untuk kompilasi source postgresql]
postgres@myhost~$:make all [menjalankan proses kompilasi source menjadi binary executable files]
postgres@myhost~$:make install [menjalankan proses installasi ke direktori yang telah di tentukan]

Installasi Slony-I dari source code

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
if [ -d /opt/pgsql/bin ] ; then
PATH=/opt/pgs/pgsql/bin:$PATH
fi
export CLUSTERNAME=slony_example
export MASTERDBNAME=mst_test
export SLAVEDBNAME=slv_test
export MASTERHOST=localhost
export SLAVEHOST=localhost
export REPLICATIONUSER=postgres

Pada contoh di atas bisa dilihat adanya perubahan environment variable $PATH dan penambahan beberapa environment variable yang meliputi
CLUSTERNAME = namespace atau nama cluster yang akan digunakan untuk mendefinisikan replikasi
MASTERDBNAME = nama database Master pada master engine. Ingat, bahwa Slony melakukan replikasi pada level table.
SLAVEDBNAME = name database pada Slave engine.
MASTERHOST = hostname (IP) dimana master engine terpasang
SLAVEHOST = hostname (IP) dimana slave engine terpasang
REPLICATIONUSER = user setara superuser yang akan digunakan sebagai user yang menghandle replikasi dan si sini kita menggunakan postgres

Setelah kita melakukan penyesuaian pada file profile, untuk mengaktifkan profile, kita lakukan logout dengan menekan Ctrl+D dan swith ke user postgres lagi. Dan check environment variable yang kita set dengan mengetikkan 'env' tanpa tanda kutip yang diteruskan dengan [enter].

Inisiasi Database
Bila semua nilai environment variables sudah terpasang dengan baik, langkah berikutnya dalah menginisiasi database.

#!/bin/sh
slonik << _EOF_
cluster name = $CLUSTERNAME;
#penentuan node yang terlibat dalam replikasi, informasi ini akan dipakai oleh slonik
#untuk melakukan koneksi dengan setiap node
#perhatikan bahwa conninfo tidak menyebutkan password, yang berarti harus ada perubahan
#pada file pg_hba.conf untuk membuka trust connection antar node
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#melakukan inisiasi cluster sebagai 'Master Node')
init cluster ( id=1, comment = 'Master Node');
_EOF_

rubah initcluster.sh menjadi executable:

#!/bin/sh
slonik << _EOF_
#4 Baris-baris berikut adalah pengulangan untuk mengenali cluster
cluster name = $CLUSTERNAME;
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#baris berikut merupakan statement untuk menambahkan node
store node ( id=1, comment = 'Slave Node', event node = 1);
_EOF_

Rubah mode addnode.sh menjadi executable

#!/bin/sh
slonik << _EOF_
#4 baris pertama adalah pengulangan untuk mengenali cluster
cluster name = $CLUSTERNAME ;
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#baris berikut menginformasi arah replikasi dari master ke slave
store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER');
store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER');
_EOF_

Rubah mode addpath.sh menjadi executable

#!/bin/sh slonik << _EOF_
#4 baris pertama adalah pengulangan untuk mengenali cluster
cluster name = $CLUSTERNAME ;
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#baris berikut akan memerintahkan slony untuk mengcreate set dengan id=1, origin=1)
create set ( id=1, origin=1, comment='table-tabel terreplikasi');
_EOF_

Rubah mode initset.sh menjadi executable.

#!/bin/sh
slonik << _EOF_
#4 baris pertama adalah pengulangan untuk mengenali cluster
cluster name = $CLUSTERNAME;
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#baris berikut akan memerintahkan slony untuk menambahkan table testtable ke dalam repl. Set)
set add table ( set id=1, origin=1, id=1, fully qualified name='public.testtable' comment='testtable', key='nomor');
_EOF_

Rubah mode addtable.sh menjadi executable

#!/bin/sh
slonik << _EOF_
#4 baris pertama adalah pengulangan untuk mengenali cluster
cluster name = $CLUSTERNAME;
node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port=5433 user=$REPLICATIONUSER';
#baris berikut akan memerintahkan slony untuk menambahkan table testtable ke dalam repl. Set)
subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
_EOF_

Rubah mode addsubscriber.sh menjadi executable

#!/bin/sh
slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST" >> slonmaster.log 2>&1 &

Rubah mode startmaster.sh menjadi executable

#!/bin/sh
slon $CLUSTERNAME "dbname=$SLAVEDBNAME port=5433 user=$REPLICATIONUSER host=$MASTERHOST" >> slonslave.log 2>&1 &

Rubah mode startslave.sh menjadi executable

postgres@myhost~$:echo “export TZ=ICT”>>~./profile

Karena ada perubahan setting timezone maka postgreSQL engine yang telah aktif harus direstart untuk bisa menggunakan setting timezone yang baru

Urutan menjalankan file-file setup replikasi.

postgres@mastoyo:~$ psql -d $MASTERDBNAME -c "insert into testtable (nomor,nama,alamat) values (2,'Paman Goble','Jalan Rusak');"
INSERT 0 1
postgres@myhost:~$ psql -d $SLAVEDBNAME -p 5433 -c "select * from testtable;"
nomor | nama | alamat
-------+-------------+-------------------------
1 | Kopral Jono | Jalan jalan pelan pelan
2 | Paman Goble | Jalan Rusak
(2 rows)

postgres@myhost:~$ psql -d $MASTERDBNAME -c "delete from testtable where nomor = 1"
DELETE 1
postgres@myhost:~$ psql -d $SLAVEDBNAME -p 5433 -c "select * from testtable;"
nomor | nama | alamat
-------+-------------+-------------
2 | Paman Goble | Jalan Rusak
(1 row)

Yang akan datang: Replikasi PostgreSQL 9

Another life

Since known that Titan (the largest moon of Saturn) has a hydrological cycle that is very similar to earth with a bit of a big difference where the hydrological cycle on Earth involve water, while the Titan include hirokarbon which in this case is methane, then I think a little naughty. Possible that Earth and Titan are two of the same world with a lot of difference?

My naughty mind then wandered away to wishful thinking about life. Could there be life in common with many differences as depicted in the hydrological cycle of Earth and Titan? Especially when it aired that Nasa has ever found life in a place that does not allow the existence of life. The most recent information describing caught on a shrimp that live in extreme environments in the northern hemisphere. Some previously existing information jeis-crustacean species which can survive in extremely hot environments. In a very toxic environment.

This information then led me into a little upset. My naughty little show invited me to rethink the definition of life on other worlds in the cosmos. If there are clouds on Titan could be like on Earth, there could be similar to rain on the earth, can exist on Earth-like lightning. There is a similar wind on earth. All the similarities were only different in that the water is not H20 but C2H2D. Temperatures there also reached -170 C. If it is said that the environment does not support life on Titan, are we not to re-think that the difference of the similarity of titan with the earth's life could also support life? Although it differs with the earth. It could be life there is not need 02 but precisely ethane, or nitrogen instead? Maybe there's life on planet Earth is considered hell. Very hot. Only God knows.

Client host rejected: cannot find your hostname

'Client host rejected: cannot find your hostname', pesan ini muncul dan cukup banyak yang mengeluhkan (baca: meributkan) beberapa hari terakhir ini, ketika sambungan internet di kantor diganti dan mikrotik juga diganti.
"Pak, ini imil dari si anu kok gak bisa masuk ya!?"
"Pak, ini imil dari si itu juga kok gak bisa masuk ya!?"
Mumet. Wong sebelumnya gak pernah ada masalah begini kok ujug-ujug bin tiba-tiba ada muncul mangsalah beginian. Akhirnya "Coba temennya suruh kirim tolakan imilnya ke saya..."
Yup, itu cara paling gampang dan ringan buat nge-trace. Daripada harus melototin log yang seabreg, mending langsung cari pokok masalahnya. Dan ternyata, ya itu tadi, 'Client host rejected: cannot find your hostname'
Aku gugal-gugel cari tahu sama paman gugel akhirnya didapet kesimpulan bahwa itu adalah sistem proteksi dari mail system untuk menghalau spammer. Jadi setiap imil yang diketahui terkirim dari server yang DNS record nya gak valid, sama mail system kantor bakal ditolak, karena dianggep sepamer. Nah lo.... Memang ini sangat efektif, karena virus-virus yang suka nyepam biasanya bakal menggunakan komputer hostnya langsung untuk merelay e-mail dan ngirim sepam kemana-mana. Tapi, ada tapinya nih; ada beberapa server yang didedikasikan sebagai mail server nyatanya juga gak punya DNS record yang valid. Lha, trus gimana? Kan gak etis kalo kita ngasih tahu sama contact kita kalo mail server mereka tertengarai sebagai spammer. Hmmm... akhirnya, ya udah kita rubah policynya.
Berhubung di kantor make Zimbra maka tinggal masuk ke Admin Control Zimbra masup ke Admin UI nya, trus pilih menu gombal, eh salah, Global Settings, pilih tab MTA. Nah di tab ini, pada groups Protocol Checks pastikan semua check box di group ini dalam kondisi checked (true). Kemudian di Group DNS checks pastikan Check Box 'Client's IP address (reject_unknown_client)' tidak di-check (false), Check Box 'Hostname in greeting (reject_unknown_hostname)' tidak di-check (false), dan Check Box 'Sender's domain (reject_unknown_sender_domain)
' dalam kondisi checked (true). Kemudian klik 'Save'. Dan untuk memastikan konfigurasi telah efektif, coba masup ke server console melalui putty sebagai user 'zimbra' dan jalankan perintah berikut:

zimbra@mail>zmprov gacf | grep zimbraMtaRestriction

hasilnya:

zimbraMtaRestriction: reject_invalid_hostname
zimbraMtaRestriction: reject_non_fqdn_hostname
zimbraMtaRestriction: reject_non_fqdn_sender
zimbraMtaRestriction: reject_unknown_sender_domain

Monggo dipun coba....