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 : 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 ?

Migrasi redmine ke server yang lain

  Saya memakai software project management bernama Redmine. Redmine adalah software gratis dan open source, project management dan bug tracking software berbasis web, Fiturnya termasuk kalender , Gantt-Chart dan menangani banyak project secara bersamaan.

Redmine yang saya pakai adalah versi 0.7.3, dan akan saya upgrade ke version 1.3.2 di mesin Ubuntu 12.04. Berikut adalah langkah langkah yang saya lakukan untuk melakukan upgrade.

Langkah di server lama adalah sebagai berikut :

  • Backup Mysql Databasedan kirim file backup ke server yang baru
    • mysqldump -u root -p redmine > redmine.dmp
    • scp redmine.dmp root@192.168.0.2:/root
  • Transfer directory files
    • scp -r /opt/redmine.0.7.3/files root@192.168.0.2:/root
  • create configuration files

Langkah di server baru adalah sebagai berikut :

  • Install semua paket yang dibutuhkan
    • sudo apt-get install apache2 mysql-client mysql-common mysql-server ruby1.8 ruby1.8-dev ruby-i18n ruby-rails-2.3 ruby-tmail rubygems ruby-builder ruby-coderay ruby-text-format ruby-blankslate ruby-mysql ruby-net-ldap ruby-rack ruby-rchardet redmine redmine-mysql
  • Buat symbolic-link halaman web redmine ke /var/www/redmine
    • sudo ln -s /usr/share/redmine/public /var/www/redmine
  • Ubah hak akses halaman web redmine
    • sudo chmod a+x /usr/share/redmine/public
  • Buat file konfigurasi untuk redmine
    • sudo vim /etc/init/redmine.conf
    • # Redmine
      description "Redmine"
      start on runlevel [2345]
      stop on runlevel [!2345]
      expect daemon
      exec ruby /usr/share/redmine/script/server webrick -e production -b 192.168.0.2 -d
  • login ke database mysql
    • mysql -u root -p
  • Buat ulang database redmine default dengan cara drop database yang lama dan buat yang baru
    • drop database redmine_default; create database redmine_default;
  • Keluar dari mysql
    • \q
  • Import database redmine yang lama ke database redmine yang baru
    • mysql -u root -p redmine_default < redmine.dmp
  • Masuk direktori redmine
    • cd /usr/share/redmine
  • Update database redmine yang lama ke database yang baru
    • rake db:migrate RAILS_ENV=production
  • Hapus semua cache yang ada
    • rake tmp:cache:clear
    • rake tmp:sessions:clear
  • Restart apache web server
    • sudo service apache2 start
  • Start redmine server
    • sudo service redmine start
  • Akses redmine melalui web browser
    • http://192.168.0.2:3000/
  • Done

Sekarang redmine saya udah menggunakan redmine 1.3.2. Semoga bermanfaat.

Migrasi server SVN

  Saya memiliki SVN server. SVN atau Subversion adalah open source version-control yang saya pergunakan untuk menyimpan kode sumber saya dan team. Pada saat kita memulai proyek , version-control yang ada hanyalah CVS dan SVN saja. Sehingga kita pakailah SVN. Kalau sekarang sudah banyak software version control yang open source yang memiliki fitur fitur lebih hebat daripada SVN seperti GIT, Mercurial dan Bazaar.

Nah, saat ini ada kebutuhan dari team untuk memindahkan SVN Server kita ke mesin yang lebih baru.

Berikut adalah langkah langkah di Server yang lama :

  • Backup repository
    • cd /data/svn/
    • svnadmin dump repository > repository.dump
  • Transfer ke server yang baru
    • scp repository.dump root@192.16.0.1:/root

