Belajar Docker.

Apa itu Docker ?

Docker adalah suatu project open source yang memungkinkan kita untuk membuat sebuah wadah atau container, yang berisikan suatu aplikasi, yang sudah kita konfigurasi, kita kemas, dan kita dapat menjalankannya.

Dalam bahasa yang lebih sederhana adalah, coba teman teman membayangkan tumpukan kontainer peti kemas di pelabuhan laut. Ada kontainer warna biru untuk database Postgresql, ada kontainer warna hijau untuk web server Apache + Php, ada kontainer warna kuning untuk database MySQL, ada kontainer warna merah untuk Bisnis Intelegence Pentaho, ada kontainer warna oranye untuk Django + Python, dan banyak lagi kontainer kontainer yang lainnya.

Nah, masing masing kontainer itu memiliki konfigurasi yang berbeda beda, misalnya ada kontainer warna biru (Postgresql) memerlukan konfigurasi database replikasi Bucardo. Kontainer yang lain tidak perlu konfigurasi Bucardo ini, tetapi memerlukan konfigurasi yang lain, misalnya kontainer warna merah (BI Pentaho) memerlukan konfigurasi JAVA SDK, yang mana konfigurasi ini juga tidak diperlukan di kontainer yang lainnya.

Kontainer kontainer tersebut berada di suatu pelabuhan peti kemas, siap untuk dikirimkan menggunakan kapal laut. Managemen pelabuhan sudah mempersiapkan dokumen tata cara pengiriman kontainer kontainer berjenis DOCKER itu. Syahbandar yang akan melakukan bongkar muat kontainer sesuai permintaan dari kapal yang akan berlabuh.

Kemudian datang sebuah kapal pengangkut peti kemas milik seorang web programmer yang memiliki kemampuan mengangkut kontainer berjenis DOCKER. Syahbandar di pelabuhan kemudian membuat duplikasi kontainer warna hijau (Apache + PHP) dan warna kuning (MySQL) dan meletakkannya ke dalam kapal pengangkut ini.

Tak lama berselang, datanglah kapal pengangkut peti kemas milik seorang database administrator dan dia memerlukan kontainer warna biru (PostgreSQL) dan kontainer warna kuning (MySQL). Syahbandar pelabuhan segera melakukan duplikasi terhadap kontainer kontainer yang di perlukan tersebut.

Nah, kedua kapal ini kemudian melanjutkan perjalanan mengarungi samudra yang luas. Pada suatu saat mereka akan berhenti di pelabuhan tujuan, dan kemudian mereka menurunkan kontainer yang mereka bawa, atau menduplikasi kontainer sebelum meletakkannya di pelabuhan tujuan, atau membawa kontainer yang baru ke dalam kapal.

Dari penjelasan diatas, kita dapat menganalogikan sebagai berikut, bahwa pelabuhan atau kapal adalah suatu platform DOCKER, dimana kita bisa membawa bermacam macam kontainer didalamnya. Suatu Pelabuhan dapat diartikan sebagai suatu Server Komputer, dan suatu kapal dapat diartikan sebagai suatu adalah laptop dari seorang software engineer atau laptop dari seorang system engineer. SuatukKontainer dapat diartikan sebagai suatu applikasi dengan konfigurasi librarynya.

Semoga penjelasan sederhana diatas dapat membantu teman teman memahami mengenai apa itu Docker, dan apa itu kontainer, dan bagaimana penerapan penggunaannya.

Bagaimana pendapat teman teman ?

Desain Table untuk replikasi

  Hi, sudah lama blog ini tidak saya update, tentu saja alasan paling utama adalah kesibukan. Klise sekali ya, jadi ingat para blogger yang lain, selalu memakai alasan yang sama, sibuk.

