IMPLEMENTASI MIRRORING DATABASE UNTUK FAULT
TOLERANCE PADA POSTGRESQL SERVER MENGGUNAKAN
METODE LOGGING
Moh Kohari 1, Wahyu Suadi,S.Kom,M.Kom2 Mahasiswa Jurusan Teknik Informatika 1 , Dosen Pembimbing 2Jurusan Teknik Informatika, Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember
Email : brancs_vill@yahoo.com
Abstrak
Database merupakan aspek yang sangat penting dalam teknologi informasi. Ini dikarenakan database berfungsi sebagai media penyimpanan data. Di dalam sistem database, kemungkinan terjadinya kegagalan sistem dan hardware selalu ada. Semuanya itu bisa disebabkan karena beberapa hal diantaranya disk crash, power outage, software error, dan human error. Kegagalan sistem ini akan mengakibatkan aliran transaksi ke database terganggu dan bisa berakibat hilangnya data.
Untuk mengatasi masalah tersebut diperlukan sistem backup database. Suatu sistem yang bertujuan menjaga agar transaksi ke database tetap berjalan dan data yang tersimpan tidak hilang meskipun sistem utama mengalami gangguan atau down. Sistem backup ini dinamakan penggandaan (mirroring) database. Dalam tugas akhir ini akan diimplementasikan
mirroring database dengan menggunakan
metode logging sebagai tempat penyimpan data sementara saat terjadi gangguan sistem. Adapun data yang disimpan berupa insert, update, delete. Hasil uji coba menunjukkan bahwa transaksi ke database tetap berjalan meskipun server utama mengalami gangguan sistem (down) dan sistem bisa mengatur proses transaksi ke semua server yang masih aktif.
Kata kunci: kegagalan sistem, disk
crash,power outage,software error,human
error,sistem backup, mirroring database.
1. PENDAHULUAN
Database merupakan aspek yang sangat penting dalam teknologi informasi. Aplikasi yang mendukung sistem besar perlu didukung oleh database server yang handal, berkinerja tinggi, serta mudah perawatan dan pengembangan[1]. Adapun fungsinya adalah sebagai media penyimpanan data yang memungkian pengguna untuk mengolah kembali data yang dimilikinya.
Di dalam sistem database, kemungkinan terjadinya kegagalan sistem dan hardware selalu ada. Kegagalan sistem ini bisa disebabkan oleh beberapa hal: disk crash, power outage, software error, dan human error. Sebelum terjadi permasalahan ini yang bisa mempengaruhi sistem database maka diperlukan sistem backup database. Tujuannya adalah untuk menjamin proses transaksi kedatabase bisa tetap berjalan dan data yang tersimpan tidak hilang meskipun primari sistem sedang mengalami gangguan. Untuk mengatasi kegagalan sistem yang berakibat bisa hilangnya data maka diperlukan suatu tindakan preventif yaitu membuat penggadaan (mirroring) database. Mirroring ini berguna untuk menjaga agar data yang tersimpan tidak hilang atau rusak pada saat terjadi gangguan pada database server. Dengan adanya mirroring ini juga akan memudahkan para pengguna dalam melakukan perubahan-perubahan terhadap data karena tidak perlu lagi mengkopikan data secara manual. Untuk merelasasikan ini semua dibutuhkan sebuah aplikasi yang bisa menghubungkan antara aplikasi dan database. Teknologi middleware adalah salah satu solusinya. Middleware adalah software yg dikembangkan untuk menyambung komponen atau aplikasi lainnya guna mendukung operasional aplikasi dalam lingkungan jaringan terdistribusi.
Oleh karena itu dalam tugas akhir ini akan dibuat aplikasi mirroring database yang menggunakan metode logging dengan memanfaatkan teknologi middleware berbasiskan web service Adapun fungsi Middleware disini adalah sebagai jembatan atau penghubung komunikasi antar database.
2. TUJUAN PEMBUATAN TUGAS
AKHIR
Tujuan dari pembuatan tugas akhir ini adalah membangun sebuah aplikasi yang bisa menggandakan data dan menggantikan salah satu database server down atau mengalami gangguan sistem.
3. DESKRIPSI SISTEM
Aplikasi yang dibangun adalah sebuah aplikasi yang berfungsi untuk menyambungkan komponen atau aplikasi guna mendukung operasional aplikasi dalam lingkungan yang melibatkan hubungan antara klien dan server dalam sebuah jaringan ( Middleware ). Ini dimungkinkan bagi pengguna untuk melakukan perubahan data pada database yang dilakukan secara bersamaan pada seluruh server database yang tersedia. Jadi dengan adanya aplikasi ini pengguna tidak perlu lagi melakukan perubahan data secara manual pada setiap database server yang tersedia, karena setiap kita melakukan operasi INSERT, UPDATE, DELETE maka secara otomatis proses tersebut dilakukan ke seluruh database server secara bersama.
Jadi ketika aplikasi (Middleware) berjalan dan pengguna ingin mengakses data pada database
dengan menggunakan operasi
INSERT,UPDATE,DELETE pengguna akan melakukan koneksi kesemua database server yang tersedia sehingga operasi tersebut dilakukan secara bersamaan di semua database server yang terhubung. Ketika terjadi salah satu database server down, middleware akan menghubungkan ke database server yang aktif untuk menjalankan transaksi. Transaksi ini juga akan diteruskan pada database server yang down hanya saja dicatat dalam log. Log inilah yang mencatat semua transaksi pada saat ada gangguan sistem. Sehingga database server yang down tetap mendapatkan data yang terbaru.
Pada aplikasi ini, database server yang berperan penting adalah database pertama yang didaftarkan. Karena semua operasi akan mengakses kedatabase ini. Sedangkan database server lainnya hanya berfungsi sebagai database slave atau cadangan. Meskipun sebagai slave, datanya tetap sama dengan dengan data yang ada dimaster. Sehingga apabila database master itu mati maka operasi tetap berjalan dengan menggunakan database slave dan tentunya database master tetap mendapatkan data yang terbaru dari pembacaan log ketika hidup kembali.
Gambar 1 Desain Model Sistem
4. MIDDLEWARE
Dalam aplikasi ini Middleware yang dibangun adalah middleware yang berbasiskan Web Service. Karena Web-service dapat dibangun dengan menggunakan bahasa pemrograman apa saja dan juga dapat diimplementasikan pada platform manapun. Sehingga akan memudahkan para pengembang untuk mengembangkan aplikasi ini.
Di dalam middleware ini akan disediakan fungsi DbConnection dan beberapa method yang dibutuhkan oleh client yaitu getListByFilter, getInsert, getUpdate, getDelete. DbConnection ini berfungsi sebagai koneksi kedatabase server. Method getListByFilter berfungsi menampilkan data yang diminta. Sedangkan method getInsert, getUpdate dan getDelete berfungsi sebagai mengupdate data dalam database jika ada perubahan dari user. Di middleware juga ada proses pembuatan LOG. LOG ini berfungsi untuk menyimpan sementara perintah data yang masuk ketika ada gangguan sistem. Jadi peran dari LOG ini adalah sangat penting karena dengan adanya LOG database server down akan tetap mendapatkan update data terbaru.
Proses pembuatan LOG itu sendiri terjadi pada saat salah satu database server down. Ketika ada proses transaksi masuk, oleh middleware transaksi akan diproses dan diteruskan keseluruh database server tak terkecuali yang down. Khusus untuk database server yang down, middleware akan secara default membuat LOG dan transaksi yang masuk akan tersimpan dalam LOG tersebut. LOG ini akan secara default tersimpan dalam aplikasi server khususnya dalam folder webserver (Glassfish). LOG akan di hapus oleh sistem middleware ketika sudah terbaca atau diexecute pada saat database yang down hidup kembali.
Gambar 2 Proses Middleware
4.1 MEKANISME MIDDLEWARE
Didalam mekanisme ini akan dijelaskan mengenai alur kerja dari sistem middleware. Bagaimana sistem ini akan menangani jika ada gangguan sistem atau down pada salah satu database server, bagaimana semua database tetap mendapatkan update data meskipun dalam keadaan ada gangguan sistem . Untuk lebih jelasnya lihat gambar dibawah ini :
Gambar 3 Mekanisme Middleware Keterangan:
− Inputan : Masukan berupa query
− Middleware : Sistem yang mengatur terhubungnya antara aplikasi dengan database server.
− Log : Tempat penyimpan data sementara berupa query yang tercipta secara default pada saat tejadi gangguan sistem.
− DB : Database server
yang berfungsi sebagai tempat penyimpanan data.
Didalam sistem middleware ini database server harus sudah didaftarkan. Database server yang terdaftar pertama merupakan database server master sedangkan yang lain merupakan database server yang berfungsi sebagai slave. Pada saat aplikasi ini dijalankan middleware akan secara langsung menghubungkan ke database server yang sudah didaftarkan. Database server yang berada pada urutan pertama yang akan diakses secara langsung sedangkan yang lain sebagai cadangan (mirror) dengan tetap mendapatkan data yang sama.
Proses saat terjadi gangguan system sebagai berikut :
a. Database server pertama down
Gambar 4 Proses Server Pertama Down Saat terjadi database server pertama down, middleware akan langsung menghubungkan dengan database server kedua untuk diakses secara langsung dalam hal ini adalah DB2. Proses transaksi akan tetap diteruskan keseluruh database tak terkecuali yang down. Untuk yang down proses transaksi akan disimpan dalam log1 dan akan dibaca pada saat database itu up kembali dan fungsinys sebagai database master akan kembali sedangkan database kedua yang semula sebagai database master berubah jadi database slave.
b. Database server kedua down
Saat terjadi database server kedua down, middleware akan tetap menghubungkan dengan database server pertama dalam hal ini DB1. Ini yang membedakan dengan yang pertama. Proses transaksi akan tetap diteruskan keseluruh database tak terkecuali yang down. Untuk yang down proses transaksi akan disimpan dalam log2 dan akan dibaca pada saat database itu up kembali. Sehingga data pada semua server akan sama.
c. Database server pertama dan kedua down
Gambar 6 Proses Server Pertama dan Kedua Down
Saat terjadi database server pertama dan kedua down, middleware akan mencari database yang aktif dalam hal ini adalah database ketiga (DB3) yang sekaligus nanti berfungsi database master. Proses transaksi akan tetap berjalan dengan database ketiga sebagai server master dan untuk server yang down proses transaksi akan disimpan dalam log1 dan log2. Ketika database server pertama dan kedua up kembali log1 dan log2 akan dibaca dan fungsi sebagai database master akan kembali ke database pertama sedangkan database ketiga berubah jadi database slave. 5. UJI COBA DAN EVALUASI
Uji coba ini dilakukan dengan menggunakan tiga database server. Adapun cara kerja dari aplikasi adalah pada saat client melakukan proses insert, update, delete maka oleh sistem middleware proses itu akan ditujukan ke semua database server tak terkecuali yang mengalami gangguan sistem. Aplikasi ini akan tetap berjalan meskipun database server pertama (master) mengalami gangguan sistem. Pada database server yang mengalami gangguan system, proses itu akan dimasukkan ke dalam log yang sudah terbuat secara default. Log ini akan dibaca pada saat server yang down, up kembali kemudian log ini akan terhapus.
Terdapat beberapa skenario dalam melakukan uji coba ini diantaranya adalah mematikan database server pertama, kedua, pertama dan kedua. 5.1 Skenario I
Pada skenario pertama adalah mematikan database server pertama. Berdasarkan langkah-langkah dalam diagram alir gambar 2, apabila ada gangguan sistem maka middleware akan mengecek koneksi kesemua database server, jika ada salah satu database server yang down maka akan membuat log. Log ini akan tersimpan dalam folder webserver (glassfish) itu berada dengan nama sesuai database server misal DB1.sql. Untuk lebih jelasnya bisa melihat gambar dibawah ini.
Keadaan ketika semua database server masih hidup dan ada inputan dari client maka semua database server akan terisi inputan tersebut.
Gambar 7 Input pertama kali
Pada gambar 7 adalah proses insert data baru dengan kode a1. Proses insert ini akan diteruskan kesemua server sehingga nantinya semua server akan terisi data baru. Seperti yang terlihat pada gambar 8 sampai 10.
Gambar 8 Database Server Pertama (Input I)
Gambar 10 Database Server Ketiga (Input I) Tampak terlihat pada gambar 8 sampai 10 yang semula belum ada datanya sekarang ada penambahan data di database server pertama,kedua dan ketiga dengan kode a1. Penambahan data ini karena ada proses insert baru, dan oleh middleware proses ini diteruskan kesemua database server.
Keadaan ketika database server pertama down dan ada inputan dari client.
Gambar 11 Input ke-2
Gambar diatas adalah pada saat user memasukkan dua data yaitu kode a2 dan kode a3. Data ini akan masuk ke database kedua dan ketiga sedangkan database pertama data belum masuk karena tersimpan dalam log terlebih dahulu. Data yang ditampilkan diatas adalah data
pada database server kedua
(\\192.168.0.134:5434\MyBase2) karena
sekarang berfungsi sebagai master. Pada saat proses insert ini masuk sedangkan database server master down maka akan tercipta sebuah log dengan nama DB1.sql dengan isi proses insert tadi.
Gambar 12 Folder Log DB1
Gambar 13 Isi Log DB1.sql
Pada gambar 13 adalah tampilan isi dari log DB1.sql. Tampak terlihat ada dua proses insert. Log ini akan dibaca setelah server pertama up kembali.
Gambar 14 Database Server Pertama (Input II)
Gambar 14 diatas ketika server pertama down dan data inputan kedua belum masuk.
Gambar 15 Database Server Kedua (Input II)
Gambar 16 Database Server Ketiga (Input II) Gambar 15 dan 16 diatas menunjukkan bahwa dua data telah masuk kedatabase server kedua
(\\192.168.0.134:5434\myBase2) dan ketiga
(\\192.168.132.130:5435\myBase2) secara
langsung setelah transaksi masuk dari client.
Gambar 17 Database Server Pertama (Input II)
Setelah database Server utama up kembali maka data yang ada di log akan terbaca dan dieksekusi.
Kemudian setelah log dieksekusi, log itu akan di hapus.
Gambar diatas adalah data yang sudah masuk
kedatabase server pertama
(\\localhost:5432\cobaDB) setelah proses
pembacaan log. Fungsi sebagai database master akan kembali kedatabase pertama sedangkan database kedua menjadi slave.
5.2 Skenario II
Pada skenario kedua adalah mematikan database server kedua.
Gambar 18 Input ke-3 (Insert dan Edit)
Gambar diatas adalah proses insert dan edit pada saat database kedua down. Proses ini akan diteruskan ke database pertama dan ketiga sedangkan ke database kedua belum masuk karena proses ini masih disimpan dalam log DB2.sql. Data yang diperlihatkan adalah data yang ada di database server pertama (master).
Gambar 19 Folder Log DB2.sql
Gambar 20 isi Log DB2.sql
Gambar di atas merupakan isi dari log DB2.sql yang berisi data yang di inputkan pada saat database server kedua mati. Tampak terlihat query insert dan update. Isi di log DB2.sql ini akan dibaca pada saat database server kedua up kembali.
Gambar 21 Database server kedua (Input III) Dalam gambar diatas proses insert dan edit belum masuk kedatabase server kedua (\\192.168.0.134:5434\myBase2) karena proses di log DB2.sql belum dibaca
Gambar 22 Database Server Pertama (InputIII)
Gambar 23 Database Server Ketiga (Input III)
Tampak terlihat pada gambar 22 dan 23 ada perubahan data pada database server pertama
(\\localhost:5432\cobaDB) dan ketiga
(\\192.168.132.130:5435\myBase2) yaitu pada
baris ketiga nama topan berubah menjadi topan hasan dan penambahan data pada baris keempat dengan kode a4. Perubahan ini secara langsung pada saat client melakukan proses transaksi baru.
Gambar 24 Database Server Kedua (Input III)
Pada gambar 24 terlihat database server kedua (\\192.168.0.134:5434\myBase2) ada perubahan isi data yaitu data baru pada baris keempat dan edit data pada baris ketiga. Perubahan ini terjadi setelah ada pembacaan log DB2.sql saat server kedua up kembali.
5.3 Skenario III
Pada skenario ketiga adalah mematikan database server pertama dan kedua.
Gambar 25 Input ke-4
Gambar diatas adalah proses insert pada saat database server pertama dan kedua down. Proses ini akan diteruskan pada server ketiga yaitu pada alamat \\192.168.132.130:5435\myBase2. Data yang ditampilkan adalah data yang ada di server ketiga karena server ketiga ini berubah fungsi menjadi server master. Data akan bertambah pada server ketiga ini dengan kode b1. Saat proses ini berlangsung, data juga akan masuk pada server pertama dan kedua hanya saja dicatat dalam log bukan dicatat dalam server yaitu dengan nama DB1.sql dan DB2.sql. Log ini akan tersimpan dalam folder glassfish seperti yang terlihat dibawah ini.
Gambar 26 Folder Log DB1.sql Dan DB2.sql
Gambar 27 Isi Log DB1.sql
Gambar 28 Isi Log DB2.sql
Gambar 27 dan 28 adalah tampilan isi dari log DB1.sql dan DB2.sql. Tampak terlihat ada proses insert data. Log ini nantinya akan masuk ke server pertama dan ketiga pada saat server itu up kembali.
Gambar 29 Database Server Ketiga (Input IV)
Tampak terlihat pada gambar 29 yaitu server ketiga (\\192.168.132.130:5435\myBase2) ada tambahan data baru dengan kode b1. Data ini masuk secara langsung ketika ada proses insert berlangsung .
Gambar 30 Database Server Pertama (InputIV)
Gambar 31 Database Server Kedua (Input IV)
Pada gambar 30 server pertama (\\localhost:5432\cobaDB) dan gambar 31 server
kedua (\\192.168.0.134:5434\myBase2) terjadi perubahan data yaitu ada data baru dengan kode b1. Perubahan ini terjadi karena terjadi pembacaan log DB1.sql dan DB2.sql saat database server itu up kembali.
5.4 Evaluasi
Dari percobaan diatas didapatkan bahwa : N o Input Server (1,2,3) Hasil yang diharapkan Ha sil 1. Insert, update, delete 1,2, & 3 up Data masuk ke semua server OK 2. Insert, update, delete 1 down 2 up 3 up 1.Data masuk ke server kedua dan ketiga. 2.Kecuali server yang down data akan masuk ke log . Setelah server up kembali data di log itu akan dibaca dan kemudian log akan dihapus 3.Data yang ditampilkan diclient adalah data di server kedua 4.Ketika server pertama up kembali, server kedua menjadi slave OK 3. Insert, update, delete 1 up 2.down 3 up 1.Data yang ditampilkan adalah data di server pertama 2.Membuat log DB2.sql 3.Membaca Log 4.server dua dan tiga tetap jadi slave OK 4. Insert, update, delete 1.down 2.down 3 up 1.Data yang ditampilkan adalah data diserver ketiga 2.Membuat log DB1.sql dan DB2.sql 3.Membaca log OK 4.ketika server pertama dan kedua up, server pertama jadi master, server kedua dan ketiga jadi slave Tabel 1 Evaluasi Uji Coba 6. KESIMPULAN
Setelah dilakukan uji coba dan analisis hasil terhadap aplikasi yang telah dibuat maka dapat diambil kesimpulan sebagai berikut:
a. Middleware yang dibangun sudah mampu mengaplikasikan proses select, insert, update dan delete.
b. Ujicoba menunjukkan aplikasi bisa berjalan meskipun server utama mengalami gangguan sistem (down) dan middleware bisa mengatur proses transaksi ke semua server yang masih aktif.
c. Ujicoba menunjukkan bahwa sistem mampu kembali ke sistem awal setelah server utama bisa up kembali.
7. DAFTAR PUSTAKA
[1] Sugiana Owo, SQL dengan Postgres, 2001 [2] Somantri, Maman, Pemrograman Lintas
Bahasa Pemrograman dalam Arsitektur
CORBA, Prosiding Seminar Nasional
Teknologi Informasi, STTNAS Yogyakarta, Juni 2005.
[3] http://lecturer.ukdw.ac.id/budsus
[4] Microsoft Corp. (2000) Application Service Provider: Evolution and Resources, White Paper, USA.
[5] Kreger, H. (2001) Web-services Conceptual
Architecture (WSCA 1.0), IBM
Software Group, USA.
[6] Manes, A.T. (2001) Introduction toWeb-services, http://www.systinet.com.
[7] Hamids (2000) Introduction toWeb-services, http://www.MCPCentral.com. [8] Microsoft Corp. (2001) Microsoft .net
Framework, USA.
[9] Meiyanto, M.E. (2001) Extensible Markup Language (XML) untuk Pertukaran Data di Internet, Skripsi, Yogyakarta.
[10] Walsh, N. (1998) A Technical Introduction to XML, ArborText, Inc. [11] Tidwell, D.(1999) Tutorial:Introduction to XML,Raleigh. NC. [12] Scheinbum, J. (2001) An Introduction to SOAP, http://www.zdnetindia.com/Techzone/codin g/stories/29727.html
[13] Microsoft Corp. (2001) Microsoft .net Framework, USA.
[14] Ariba, IBM, Microsoft (2000) UDDI
Technical White Paper,
http://www.uddi.org. [15]
httpcode86.wordpress.com20091220middle w
are-osgi-ami-c-jcp
[16] Kogan Tamara : Web Service Tutorial.pdf [17] Dubuis Eric. 2008. JAX-WS Java Api for
XML-Based Web Service.
[18] Widapratama, Andy. 2008.Pengembangan Mirroring Untuk Fault Toleran Pada Mysql Server Menggunakan Metode Pengkopian Stream, [Tugas Akhir], Institut Teknologi Sepuluh Nopember Surabaya.