Langkah langkah di Server yang baru :

  • Install SVN dan Apache
    • sudo apt-get install subversion apache2 libapache2-svn
  • Aktifkan package dav_svn
    • vim /etc/apache2/mods-enabled/dav_svn.conf
  • Buat User Admin
    • sudo htpasswd -cm /etc/apache2/dav_svn.passwd admin
  • Tambahkan User Member yang lainnya
    • sudo htpasswd -m /etc/apache2/dav_svn.passwd member_1
  • Buat repository di direktory /data/svn
    • cd /data/svn/
    • sudo svnadmin create repository
  • Load data repository ke svn
    • sudo svnadmin load repository < repository.dump
  • Ubah hak akses direktory repository
    • sudo chown www-data:www-data repository -R
  • Masuk ke Web Browser dan akses melalui
    • http://server_baru/svn
  • Done

Semoga bermanfaat.

Defrag database PostgreSQL

  Artikel ini di peruntukkan pengguna Database PostgreSQL yang memutuskan untuk melakukan defrag terhadap database anda.

Berikut adalah langkah langkah untuk melakukan defrag di database PostgreSQL :

  • Cek tabel tabel dan index index yang memiliki fragmentasi dengan menjalankan skrip berikut ini dan melihat nilai rasio dan wastebyte dari tabel bloat anda.
    • Nilai rasio itu menentukan seberapa besar fragmentasi yang terjadi di dalam tabel atau index anda.
    • Semakin besar rasio semakin besar fragmentasi yang terjadi.
    • Wastebyte adalah kondisi dimana blok data tidak dapat dipergunakan untuk menyimpan data.
  • Apabila anda mendapati rasio > 1.5 lakukan VACUUM ANALYZE.
    • VACUUM ini akan merubah wastebyte yang tidak dapat dipergunakan untuk transaksi menjadi aktif dan dapat dipergunakan lagi.
    • ANALYZE akan melakukan pembuatan statistik untuk tabel atau index tersebut.
    • Dengan melakukan VACUUM ANALYZE ini, maka wastebyte yang ada akan di aktifkan kembali, walaupun posisinya berada ditengah tengah blok data yang ada isinya.
  • Apabila anda mendapati rasio > 5 lakukan VACUUM FULL, REINDEX TABLE dan ANALYZE
    • VACUUM FULL ini akan mengaktifkan kembali wastebyte yang ada dan mengisinya dengan blok data dari bagian akhir dari tabel atau index. Sehingga bagian yang ter-fragmentasi itu akan terisi dengan data, kemudian sisa free space yang ada akan dikembalikan ke Sistem Operasi, sehingga tabel tidak akan menyimpan free-space lagi.
    • VACUUM FULL ini akan mendefrag tabel, tetapi tidak mengurutkan datanya sesuai dengan primary key tabel itu.
    • Kemudian lakukan REINDEX terhadap tabel ini, untuk membuat ulang index-indexnya.
    • Kemudian lakukan ANALYZE untuk melakukan pembuatan statistik untuk tabel dan indexnya.
    • Lakukan proses ini pada saat koneksi user sedikit, karena postgresql akan melakukan lock terhadap tabel secara keseluruhan. Untuk versi 9.0 keatas proses vacuum sangat cepat.
  • Apabila anda mendapati rasio > 10 lakukan dengan metode CTAS.
    • Untuk proses ini, pastikan jangan ada user atau applikasi yang terkoneksi ke database.
    • Proses ini akan melakukan membuat tabel baru dengan data yang telah terurut berdasarkan primary key atau unique indexnya.
    • Jangan lupa untuk melakukan ANALYZE di akhir proses untuk membuat statistik terhadap tabel dan indexnya.
  • Solusi yang lain adalah menggunakan extensi pg_reorg.
    • Solusi ini berbasis metode CTAS dan saya belum pernah mencobanya.

Demikian cara saya untuk melakukan defrag database PostgreSQL.

Bagaimana dengan anda ?

Postgresql : Mencari table bloated atau ter-fragmentasi

  Postgresql mempunya istilah untuk fragmentasi yaitu bloat. Bloat ini muncul terhadap dua object postgresql yaitu tabel dan index. Artikel ini akan menjelaskan bagaimana cara kita mencari tabel yang ter-fragmentasi. Apabila anda menemukannya, maka tabel tersebut harus di defrag.