Baiklah, topik kita kali ini adalah desain tabel yang akan di pergunakan untuk replikasi. Replikasi data ditempat kita adalah Master to Master, artinya setiap lokasi dapat melakukan update data dan masing masing lokasi akan melakukan sinkronisasi dengan lokasi lainnya. Desain tabel ini berdasarkan pengalaman yang kita miliki selama ini, yaitu :

  • Primary Key
    • Setiap record yang tercatat harus memiliki primary key, yang dapat dipergunakan untuk identifikasi unik record tersebut. Tingkat ke-unik-annya harus mempertimbangkan kode lokasi dan kode perusahaan.
    • Dengan pertimbangan di atas, pada saat replikasi, kita yakin bahwasannya data setiap record itu adalah unik, tidak akan mungkin tercampur / bertabrakan dengan data dari lokasi lainnya.
    • Contoh primary key nya :
      • A1   : A untuk kode lokasi, 1 untuk no urut data
      • XA1 : X untuk kode perusahaan, A untuk kode lokasi, 1 untuk no urut data.
  • Tanggal Pembuatan
    • Kita harus mencatat juga kapan record tersebut di catat di dalam tabel. Umumnya kita kombinasikan dengan constraint DEFAULT.
    • Contoh untuk Postgresql dan Oracle :
      • created_date timestamp default NOW()
      • created_by numeric(8)
  • Tanggal Perubahan
    • Kita juga harus mencatat kapan record tersebut berubah/diubah di dalam tabel. Pencatatannya dilakukan pada saat kita menjalankan perintah UPDATE atau REPLACE.
    • Contoh untuk Postgresql dan Oracle :
      • modified_date timestamp
      • modified_by numeric(8)

ID yang unik adalah suatu keharusan, sementara untuk tanggal Pembuatan dan perubahan sebagai data pendukung terhadap status record tersebut. Tentusaja data pendukungnya dapat bertambah sesuai kebutuhan, tetapi kolom kolom yang diatas itu adalah keharusan di tempat kita. Jadi standard DDL untuk tabel yang akan di replikasi seperti berikut :

<!-- Center Pane -->
Create Table Master_tbl
( id varchar(16),
  ...
  ...
  created_date timestamp default NOW(),
  created_by numeric(8),
  modified_date timestamp,
  modified_by numeric(8),
  contraint master_tbl_pk primary key (id)
);

Bagaimana dengan teman teman ?

Replikasi melambat setelah tabel reorganize dengan CTAS

  Teman teman pasti tahu kalau saya memakai Bucardo untuk replikasi. Nah kejadian terakhir yang saya alami dengan bucardo berhubungan dengan tabel reorganisasi. Begini ceritanya.

Saya memiliki 3 server yang saya pergunakan untuk master to master replication dan hanya salah satu server saja yang di pergunakan sebagai server transaksi utama, lainnya untuk keperluan backup dan baca data. Nah saat saya melakukan analisa terhadap server untuk keperluan backup dan data ini, saya menemukan beberapa tabel yang ukurannya 3x lebih besar dari asalnya di server transaksi utama. Saya cek apakah mungkin tabelnya ter-fragmentasi atau tidak. Ternyata benar ada fragmentasi disana.

Akhirnya tabel yang ter-fragmentasi itu saya betulkan dengan metode CTAS. Berhasil. Salah satu tabel tersebut setiap malamnya melakukan update data sekitar 150k records. Jadi kalau dengan bucardo akan menjadi 300K records. Saya berkeyakinan bahwa semuanya akan lancar.

Esoknya, hari ke 1, sewaktu saya memonitor ZABBIX, ini adalah tools di linux untuk melihat kondisi server, saya mendapati bahwa dua server dimana saya melakukan CTAS kemarin cpu-load-nya sangat tinggi. Itu selesai setelah 6 Jam process, baru load nya turun drastis. Langsung saja saya curiga, mungkin itu terjadi karena tabel yang kemarin saya CTAS. Kemudian saya coba matikan bucardo-nya dan berharap esok hari zabbix akan memberikan laporan yang lebih baik.

