HASIL DAN PEMBAHASAN
4.1. Parameter Replikasi Database pada Simulasi
Ada tiga parameter yang menjadi penilaian dalam mereplikasi data (Wiesman et al : 2000). Ketiga parameter terdapat pada simulasi yang dilakukan agar replikasi yang terjadi baik. Parameter tersebut adalah arsitektur server, interaksi server dan terminasi transaksi. Ketiga parameter tersebut dapat dijelaskan pada gambar 4.1 di bawah ini:
o
gfile Log file
Realtime log Realtime log
Primary Database Standby Database
Gambar 4.1. Arsitektur server pada simulasi
1. Arsitektur Server
Ada dua teknik yang harus dipertimbangkan dalam membangun arsitektur server. Pertama adalah replikasiprimary copy, yaitu teknik yang membangun server dengan membuat situs-situs yang spesifik yang terkait dengan setiap item data. Dan kedua
26
adalahupdate everywhere, yaitu memungkinkan meng-update sebuah item data yang akan dilakukan di mana saja di dalam sistem. Artinya,updatesecara bersamaan dapat tiba di dua salinan yang berbeda dari item data yang sama (yang tidak dapat terjadi denganprimary copy). Karena properti ini, di mana-mana memperbaharui pendekatan yang lebih baik ketika berhadapan dengan kegagalan karena tidak ada protokol pemilihan yang diperlukan untuk melanjutkan proses. Pada simulasi ini penulis menggunakan teknikprimary copy, yaitu dengan membangun serverstandby database yang mutlak sama dengan primary database. Data yang masuk ke primary database akan tereplikasi ke dalam tabelstandby database yang susunan tabel tersebut mutlak sama.
2. Interaksi Server
Parameter kedua yang perlu dipertimbangkan melibatkan tingkat komunikasi antara serverdatabaseselama eksekusi transaksi. Ini menentukan jumlah lalu lintas jaringan yang dihasilkan oleh algoritma replikasi dan overhead pada proses transaksi data. Parameter ini mempertimbangkan dua kasus :
a. Interaksi terus-menerus (konstan), yang sesuai dengan teknik di mana sejumlah data digunakan untuk mensinkronkan server untuk transaksi tertentu, terlepas dari jumlah operasi dalam transaksi. Biasanya, protokol dalam kategori ini bertukar pesan tunggal per transaksi dengan mengelompokkan semua operasi dari transaksi dalam satu pesan.
b. Interaksi linier, yang biasanya berkaitan dengan teknik di mana sebuahdatabase server merambat setiap operasi transaksi pada basis per operasi. Operasi dapat dikirim baik sebagai pernyataan SQL atau sebagai catatan log yang berisi hasil setelah dieksekusi operasi di server tertentu.
Berdasarkan simulasi yang telah dilakukan, parameter interaksi server yang terjadi adalah interaksi linear. Standby database akan melakukan perubahan data apabila admin melakukan traksaksi data terhadap primary database. Dan ini terjadi secara per operasi. Setelah transaksi selesai, real time loggingdi aplikasiprimary database akan memberikan status bahwa replikasi berhasil dilakukan dengan mencantumkan tanggal dan jam terjadinya replikasi serta alamat server standby database (tujuan replikasi).
27
3. Terminasi Transaksi
Replikasi yang baik adalah replikasi yang memiliki akhir di dalam prosesnya (terminasi). Simulasi yang penulis lakukan juga memenuhi parameter ini. Karena replikasi yang terjadi bersifat per operasi, maka setiap data yang telah tereplikasi di dalam standby database akan berhenti setelah tabel log pada primary database
berstatus “logging”. Dan akan kembali melakukan replikasi apabila admin kembali melakukan transaksi data terhadap primary database. Dari beberapa analisis di atas dapat ditarik kesimpulan bahwa simulasi ini berjalan sesuai dengan parameter replikasi database. Karena semua parameter telah terpenuhi. Sehingga dapat disimpulkan bahwa replikasi standby database dengan metode incremental backup adalah replikasi yang baik.
4.2. Simulasi
Penelitian pada simulasi ini dilakukan di laboraturium dengan menggunakan jaringan LAN yang terisolasi dan melakukan penelitian terhadap tiga skenario. Tujuan simulasi ini dilakukan untuk mengumpulkan data yang diperlukan, yaitu mengetahui proses replikasi (logging) yang terjadi antaraprimary database danstandby database, proses aktifnya failover untuk membuat standby database menjadi primary database yang baru karena primary database yang sebelumnya mengalami kerusakan (failure), serta menghitung jumlah waktu respon dan troughput yang dihasilkan pada saat primary database mengirimkan archived log ke standby database dan jumlah waktu respon serta throughput yang terjadi pada saat standby database yang baru melakukan replikasi terhadapprimary database yang baru.
Ada dua buah aplikasi yang dilakukan pada simulasi. Dibuatkan aplikasi untuk prosesstandby databasekarena DBMS MySQL tidak memiliki fiturstandby database secara default. Aplikasi yang dibuat pertama untuk pengujian adalah aplikasi pergudangan yang berfungsi untuk meng-input, edit ataupun men-delete data dari sebuah PC klien (admin). Aplikasi yang kedua adalah aplikasi yang berada pada primary database yang berfungsi untuk menghubungkan server primary database dengan server standby database. Pada aplikasi ini juga menjadi tempat archived log mengumpulkan log file pada primary database sebelum mengirimkannya ke server standby database. Pengaturan IP Address untuk ketiga jaringan yang akan menjadi alat simulasi digunakannetworkyang satusubnet seperti pada tabel 4.1.
28
Tabel 4.1. Pengaturan IP address
Server Network IP Server IP-Range
Primary Database 192.168.10.0/24 192.168.10.1 192.168.10.1– 192.168.10.254 Standby Database 192.168.10.0/24 192.168.10.4 192.168.10.1– 192.168.10.254 Klien (admin) 192.168.10.0/24 192.168.10.7 192.168.10.1– 192.168.10.254
4.1.1. Skenario I, Primary Database dan Standby Database berada dalam keadaan normal
Langkah awal pada simulasi skenario I adalah membangun sebuah klien yang terhubung pada serverprimary databasedan serverstandby databasesecara terisolasi. Pada simulasi ini penulis akan memberikan Internet Protocol Address Static kepada klien, server primary database dan juga server standby database yang semuanya berada pada kelas C. Berikut adalah gambaran kerja pada simulasi I:
1) Konfigurasi IP serverprimary databasepada klien.
Aplikasi pergudangan yang berada pada komputer klien berfungsi untuk melakukan transaksi data pada gudang supermarket seperti input, edit maupun delete. Aplikasi pergudangan tersebut mendaftarkan alamat IP tujuan yaitu server primary database. Hal ini dilakukan agar data yang di-input,edit maupun delete akan diarahkan kepada server primary database sehingga data tersebut akan tersimpan di dalam primary database. Seperti yang terlihat pada gambar 4.2 di bawah ini:
29
2) Konfigurasi IP pada server primary database dengan menggunakan aplikasi MasterStandby Database.
Setelah berhasil mengkonfigurasi IP pada aplikasi pergudangan, maka konfigurasi IP selanjutnya pada aplikasi Master yang terdapat pada server primary database. IP yang dimasukkan pada aplikasi Master adalah IP yang dimiliki oleh server primary database. Dengan demikian log file data yang dikirimkan oleh admin akan masuk ke dalam aplikasi master yang ada pada primary database. Berikut adalah konfigurasi IP pada aplikasi master yang dapat dilihat pada gambar 4.3.
Gambar 4.3. Melakukan konfigurasiIP addresspada aplikasi master
3) Daftarkan IP serverstandby databasepada aplikasi Master.
Pada langkah ini daftarkan IP server standby databaseyang akan menjadi tujuan replikasi dari serverprimary databasepada saat data di-input olehadminbarang. Gambar 4.4 akan menjelaskan tentang daftar IPstandby database.
Gambar 4.4. MendaftarkanIP server standby databasepada aplikasi master
4) Jalankanreal time loggingpada aplikasi master.
Tabel real time logging ialah tabel yang penulis buat untuk menjadi sebuah archived logyang digunakan untuk menyimpanredo log filesementara yang pada
30
akhirnya akan dikirimkan ke server standby database. Tabel ini dibuat karena MySQL tidak memiliki fitur archived log secara default. Jika tabel real time loggingini tidak diaktifkan atau berada pada modus stop, makaredo log filepada primary database tidak akan terkirim ke server standby database. Sehingga mengakibatkan archived log file akan menyimpan banyak file redo log. Berikut adalah proses mengaktifkan real time logging seperti pada gambar 4.5 di bawah ini:
Gambar 4.5. Mengaktifkanreal time logging
5) Input data pada aplikasi klien.
Berikut adalah contoh seorangadminmemasukkan data barang ke dalam aplikasi pergudangan yang akan di simpan di dalam primary database. Untuk lebih jelasnya dapat dilihat pada gambar 4.6.
31
6) Memeriksa data padaprimary databasedanstandby database.
Terlihat bahwa jumlah data yang ada pada primary database dan standby databaseadalah sama.
Gambar 4.7. (a) Data padaprimary database, (b) Data padastandby database
7) Memeriksa tabelreal time logging(archived log) pada aplikasi master.
Berikut adalah gambar 4.8. tabel real time logging yang merupakan kumpulan dari beberapa fileredo log:
Gambar 4.8. Tabellogging
Dari tabel logging dapat dilihat bahwa proses replikasi yang terjadi dari server primary database menuju server standby database berjalan secara real time. Karena data yang di-input oleh admindari komputer klien yang masuk ke server primary databasejuga langsung ter-inputdi dalam serverstandby database. Pada sistem standby database yang telah dibangun, proses replikasi terjadi secara increment. Maka setiap data yang masuk ke serverprimary databaseakan berlanjut ke server standby database secara real time. Berbeda halnya replikasi yang dilakukan secarafull backupyang melakukan replikasi secara periodik. Setiap data memilikilog yang apabila telah sampai di serverprimary database,log tersebut akan tersimpan di dalam tabel log (archived log). Tabel log adalah sebagai tempat catatan setiap
32
transaksi yang terjadi. Tabel log juga akan mencatat setiap data yang berhasil di replikasi oleh standby database. Berikut adalah proses replikasi yang terjadi secara incremental backupyang dijelaskan pada gambar 4.9.
Gambar 4.9. Skema replikasi pada sistem yang dibangun
Standby database adalah database cadangan yang selalu mereplikasi data setiap admin melakukan transaksi data pada primary database. Standby database dipersiapkan untuk menggantikanprimary databaseyang mengalami kerusakan. Oleh karena itu semua tabel yang ada pada primary database mutlak harus dimiliki juga oleh standby database. Tabel 4.2 dan 4.3 adalah contoh dari tabel yang ada pada primary database, tabellogdanstandby database.
Tabel 4.2. Contoh data barang yang terdapat di dalamprimary database
Tabel 4.3. Contoh data barang yang terdapat di dalamstandby database ID Kode
Barang Nama Barang Harga 1665 A-001 Dancow Balita 150gr 9750 1666 A-002 SGM 0-6 Bln 11200 1667 A-003 Lactogen Pbio 1 180gr 16700 1668 A-004 Lactogen Pbio 2 180gr 16700 ID Kode
Barang Nama Barang Harga 1665 A-001 Dancow Balita 150gr 9750 1666 A-002 SGM 0-6 Bln 11200 1667 A-003 Lactogen Pbio 1 180gr 16700 1668 A-004 Lactogen Pbio 2 180gr 16700
33
Proses replikasi akan dijelaskan pada gambar 4.10. untuk menandakan replikasi data yang dilakukan secara incremental penulis akan memberikan warna yang berbeda pada setiap proses yang terjadi.
TabelPrimary Database TabelStandby Database
Gambar 4.10. Proses replikasistandby databasesecaraincremental backup
Keterangan:
Proses 1.1. dan 2.1. : Data yang telah masuk ke primary database akan membentuk sebuahlog fileyang berisikan keterangan tambahan pada data. Proses 1.2. dan 2.2. : Setelah membentuk log file data akan tereplikasi secara real
timekestandby database.
Proses 1.3. dan 2.3. : Data yang telah berhasil tereplikasi akan mengirimkan status “logged” pada tabellogyang berada padaprimary database. Replikasi yang pertama kali dilakukan adalah data yang pertama sekali di-input oleh admindan masuk keprimary databaseyaitu Dancow Balita 150gr. Setelah melakukan proses 1.1, 1.2 dan 1.3 data Dancow Balita 150 gr telah tersimpan di dalam standby database. Setelah ituadminmeng-inputdata kembali dengan nama SGM 0-6 Bln dan proses 2.1, 2.2 dan 2.3 akan berjalan. Demikian juga proses input, edit dan delete selanjutnya. Setiap primary database mengalami penambahan ataupun perubahan, standby database akan mereplikasi penambahan ataupun perubahan data tersebut secarareal time.
ID Kode
Barang Nama Barang Harga 1665
A-001 Dancow Balita
150gr 9750
1666 A-002 SGM 0-6 Bln 11200 1667 A-003 Lactogen Pbio
1 180gr 16700 1668 A-004 Lactogen Pbio
2 180gr 16700
ID Kode
Barang Nama Barang Harga 1665 A-001 Dancow Balita
150gr 9750
1666 A-002 SGM 0-6 Bln 11200 1667 A-003 Lactogen Pbio 1
180gr 16700
1668 A-004 Lactogen Pbio 2
180gr 16700
Id_log Tanggal Query Status
1 15-11-2013 insert logged 2 15-11-2013 insert logged 3 16-11-2013 insert logged 4 17-11-2013 insert unlogged Proses 2.2. Proses 2.1. Proses 2.3. Proses 1.3. Proses 1.2. Proses 1.1. Tabel Log
34
Setiap data yang di-input oleh admin akan masuk ke primary database. Pada gambar 4.10 contohnya adalah data dengan kode A-001, nama barang Dancow Balita 150gr dengan harga 9750. A-001 memiliki keterangan tambahan seperti di-input pada tanggal 15-11-2013 dengan status unlogged yang disimpan di dalam tabel log. A-001 akan langsung direplikasi (increment) ke standby database. Setelah A-001 terekam di standby database, file logpadastandby databaseakan memberikan pesan bahwa data berhasil terekam dan status A-001 padaprimary databaseberubah menjadi “logged”. Demikianlah sebab yang menjadikan replikasi dengan metode incremental backup akan menghasilkan replikasi yang real time. Kelemahannya yaitu data yang tidak valid juga akan langsung tereplikasi kestandby databaseapabila data tersebut di-input oleh admin. Hasil pengujian waktu tempuh dan throughput yang penulis catat saat melakukaninputdata dapat dilihat pada tabel 4.4.
Tabel 4.4. Hasil pengujian waktu respon danthroughputpada skenario I
Tahap Waktu Respon Throughput
I 0,5 s 7,37 kbps
II 0,9 s 3,69 kbps
III 0,7 s 3,78 kbps
IV 0,5 s 5,36 kbps
Dari hasil pengujian yang telah dilakukan dapat dilihat bahwa replikasi yang terjadi antara primary database dan standby database tidak ada yang mencapai waktu 1 s. Sehingga dapat disimpulkan bahwa standby database pada lingkungan DBMS MySQL yang penulis bangun adalahreal time.
4.1.2. Skenario II, Standby Database dalam keadaan normal tetapi Primary Database mati dalam keadaan proses menginput data.
Skenario II adalah simulasi yang menunjukkan primary databasemelakukan failover kepada standby database karena mengalami kerusakan. Standby database akan menjadi primary database yang baru untuk menggantikan fungsi primary database yang lama sehingga data dapat tetap digunakan dengan baik. Fungsi failover juga tidak dimiliki oleh DBMS MySQL. Sehingga untuk itu penulis membuat sebuah menu pada aplikasi master dengan nama “transform to primary”. Berikut adalah proses failoverdi dalam aplikasi master:
35
a) Menjalankan aplikasi master dari server standby database dan lakukan konfigurasi IP Address pada aplikasi master untuk mengaktifkan standby database menjadi primary database. Seperti yang terlihat pada gambar 4.11 di bawah ini:
Gambar 4.11. KonfigurasiIP addressuntukprimary databaseyang baru
b) Kemudian aktifkan failoverdengan cara menjalankan opsitransform to primary. Seperti pada gambar 4.12 di bawah ini:
Gambar 4.12. Konfigurasifailover
Setelah menu transform to primary dipilih oleh admin melalui server standby database, kini status standby database telah menjadi primary database yang baru. Sehingga data masih tetap dapat diakses walaupunprimary database yang lama sudah tidak aktif lagi.
c) Konfigurasi IP address klien pada aplikasi pergudangan menuju primary databaseyang baru.
Karenaprimary database yang lama sudah tidak aktif (beroperasi) dalam waktu tertentu, maka alamat server pada aplikasi pergudangan yang berada pada PC admin harus di set ulang. Konfigurasikan alamat server pada aplikasi pergudangan tersebut menuju IP address primary database yang baru. Contoh konfigurasi tersebut dapat dilihat pada gambar 4.13 di bawah ini:
36
Gambar 4.13. KonfigurasiIP addresspada aplikasi pergudangan
Aktifasi failover yang merubah standby database menjadi primary database yang baru bersifat operasi permanen. Admin tidak dapat mengembalikan fungsi primary database yang lama untuk menjadi primary databasekembali dengan cara role back. Primary database yang lama akan disiapkan menjadi standby database yang baru. Dengan demikiandatabasetersebut dapat menjadiprimary database kembali apabila primary databaseyang berjalan saat ini juga mengalami kerusakan (failure).
4.1.3. Skenario III, Primary Database dalam keadaan normal tetapi dengan standby database yang baru.
Skenario III menggambarkan proses terbentuknya standby database yang baru. Karena pada skenario IIstandby databasetelah menggantikanprimary databaseyang rusak, sehingga terjadinya kevakuman padastandby database. Sementaraadmintetap melakukan transaksi data terhadap primary database yang baru. Hal ini mengakibatkan adanya penumpukan data yang belum tereplikasi pada standby databaseyang baru. Sehingga mengakibatkanprimary databasedanstandby database yang baru tidak memiliki jumlah data yang sama. Untuk mengatasi ketidaksinkronan ini dibuatkan sebuah menu “initiate standby database” yang dapat mereplikasikan data yang menumpuk pada primary database dan belum direplikasi oleh standby database. Replikasi yang terjadi pada saat sinkronisasi data pada simulasi ini adalah full backupdan periodik. Berikut adalah gambar 4.14 yang menjelaskan replikasi yang terjadi pada saat simulasi ini berlangsung:
37
Tabel Primary Database Tabel Standby Database
Gambar 4.14. Proses Sinkronisasi data dengan menggunakan MetodeFull Backup
Keterangan:
Proses 1 : Setiap transaksi yang terjadi padaprimary databaseakan masuk ke dalam tabellog. Karena tidak ditemukannyastandby databasemaka data tersebut akan terkumpul di primary database dengan status “unlogging” dan membentuk tumpukan data. Sehingga harus dilakukan sinkronisasi data secarafull backupapabilastandby databasetelah aktif kembali.
Proses 2 : Tumpukan data direplikasi ke standby database dengan menggunakan metodefull backup. Data dengan id terkecil akan lebih dulu direplikasikan kestandby database(ascending).
Proses 3 : Data yang telah tereplikasi di standby database akan mengirimkan status “logging” pada tabellogyang ada diprimary database.
Berikut adalah langkah kerja aplikasi master mempersiapkandatabaseyang telah siap untuk digunakan kembali menjadistandby database:
a. Pastikan proses real time logging pada server primary database yang baru dalam keadaan tidak aktif. Hal ini dilakukan agar proses reset pada standby database yang baru dapat berjalan dengan baik. Sebab reset tidak akan selesai
ID Kode
Barang Nama Barang Harga 1665
A-001 Dancow Balita
150gr 9750
1666 A-002 SGM 0-6 Bln 11200 1667
A-003 Lactogen Pbio
1 180gr 16700 1668
A-004 Lactogen Pbio
2 180gr 16700
ID Kode
Barang Nama Barang Harga 1665 A-001 Dancow Balita
150gr 9750
1666 A-002 SGM 0-6 Bln 11200 1667 A-003 Lactogen Pbio 1
180gr 16700
1668 A-004 Lactogen Pbio 2
180gr 16700
Id_log Tanggal Query Status 1 15-11-2013 insert logged 2 15-11-2013 insert logged 3 16-11-2013 insert logged 4 17-11-2013 insert logged Proses 3 Proses 2 Proses 1 Tabel Log
38
apabila masih ada data yang terkirim dariprimary database. seperti yang terlihat pada gambar 4.15 berikut:
Gambar 4.15. Tabel realtime logging tidak aktif
b. Jalankan aplikasi master padastandby database yang baru. Dan kemudian set IP Address pada standby database yang baru. Kemudian klik initiate standby databasepada menu aplikasi master yang terdapat pada serverstandby database. Proses replikasi data terhadap standby database yang baru dapat dilihat pada gambar 4.16 di bawah ini.
Gambar 4.16. Proses initiate standby database
Semua data di dalam standby database harus di format (hapus) sebelum melakukan teknik initiate standby database. Hal ini dilakukan untuk menghindari redudansi data yang mungkin terjadi apabila standby database yang baru mereplikasi data yang ada pada primary database. Fungsi utama dari initiate standby database adalah mereplikasi dari awal semua data yang ada padaprimary databaseyang baru.
39
c. Proses real time logging dapat diaktifkan kembali. Pada proses ini standby database yang baru sudah dapat digunakan kembali. Dengan demikian proses standby databasetelah selesai dilakukan.
Pada skenario ini penulis melakukan pengujian sinkronisasi data yang dimiliki primary databaseterhadapstandby database. Pengujian dilakukan secara tiga kali dengan jumlah data yang berbeda-beda yaitu 4record, 33recorddan 106 record. Berikut adalah tabel yang dihasilkan dari pengujian skenario III:
Tabel 4.5. Hasil pengujian waktu respon pada skenario III
Tahap Record Waktu
1 4 1 s
2 33 6 s
3 106 17 s
Tabel 4.6. Hasil pengujianthroughputpada skenario III Tahap Record Throughput
1 4 17 kbps
2 33 3 kbps
3 106 1,12 kbps
Dari hasil pengujian di atas dapat disimpulkan bahwa proses replikasi yang terjadi dengan menggunakan metode incremental backup lebih cepat jika dibandingkan dengan metode full backup. Karena pada metode incremental backup, primary databasetidak dibebankan oleh jumlah data yang menumpuk. Hal lain yang menjadi pertimbangan standby database menggunakan metode incremental backup karena primary database yang dapat rusak kapan saja. Metode incremental backup menjadikan standby database tidak pernah mengalami kehilangan data karena data ter-backup secara real time. Dengan demikian standby database selalu siap untuk menggantikanprimary database.
40
BAB 5