Untuk mencari tabel dan index mana saja yang memiliki Bloat, kita dapat menggunakan script yang telah disediakan oleh postgreSQL yang dapat dilihat disini. Berikut saya copy paste dari halaman wiki PostgreSQL:

SELECT current_database(), schemaname, tablename,
       /*reltuples::bigint, relpages::bigint, otta,*/
       ROUND( CASE WHEN otta=0
                   THEN 0.0 ELSE sml.relpages/otta::numeric
                   END,1) AS tbloat,
       CASE WHEN relpages < otta THEN 0 
                ELSE bs*(sml.relpages-otta)::bigint END AS wastedbytes,
       iname, /*ituples::bigint, ipages::bigint, iotta,*/
       ROUND(CASE WHEN iotta=0 OR ipages=0 
                   THEN 0.0 ELSE ipages/iotta::numeric 
                   END,1) AS ibloat,
       CASE WHEN ipages < iotta THEN 0 
               ELSE bs*(ipages-iotta) END AS wastedibytes
FROM 
( SELECT schemaname, tablename, cc.reltuples, cc.relpages, bs,
             CEIL((cc.reltuples*((datahdr+ma- 
                    (CASE WHEN datahdr%ma=0 THEN ma 
                             ELSE datahdr%ma END))+nullhdr2+4)
                     )/(bs-20::float)) AS otta,
             COALESCE(c2.relname,'?') AS iname, 
             COALESCE(c2.reltuples,0) AS ituples, 
             COALESCE(c2.relpages,0) AS ipages,
             COALESCE(CEIL((c2.reltuples*(datahdr-12)
                           )/(bs-20::float)),0) AS iotta 
                           -- very rough approximation, assumes all cols
  FROM 
  (  SELECT ma,bs,schemaname,tablename,
               ( datawidth+(hdr+ma-
                 (case when hdr%ma=0 THEN ma ELSE hdr%ma END))
               )::numeric AS datahdr,
               ( maxfracsum*(nullhdr+ma-
                 (case when nullhdr%ma=0 THEN ma ELSE nullhdr%ma END))
               ) AS nullhdr2
    FROM 
    (  SELECT schemaname, tablename, hdr, ma, bs,
                  SUM((1-null_frac)*avg_width) AS datawidth,
                  MAX(null_frac) AS maxfracsum,
                  hdr+( SELECT 1+count(*)/8
                           FROM pg_stats s2
                           WHERE null_frac<>0 
                               AND s2.schemaname = s.schemaname 
                               AND s2.tablename = s.tablename
                  ) AS nullhdr
       FROM pg_stats s, 
       ( SELECT ( SELECT current_setting('block_size')::numeric) AS bs,
                    CASE WHEN substring(v,12,3) IN ('8.0','8.1','8.2') 
                    THEN 27 ELSE 23 
                    END AS hdr,
                    CASE WHEN v ~ 'mingw32' THEN 8 ELSE 4 END AS ma
         FROM ( SELECT version() AS v) AS foo
      ) AS constants
      GROUP BY 1,2,3,4,5
    ) AS foo
  ) AS rs
  JOIN pg_class cc ON cc.relname = rs.tablename
  JOIN pg_namespace nn
    ON ( cc.relnamespace = nn.oid 
            AND nn.nspname = rs.schemaname 
            AND nn.nspname <> 'information_schema' )
  LEFT JOIN pg_index i ON indrelid = cc.oid
  LEFT JOIN pg_class c2 ON c2.oid = i.indexrelid
) AS sml
ORDER BY wastedbytes DESC

Yang perlu diperhatikan dari skrip ini adalah :

  • Skrip ini diperuntukkan sebagai informasi penunjang, untuk memastikan keakuratannya harus di cek dengan modul contrib pgstattuple atau pg_freespacemap.
  • Kolom tbloat adalah rasio fragmentasi di table antara besarnya table dan free space yang dimilikinya.
  • Kolom wastedbytes adalah besarnya free space yang dimiliki tabel tersebut dalam satuan byte yang tidak dapat dipergunakan.
  • Kolom ibloat adalah rasio fragmentasi di index antara besarnya index dan free space yang dimilikinya
  • Kolom watedibytes adalah besarnya free space yang dimiliki index tersebut dalam satuan byte yang tidak dapat dipergunakan.