Esoknya, hari ke 2, pagi pagi langsung saya lihat kondisi Zabbix, ternyata benar, load selama 12 jam terakhir rendah sekali. Jadi saya berkesimpulan bahwa load yang tinggi kemarin itu karena Bucardonya. Saya remove tabel tabel yang kemarin saya CTAS dari daftar tabel yang di replikasi di bucardo. Kemudian bucardo saya start lagi untuk menyelesaikan semua data data yang belum di replikasi. Dalam 3 jam ke depan Zabbix menunjukan kalau 2 server tersebut sibuk, karena menyelesaikan transaksi bucardo. Setelah itu rendah kembali, normal seperti sedia kala.,

Nah, saya browsing mencari jawaban mengenai hal ini, tetapi masih belum juga ketemu jawabannya. Mengapa setelah tabel tersebut di CTAS, process bucardo di  tabel tersebut jadi lebih lambat. Apakah ada teman teman yang memiliki pengalaman seperti ini ? mohon info nya.

Bucardo : Perintah Truncate Table Ter-Replikasi

  Hari ini saya mendapatkan pelajaran berharga dari bucardo. Saya secara tidak sengaja, maksudnya aktivitas yang saya kerjakan akan ter-replikasi ke server yang lain.

Jadi ceritanya, saya akan mendaftarkan tabel baru ke dalam replikasi bucardo. Tabel ini tabel aktif, dan transaksi masih sedang berlangsung. Rencana saya, setelah saya daftarkan tabel tersebut di bucardo, saya akan sinkronisasi datanya terlebih dahulu, baru kemudian mengaktifkan bucardonya. Sebelum melakukan sinkronisasi saya harus memastikan tabel di server yang lain kosong, saya pakai perintah truncate, dan ini adalah kesalahan saya, karena ternyata perintah truncate termasuk perintah SQL yang akan ter-replikasi juga.

Berikut kronologis  nya :

  • Server A: Tambahkan tabel yang baru ke dalam replikasi bucardo
  • Server A: Validate sync-nya
  • Server B: kosongkan tabel yang baru di server B pakai perintah truncate
  • Server A: copy data dari server A ke server B
  • Server A: start bucardo

Nah, begitu bucardo start, terjadilah replikasi dari server B ke server A, perintah truncate tersebut, sehingga data di server A terhapus juga. Berikut ini adalah urutan yang benar  :

  • Server B: kosongkan tabel yang baru di server B pakai perintah truncate
  • Server A: copy data dari server A ke server B
  • Server A: Tambahkan tabel yang baru ke dalam replikasi bucardo
  • Server A: Validate sync-nya
  • Server A: start bucardo

Dijamin, truncate tidak akan ikut ter-replikasi.

Bucardo : Mengatur object dalam sync

  Sekarang  bucardo sudah berjalan dengan lancar. Kadang kala kita perlu mengatur object postgresql di dalam bucardo sync. Object ini adalah table dan sequence. Kedua object ini dapat kita tambahkan atau kita hapus.

Contoh yang saya miliki adalah sebagai berikut :

  • Table A, ingin saya replikasi dari db1 ke db2, tetapi tidak untuk db3.
  • Sequence B, ingin saya replikasi dari db1 ke db3, tetapi tidak untuk db2.

Berikut langkah langkah untuk menambah suatu object ke dalam sync :

  • stop bucardo
  • bucardo add table schema.nama_table herd=my_herd
  • bucardo add sequence schema.nama_sequence herd=my_herd
  • bucardo validate sync my_sync
  • start bucardo

Dan untuk menghapus, langkah langkah nya sebagai berikut :

  • stop bucardo
  • bucardo remove table schema.nama_table
  • bucardo remove sequence schema.nama_sequence
  • bucardo validate sync my_sync
  • start bucardo

Jika setelah menghapus suatu object, kita menemukan pesan errod di dalam file log, seperti ini :

“(23143) [Mon Dec 3 13:18:24 2012] VAC Warning! VAC was killed at line 6486: DBD::Pg::st pg_result failed: ERROR: relation “bucardo.delta_265672″ does not exist”

artinya ada object postgresql yang secara fisik sudah tidak ada di postgresql tetapi masih terdaftar di dalam sistem bucardo. Mengapa ini dapat terjadi ? bucardo yang kita pakai bukan versi stabil, masih versi beta atau alpha. Tenang saja, kita bisa memperbaikinya kan.

Untuk membetulkannya:

  • bucardo stop
  • login ke db1
  • cek melalui perintah
    • select * from pg_class where oid = 265672
  • jika tidak ada hasilnya, berarti object memang tidak ada.
  • delete from bucardo.bucardo_delta_targets where tablename = 265672
  • if no result…. ulang step ke db yang lainnya  ..dan seterusnya
  • bucardo start

Bagaimana pengalaman anda dengan bucardo ? mohon infonya.

Bucardo Server Down

  Yup betul. Pagi ini saya mendapati server bucardo saya mati. Hardware error. Saya coba restart server, selalu terhenti dengan pesan kesalahan ada pada perangkat keras. Sedikit panik sih, tetapi harus tetap tenang.  Saya hitung pilihan yang saya punya.

  • 1 Mesin DB slave
  • Tidak ada backup database bucardo
  • Server DB Master dan Server DB Slave masih berfungsi.

Pilihan yang ada adalah install bucardo di mesin DB Slave, dan register ulang semua tabel yang akan di replikasi. Seharusnya proses registrasi ulang ini dapat di hindari, tetapi karena saya tidak punya backup database bucardo, jadi harus registrasi ulang. Kalau ini berjalan, saya harus ikutkan database bucardo dalam skema backup saya.

Ada sedikit kekhawatiran dalam hati, jangan jangan bucardo nya tidak mau replikasi karena saya install database bucardo yang baru. Dalam hati berharap semoga bucardo nya tetap dapat melakukan replikasi.

So, setelah install ulang bucardo di mesin DB Slave, registrasi ulang, maka sekarang saatnya untuk start bucardo. Sambil berharap harap cemas, saya start bucardo dan tail -f log.bucardo.

Ternyata berjalan normal, tanpa kurang suatu apapun. L E G A.

Bagaimana dengan teman teman, ada memiliki pengalaman seperti ini ?

Bucardo : Mengubah stuktur table

  Setelah memakai Bucardo sekaian lama, saya memiliki kebutuhan untuk merubah struktur tabel. Menambah kolom, merubah tipe data, melebarkan kolom, atau menambah constraint. Proses ini harus dilakukan dengan kondisi tidak ada proses replikasi yang sedang berjalan atau dengan kata lain Bucardo harus berhenti.

Berikut adalah langkah langkah merubah struktur tabel :

  • Matikan Bucardo
    • bucardo stop
  • Ubah stuktur tabel di semua lokasi
    • psql -h 192.168.0.2 -U postgres
    • alter table my_table add column ….
    • alter table add constraint my_constraint …
    • Ulangi hingga semua lokasi memiliki struktur table yang sama
  • Jalankan Bucardo kembali
    • Bucardo Start

Setelah itu kita hanya perlu memonitor file log.bucardo, jikalau tidak ada error berarti proses perubahan struktur tabel berhasil dilakukan. Silahkan mencoba.

Bucardo : Menambah Server ke dalam Replikasi Master To Master

  Beberapa waktu yang lalu, saya memutuskan untuk menambahkan 1 server lagi kedalam replikasi master to master yang saya pergunakan. Saya memakai Bucardo untuk menangani replikasi master to master. Performancenya cukup memuaskan saya. Nah saat ini saya merasa perlu untuk menambah 1 server lagi untuk membagi beban kerja di server.