Apabila skrip ini dijalankan, maka akan kita dapati tabel dan index yang memiliki bloat. Perhatikan kolom kolom rasio-nya dan gabungkan dengan kolom wastebyte-nya. Perhatikan pola antar tabel. Rasio 1 pada tabel A, nilai wastebyte nya dapat berbeda dengan tabel B untuk rasio yang sama.

Lantas bagaimana menentukan mana tabel yang perlu di defrag ? Jawabannya adalah kenalilah karakteristik database anda.

Database saya memiliki beberapa tabel yang karakteristiknya berbeda. Ada tabel tabel yang sering kali memakai proses update secara perlahan lahan. Ada juga tabel yang lebih memakai metode proses delete-insert daripada update. Ada juga yang lebih banyak proses insertnya daripada proses updatenya. Ada juga tabel yang cepat sekali pertumbuhan datanya ada yang lambat.

Nah, bagaimana cara saya menentukan tabel yang perlu defrag adalah dengan membatasi ratio tbloat dan ibloat > 1.5 atau yang memiliki wastebyte > 3Mb. Dengan syarat seperti itu saya akan mendapati 5-6 tabel yang perlu di defrag setiap minggu nya. Saya tinggal melakukan defrag.

Bagaimana dengan anda ?

Instalasi Bucardo, master to master replikasi untuk database PostgreSQL

  Bucardo adalah software replikasi master to master untuk database Postgresql. Bucardo yang saya pergunakan adalah bucardo versi 5 beta, tepatnya versi 4.99.5 dan dapat di download dihalaman ini.  Sampai saat ini kecepatan replikasi yang dapat saya peroleh adalah > 200 record per detik untuk replikasi antar kota. Hasil ini dapat berbeda untuk jenis applikasi yang anda gunakan.

Konfigurasi yang saya miliki :

Berikut langkah langkah yang dilakukan untuk instalasi bucardo :

  • Backup database di server 1 dan extract di server 2, dengan ini maka kedua database tersebut memiliki struktur dan data yang identik.
  • Update package ubuntu dengan menambahkan beberapa package yang dibutuhkan

$> apt-get install make libdbi1 libdbi-perl libdbix-safe-perl libdbix-simple-perl libdbd-pg-perl libboolean-perl postgresql-contrib postgresql-plperl-9.1

  • Check nilai ulimit di kernel linux. Nilai ulimit ini akan di pergunakan untuk menentukan nilai parameter max_stack_depth di postgresql.

$> ulimit -s

8192

  • Berdasarkan infomasi diatas menghasilkan nilai 8192 Kb. Artinya saya dapat menaikan parameter max_stack_depth hingga 8M. Tetapi kita akan pakai setengahnya saja. Parameter max_stack_depth ini dipergunakan untuk memperbesar kemampuan query yang menggunakan klausa IN. Kemudian update file konfigurasi postgresqlnya.

$> vim /etc/postgresql/9.1/main/postgresql.conf

max_stack_depth = 4M

  • Install language plperlu di postgresql

$> psql -h 127.0.0.1 -U postgres
SQL> CREATE LANGUAGE PLPERLU;
SQL> CREATE LANGUAGE PLPGSQL;

  • Download Bucardo versi 5 Beta disini.
  • ekstrak file hasil download tersebut.
  • Kemudian lakukan kompilasi .

$> cd bucardo-4.99.5
$> perl Makefile.PL
$> make
$> sudo make install

  • Install Bucardo, dan ubah setting koneksinya seperti berikut

$> bucardo install

Current connection settings:
1. Host: 127.0.0.1
2. Port: 5432
3. User: postgres
4. Database: postgres
5. PID directory: /var/run/postgresql
Enter a number to change it, P to proceed, or Q to quit: P

$>

  • Check instalasi bucardo