Pada awalnya tujuan memakai 2 server hanya untuk keperluan berbagi beban server dan backup di dalam 1 lokasi gedung, ternyata diperjalanannya untuk lokasi kota yang lain perlu juga di bagi beban servernya dan backup jika sewaktu waktu jaringan antar kota terputus, sehingga tidak akan mengganggu transaksi lokal. Untuk instalasi awal replikasi master to master dengan bucardo dapat anda baca disini.

Informasi :

  • db1 memiliki ip address 192.16.0.1
  • db2 memiliki ip address 192.16.0.2
  • db1 dan db2 berada dalam 1 gedung
  • db3 memiliki ip address 192.16.1.3
  • db3 berada di kota yang berbeda

Nah berikut adalah langkah langkah untuk menambahkan Server Database db3  ke dalam replikasi :

  • Login ke Server Bucardo dan stop replikasinya.
    • bucardo stop
  • Login ke Server Applikasi dan stop semua applikasi yang terkoneksi ke Server Database
  • Login ke Server Database ke 1 , backup dan kirim Server Database ke 3
    • pg_dump -h 127.0.0.1 -U postgres my_database > my_database.dmp
    • scp my_database.dmp root@192.16.1.3:/root
  • Login ke Server Database ke 3, buat database baru, dan restore database backupnya
    • psql -h 127.0.0.1 -U postgres -c “create database my_database; ” template1
    • psql -h 127.0.0.1 -U postgres -d my_database < my_database.dmp
  • Login ke Server Bucardo, daftarkan Server Database ke 3, dan syncronize ulang
    • bucardo add db db3 dbname=eis dbhost=192.16.1.3 dbuser=postgres dbpass=password
    • bucardo remove sync db_sync
    • bucardo remove dbgroup db_group
    • bucardo add dbgroup db1:source db2:source db3:source
    • bucardo add sync db_sync herd=db_herd dbs=db_group
    • bucardo start
  • Kemudian check log.bucardo, kita akan menemukan pesan kesalahan seperti ini :
    • “(23143) [Mon Dec 3 13:18:24 2012] VAC Warning! VAC was killed at line 6486: DBD::Pg::st pg_result failed: ERROR: relation “bucardo.delta_265672? does not exist”
    • Tenang, pesan kesalahan ini terjadi karena kita melakukan restore database beserta object object bucardo dari server asal.
    • Setelah kita restore database dan kemudian bucardo kita start, maka bucardo akan melakukan proses sinkronisasi objectnya. Karena kita melakukan restore, tentu saja object id atau OID dari object table di server yang baru akan berbeda dengan object id dari server yang lama. Oleh karena itu, bucardo akan mendaftarkan ulang object table di server yang baru, sehingga kita harus menghapus object id yang lama secara manual.
    • Mari kita periksa table bucardo_delta_targets, disinilah object table di daftarkan.
      • select * from bucardo.bucardo_delta_targets;
    • Kita akan mendapati, daftar table dengan perbedaan di tanggal registrasi, di kolom cdate. Yang perlu kita lakukan adalah menghapus semua table yang memiliki tanggal cdate tidak sama dengan saat ini atau saat prosess restore.
      • delete from bucardo.bucardo_delta_targets where to_char(cdate,’dd/mm/yyyy’) <> to_char(now(),’dd/mm/yyyy’);
    • Setelah itu periksa kembali file log.bucardo, seharusnya pesan kesalahan sudah tidak muncul lagi.
  • Done

Nah, sekarang kita memiliki 3 server di dalam replikasi master to master kita, db1 dan db2 dalam 1 gedung, db3 berada di kota yang lain. Dengan cara ini, apabila terjadi putusnya jaringan antar kota, maka user di kota yang lain tetap dapat menjalankan applikasi. Dan pada saat jaringan tersambung kembali maka bucardo akan melakukan sinkronisasi data kembali. Bagaimana pendapat anda ?

Drop rubyrep object secara manual di PostgreSQL

  Selama saya melakukan test terhadap rubyrep, ada kejadian dimana saya harus menghapus object object milik rubyrep secara manual. Menggunakan perintah rubyrep uninstall gagal, karena tidak dapat berkomunikasi dengan salah satu servernya. Alhasil dengan terpaksa harus melakukan pembersihan secara manual.

Semua object object milik rubyrep, secara default memiliki nama depan yang diawali dengan awalan “rr_“. Object yang terinstal adalah trigger dan table.

Berikut langkah langkah melakukan drop rubyrep secara manual :

  • Login ke database postgresql dimana tabel tabel rubyrep terinstall
  • Dapatkan daftar trigger trigger yang dipergunakan rubyrep
SELECT 'DROP FUNCTION ' || ns.nspname || '.' || proname || '('
       || oidvectortypes(proargtypes) || ') CASCADE;'
FROM pg_proc 
INNER JOIN pg_namespace ns ON (pg_proc.pronamespace = ns.oid)
WHERE ns.nspname = 'public'  order by proname;
  • Copy Paste perintah drop function yang dimulai dengan awalan “rr_”  tersebut untuk menjalankan perintah drop tersebut.
  • Dapatkan daftar tabel tabel yang di pergunakan rubyrep
select 'DROP TABLE '||tablename||' CASCADE; ' 
from pg_tables 
where tablename ilike 'rr_%';
  • Copy Paste perintah drop tabel yang dimulai dengan awalan “rr_” tersebut untuk menjalankan perintah drop tersebut.
  • Done.
Nah, dengan cara ini maka semua tabel dan trigger milik rubyrep sudah hilang dari sistem. Silahkan mencoba.

Bucardo memakai parameter max_stack_depth

  Pagi ini saya menemukan error di dalam file log.bucardo yang menyatakan bahwa saya harus menaikkan paramter max_stack_depth di file konfigurasi postgresql.conf. Berikut potongan pesan errornya :

(9926) [Thu Sep  6 08:32:45 2012] KID Warning! Aborting due to exception for public.my_big_table:? Error was DBD::Pg::db do failed: ERROR:  stack depth limit exceeded\nHINT:  Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depth limit is adequate. at /usr/local/share/perl/5.14.2/Bucardo.pm line 8131.

...

” Wah ini parameter apa ya ?” pikir saya. Terus terang saya belum pernah melihat secara mendetail fungsi dari parameter ini.

Menurut dokumentasi postgresql, parameter Max_Stack_Depth ini berfungsi untuk menaikkan kemampuan server dalam Execution Stack. Misalnya dalam pemrosesan fungsi fungsi rekursif seperti sub-query dan klausa IN. PostgreSQL akan memanggil parameter ini pada saat memproses fungsi fungsi rekursif itu saja, jadi tidak setiap saat. Nilai ideal dari parameter ini harusnya sama dengan nilai batasan ukuran stack di kernel linux, yang bisa diperoleh dengan menjalankan perintah ulimit -s.

$> ulimit -s

8192

Jika di komputer saya akan menghasilkan 8192. Nilai ulimit ini dalam kilobyte, ini artinya kernel saya memiliki batasan ukuran stack 8192 Kb atau 8M. Tetapi saya tidak akan menggunakan 8M ini, saya akan pakai setengahnya saja, 4M. Jikalau kita memaksa menaikkan nilai parameter ini diatas kemampuan kernel, 8M, maka sistem dapat menjadi lumpuh.

Setelah itu barulah saya merubah file konfigurasi postgresql.conf dan ubah parameter max_stack_depth.

$> vim /etc/postgresql/9.1/main/postgresql.conf 
...
max_stack_depth = 4M
...

Setelah itu server  postgresql di restart dan bucardo di start kembali. Problem selesai.