$> bucardo –version

  • Tambahkan database ke bucardo

$> bucardo add db db1 dbname=mydatabase dbhost=192.16.0.1 dbuser=postgres dbpass=password
$> bucardo add db db2 dbname=mydatabase dbhost=192.16.0.2 dbuser=postgres dbpass=password

  • Daftarkan semua table dan sequence ke bucardo. Herd dapat dianalogikan sebagai kumpulan object database

$> bucardo add table all tables herd=db_herd
$> bucardo add sequence all sequences herd=db_herd

  • Daftarkan database yang ada didalam bucardo ke dalam database group

$> bucardo add dbgroup db_group db1:source db2:source

  • Sinkronisasi ke dua database tersebut untuk install triggernya dan start replikasi

$> bucardo add sync db_sync herd=db_herd dbs=db_group
$> bucardo start

  • Setelah start anda dapat melakukan testing insert, delete, update dari masing masing sisi server.
  • Perlu diingat yang di replikasikan adalah perintah DML yakni insert, update, delete.
  • Done.
Silahkan mencoba.

Apa itu PGPool-II ?

  PGPool II ini termasuk salah satu tools yang saya pergunakan di dalam arsitekture applikasi saya. Untuk performancenya, saya merasa cukup puas.  Berikut saya kutip penjelasan dari wikipedia mengenai pgpool-II ini.

PGPool-II ini adalah middleware yang bekerja diantara PostgreSQL server dan Applikasi Client. Dia memiliki kemampuan sebagai berikut :

  • Connection Pooling :
    • pgpool-II akan membuat sekumpulan koneksi ke database PostgreSQL dan tidak akan memutus / mematikan koneksi itu. Apabila applikasi anda ingin berhubungan dengan database PostgreSQL, harus melalui pgpool-II ini. Jumlah koneksi yang dibuat oleh pgpool dapat di tentukan jumlahnya, dan akan selalu tetap jumlahnya sampai pgpool-II di restart. Koneksi yang ada ini dapat dipergunakan berulang ulang pada semua koneksi client yang terhubung ke pgpool-II. Hal ini akan mengurangi pemakaian resource yang berlebih dari proses terciptanya koneksi yang berulang ulang dan meningkatkan beban data yang lewat di dalam sistem secara keseluruhan.
  • Replication :
    • pgpool-II dapat berperan sebagai alat untuk replikasi data memanfaatkan beberapa server PostgreSQL untuk menciptakan backup data secara realtime. Sehingga database akan selalu berfungsi jika terjadi kerusakan data.
  • Load Balance
    • Jika database ter-replikasi, perintah SELECT pada server manapun akan memiliki hasil yang sama. pgpool-II akan memanfaatkan kemampuan replikasinya untuk menguraki beban dari setiap server dengan cara menyebar perintah SELECT ke beberapa servernya, hal ini akan meningkatkan kemampuan sistem.  Load Balancing ini akan berfungsi dengan baik apabila terdapat banyak user yang mengeksekusi perintah sql secara bersamaan.
  • Limiting Exceeding Connections :
    • Ada pembatasan dalam membuat jumlah maksimal kumpulan koneksi ke database PostgreSQL.  Meningkatkan jumlah maksimal koneksi ini akan berbanding lurus dengan besarnya pemakaian resource dan berpengaruh terhadap kemampuan sistem. Apabila jumlah koneksi yang ada telah dipergunakan semuanya, maka koneksi baru yang ada akan masuk dalam daftar antrian.
  • Parallel Query :
    • Fasilitas ini akan memecah perintah SELECT agar dapat di eksekusi ke semua server replikasi sehingga akan mempercepat waktu pemrosesan data. Parallel Query ini baik untuk mencari data dalam skala besar.
Itu adalah kemampuan yang dimiliki oleh pgpool-II. Saya sendiri belum bisa memanfaatkan semuanya. Saat ini hanya Connection-Pooling saja yang dapat saya pergunakan. Untuk yang lainnya masih belum.
Bagaimana dengan anda ?
Enhanced by Zemanta