Replikasi pada Standby Database Menggunakan Metode Incremental Backup

REPLIKASI PADA

STANDBY DATABASE

MENGGUNAKAN

METODE

INCREMENTAL BACKUP

TESIS

DEFRY HAMDHANA

117038074

PROGRAM STUDI S2 TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI

UNIVERSITAS SUMATERA UTARA

MEDAN

2014

REPLIKASI PADA

STANDBY DATABASE

MENGGUNAKAN

METODE

INCREMENTAL BACKUP

TESIS

Diajukan untuk melengkapi tugas dan memenuhi syarat memperoleh ijazah Magister Teknik Informatika

DEFRY HAMDHANA

117038074

PROGRAM STUDI S2 TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI

UNIVERSITAS SUMATERA UTARA

MEDAN

2014

PENGESAHAN

Judul : Replikasi padaStandby DatabaseMenggunakan Metode Incremental Backup

Nama : Defry Hamdhana

Nomor Induk Mahasiswa : 117038074

Program Studi : Magister (S2) Teknik Informatika

Fakultas : Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara

Komisi Pembimbing :

Pembimbing 2, Pembimbing 1,

Dr. Erna Budhiarti Nababan, M.IT Prof. Dr. Herman Mawengkang

Diketahui/disetujui oleh

Program Studi S2 Teknik Informatika Ketua,

Prof. Dr. Muhammad Zarlis NIP. 19570701 198601 1 003

PERNYATAAN

REPLIKASI PADASTANDBY DATABASEMENGGUNAKAN METODEINCREMENTAL BACKUP

TESIS

Saya mengakui bahwa tesis ini adalah hasil karya saya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing telah disebutkan sumbernya.

Medan, 03 Januari 2014

Defry Hamdhana NIM. 117038074

PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN

AKADEMIS

Sebagai civitas akademik Universitas Sumatera Utara, saya yang bertanda tangan di bawah ini :

Nama : Defry Hamdhana

Nim : 117038074

Program Studi : Teknik Informatika

Demi pengembangan ilmu pengetahuan, menyetujui memberikan kepada Universitas Sumatera Utara Hak Bebas Royalti Non-Ekslusif (Non-Exclusive Royalty Free Right) atas tesis saya yang berjudul:

REPLIKASI PADASTANDBY DATABASEMENGGUNAKAN METODEINCREMENTAL BACKUP

Beserta perangkat yang ada (jika diperlukan). Dengan hak bebas Royaliti Non-Exclusive ini, Universitas Sumatera Utara berhak menyimpan, mengalih media, memformat, mengelola dalam bentuk database, merawat dan mempublikasikan tesis saya tanpa meminta izin dari saya selama tetap mencantumkan nama saya sebagai penulis dan sebagai pemegang dan/atau sebagai pemilik hak cipta

Demikian pernyataan ini dibuat dengan sebenarnya.

Medan, 03 Januari 2014

Defry Hamdhana 117038074

Telah diuji pada

Tanggal: 03 Januari 2014

PANITIA PENGUJI TESIS

Ketua : Prof. Dr. Herman Mawengkang Anggota : 1. Dr. Erna Budhiarti Nababan, M.IT

2. Prof. Dr. Muhammad Zarlis 3. Prof. Dr. Tulus

RIWAYAT HIDUP

DATA PRIBADI

Nama Lengkap : Defry Hamdhana, S.T

Tempat dan Tanggal Lahir : Lhokseumawe, 05 Mei 1987 Alamat Rumah : Jl. Pendidikan No. 6 Dusun III

Desa Tambon Tunong Kec. Dewantara Kab. Aceh Utara

Telepon Rumah/Faks/Hp : 0857 6136 2180

E-mail : defryhamdhana@gmail.com

Instansi Tempat Bekerja : SMK Tritech Informatika Medan

Alamat Kantor : Jl. Bhayangkara No. 488 Kel. Indra Kasih Kec. Medan Tembung

DATA PENDIDIKAN

SD : SD Swasta Iskandar Muda TAMAT : 1999 SMP : SMP Swasta Al-Azhar Medan TAMAT : 2002 SMA : SMA Negeri 1 Lhokseumawe TAMAT : 2005 S1 : Jurusan Teknik Informatika Unimal TAMAT : 2010

vii

KATA PENGANTAR

Alhamdulillah puji syukur kehadirat Allah SWT, yang telah memberikan rahmat dan karunia-Nya kepada penulis, sehingga penulis dapat menyelesaikan tesis ini dengan judul: Replikasi padaStandby DatabaseMenggunakan MetodeIncremental Backup.

Tesis ini disusun untuk melengkapi dan memenuhi persyaratan mencapai derajat kesarjanaan Strata-2 pada Program Studi Teknik Informatika, Fakultas Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara. Penulis menyadari sepenuhnya, bahwa tesis ini selesai karena adanya dukungan dan bantuan dari berbagai pihak. Untuk itu pada kesempatan ini, penulis menyampaikan penghargaan dan ucapan terimakasih yang sedalam-dalamnya kepada:

1. Bapak Prof. Dr. Herman Mawengkang, selaku Dosen Pembimbing Utama dan Ibu Dr. Erna Budhiarti Nababan, M.IT selaku Dosen Pembimbing Kedua, dengan segala perhatian dan kesabaran telah memberikan bimbingan baik selama mengikuti pendidikan maupun dalam penyelesaian tesis ini.

2. Bapak Prof. Dr. Muhammad Zarlis selaku Ketua Prodi, Bapak Prof. Dr. Tulus dan Bapak Dr. Marwan Ramli, M.Si, selaku Dosen Pembanding atas segala kritik dan sarannya.

3. Seluruh Dosen Pengajar Pascasarjana Program Studi Teknik Informatika yang telah memberikan bekal ilmu pengetahuan selama penulis mengikuti pendidikan.

4. Ayahanda H. Muhammad Yusuf Umar, Ibunda Hj. Ernawati Sulaiman, dan adik-adik atas doa restu dan motivasinya yang telah diberikan selama ini.

5. Bapak Fadlisyah S.Si, M.T dan Bapak Sayed Fachrurrozi S.Si, M.Kom selaku Dosen Jurusan Informatika Unimal, dan Bapak Nurdin, M.Kom selaku Ketua Jurusan Informatika Unimal, yang selama ini telah banyak memberikan dukungan baik moril maupun materil kepada penulis.

viii

6. Segenap civitas akademika Program Studi Pascasarjana Teknik Informatika Sumatera Utara yang selalu memberikan informasi dan pelayanan kepada penulis dengan tulus dan tak kenal lelah.

7. Rekan-rekan seperjuangan pada program studi Teknik Informatika yang tergabung dalam Kom C 2011 dan rekan-rekan lain yang tidak dapat disebutkan satu persatu, yang telah banyak membantu selama perkuliahan maupun dalam penyelesaian tesis ini.

Tentulah tiada yang sempurna di dunia ini begitu pula dalam penulisan tesis ini, untuk itu penulis mengharapkan kritik dan saran dari pembaca demi kesempurnaan tesis ini selanjutnya.

Akhir kata penulis berharap semoga tesis ini dapat bermanfaat bagi semua pihak, khususnya dalam bidang pendidikan dan penyedia jasa internet.

Medan, 03 Januari 2014 Penulis

ABSTRAK

Bagi beberapa lembaga pemerintahan atau perusahaan, data adalah salah satu aset yang harus dapat dijamin keberadaaannya. Akan tetapi resiko kehilangan data yang diakibatkan olehmaintenance, kerusakandatabase, kerusakan media, data corruption atau bahkan bencana alam dapat memberikan resiko yang besar terhadap keberadaan data yang semuanya itu dapat terjadi tanpa bisa diprediksi terlebih dahulu. Untuk itu dibutuhkan sebuah disaster recovery plan yang dapat menjamin data tetap konsisten walaupun database mengalami gangguan bahkan kerusakan. Adapun teknik penyelamatan data yang sering dilakukan adalah backup data. Pada kasus ini backup data harus dapat dilakukan secarareal time. Karenadisaster yang dapat terjadi kapan saja. Hal ini dapat dilakukan dengan menggunakan metode incremental backup. Namun solusi backup untuk beberapa instansi yang tetap harus melakukan transaksi data walaupun database primary rusak belum cukup. Server database slave tidak dapat langsung menggantikan server database primary. Untuk itu dibutuhkan sebuah teknik yang mampu mengatur server database slave menjadi pengganti server database primary untuk menjaga keberlangsungan transaksi data. Teknik tersebut adalah standby database. Dengan melakukan failover, standby database dapat menggantikan fungsiprimary database dalam waktu yang singkat. Dengan demikian proses transaksi data tetap dapat berjalan walaupun primary database mengalami kerusakan.

REPLICATION STANDBY DATABASE USING THE INCREMENTAL BACKUP METHOD

ABSTRACT

For some government agencies or companies, the data is one of the assets that must be guaranteed its existence. However, the risk of data loss caused by maintenance, database damage, damage to the media, corruption of data or even a natural disaster can provide a great risk to the existence of the data all of which can happen without being able to predict in advance. That requires a disaster recovery plan to ensure that data remains consistent even though the database to crash damage. The data rescue techniques is often done data backups. In this case the backup data must be done in real time. Because disaster can occur anytime. This can be done by using incremental backups. But backup solutions for some agencies still have to perform data transactions even if the primary database is not damaged enough. The slave database servers can not directly replace the primary database server. That requires a technique that is able to regulate the slave database server becomes a substitute for the primary database server to maintain the continuity of data transactions. The technique is a standby database. By doing failover, standby database can replace the function of the primary database in a short time. Thus the process of data transactions can still run even if the primary database is damaged.

xi

DAFTAR ISI

Hal.

HALAMAN JUDUL i

PENGESAHAN ii

PERNYATAAN ORISINALITAS iii

PERSETUJUAN PUBLIKASI iv

PANITIA PENGUJI v

RIWAYAT HIDUP vi

KATA PENGANTAR vii

ABSTRAK ix

ABSTRACT x

DAFTAR ISI xi

DAFTAR TABEL xiii

DAFTAR GAMBAR xiv

BAB I PENDAHULUAN 1

1.1. Latar Belakang 1

1.2. Perumusan Masalah 3

1.3. Batasan Masalah 3

1.4. Tujuan Penelitian 3

1.5. Manfaat Penelitian 3

BAB II LANDASAN TEORI 5

2.1. Data 5

2.2. Disaster Recovery 5

2.3. KonsepBackup 6

2.4. Replikasi 7

2.5. Primary DatabasedanStandby Database 9

2.5.1. Failover 10

2.5.2. Redo Log File 10

2.5.1. Archived Log File 10

2.6. MetodeStandby Database 11

2.6.1. Metode Standby Database secara Manual 11 2.6.2. Metode Standby Database secara Managed Recovery 11

2.6.3. Read-Only Mode untuk Query 12

BAB III METODOLOGI PENELITIAN 14

3.1. Rancangan Penelitian 15

3.2. Perangkat dan Data yang digunakan dalam penelitian 15

3.2.1. Perangkat 15

3.2.2.Data yang digunakan 15

3.3. Model Jaringan Untuk Simulasi 15

. 3.4. Langkah Kerja Jaringan 16

xii

3.6.1. Analisa Data 17

3.6.2. Rancangan Skenario Simulasi 17

3.6.2.1.Skenario I, Primary Database dan Standby

Database berada dalam keadaan normal 23 3.6.2.2.Skenario II, Standby Database dalam

keadaan normal tetapi Primary Database mati dalam keadaan proses menginput data 24 3.6.2.3.Skenario III, Primary Database dalam

keadaan normal tetapi dengan Standby Database

yang baru 24

BAB IV HASIL DAN PEMBAHASAN 25

4.1. Parameter ReplikasiDatabasepada Simulasi 25

4.2. Simulasi 27

4.1.1. Skenario I, Primary Database dan Standby Database

berada dalam keadaan normal 28

4.1.2. Skenario II, Standby Database dalam keadaan normal tetapi Primary Database mati dalam keadaan proses

menginput data 34

4.1.3.Skenario III, Primary Database dalam keadaan normal tetapi dengan Standby Database yang baru 36

BAB V KESIMPULAN DAN SARAN 40

5.1. Kesimpulan 40

5.2. Saran 41

DAFTAR PUSTAKA 42

xiii

DAFTAR TABEL

Hal.

Tabel 4.1. PengaturanIP address 28

Tabel 4.2. Contoh data barang yang terdapat di dalamprimary database 32 Tabel 4.3. Contoh data barang yang terdapat di dalamstandby database 32 Tabel 4.4. Hasil pengujian waktu respon danthroughputpada skenario I 34 Tabel 4.5. Hasil pengujian waktu respon pada skenario III 39 Tabel 4.6. Hasil pengujianthroughputpada skenario III 39

xiv

DAFTAR GAMBAR

Hal. Gambar 2.1.Standby databasepada moderecovery manual 11 Gambar 2.2.Updatesecara otomatis pada sebuahstandby database 12 Gambar 2.3.Standby Databasedalam ModeRead Only 12 Gambar 3.1. Rancangan topologi jaringan yang dibagun untuk simulasi 16 Gambar 3.2.Flowchartsistem kerjastandby database 18

Gambar 3.3. Prosesstandby database 19

Gambar 3.4. Skema dari sistemstandby database 20

Gambar 3.5.Redo log files 21

Gambar 3.6. Proseslog File 23

Gambar 4.1. Arsitektur server pada simulasi 25

Gambar 4.2. MendaftarkanIP address primary databasepada komputer

klien 28

Gambar 4.3. Melakukan konfigurasiIP addresspada aplikasi master 29 Gambar 4.4. MendaftarkanIP server standby databasepada aplikasi

master 29

Gambar 4.5. Mengaktifkanreal time logging 30

Gambar 4.6.Inputdata 30

Gambar 4.7. (a) Data padaprimary database, (b) Data padastandby

database 31

Gambar 4.8. Tabellogging 31

Gambar 4.9. Skema replikasi pada sistem yang dibangun 32 Gambar 4.10. Proses replikasistandby databasesecaraincremental

backup 33

Gambar 4.11. KonfigurasiIP addressuntukprimary databaseyang baru 35

Gambar 4.12. Konfigurasifailover 35

Gambar 4.13. KonfigurasiIP addresspada aplikasi pergudangan 36 Gambar 4.14. Proses sinkronisasi data dengan menggunakan metodefull

xv

Gambar 4.15. Tabelreal time loggingtidak aktif 38

ABSTRAK

Bagi beberapa lembaga pemerintahan atau perusahaan, data adalah salah satu aset yang harus dapat dijamin keberadaaannya. Akan tetapi resiko kehilangan data yang diakibatkan olehmaintenance, kerusakandatabase, kerusakan media, data corruption atau bahkan bencana alam dapat memberikan resiko yang besar terhadap keberadaan data yang semuanya itu dapat terjadi tanpa bisa diprediksi terlebih dahulu. Untuk itu dibutuhkan sebuah disaster recovery plan yang dapat menjamin data tetap konsisten walaupun database mengalami gangguan bahkan kerusakan. Adapun teknik penyelamatan data yang sering dilakukan adalah backup data. Pada kasus ini backup data harus dapat dilakukan secarareal time. Karenadisaster yang dapat terjadi kapan saja. Hal ini dapat dilakukan dengan menggunakan metode incremental backup. Namun solusi backup untuk beberapa instansi yang tetap harus melakukan transaksi data walaupun database primary rusak belum cukup. Server database slave tidak dapat langsung menggantikan server database primary. Untuk itu dibutuhkan sebuah teknik yang mampu mengatur server database slave menjadi pengganti server database primary untuk menjaga keberlangsungan transaksi data. Teknik tersebut adalah standby database. Dengan melakukan failover, standby database dapat menggantikan fungsiprimary database dalam waktu yang singkat. Dengan demikian proses transaksi data tetap dapat berjalan walaupun primary database mengalami kerusakan.

REPLICATION STANDBY DATABASE USING THE INCREMENTAL BACKUP METHOD

ABSTRACT

For some government agencies or companies, the data is one of the assets that must be guaranteed its existence. However, the risk of data loss caused by maintenance, database damage, damage to the media, corruption of data or even a natural disaster can provide a great risk to the existence of the data all of which can happen without being able to predict in advance. That requires a disaster recovery plan to ensure that data remains consistent even though the database to crash damage. The data rescue techniques is often done data backups. In this case the backup data must be done in real time. Because disaster can occur anytime. This can be done by using incremental backups. But backup solutions for some agencies still have to perform data transactions even if the primary database is not damaged enough. The slave database servers can not directly replace the primary database server. That requires a technique that is able to regulate the slave database server becomes a substitute for the primary database server to maintain the continuity of data transactions. The technique is a standby database. By doing failover, standby database can replace the function of the primary database in a short time. Thus the process of data transactions can still run even if the primary database is damaged.

1

BAB 1 PENDAHULUAN

1.1. Latar Belakang

Kebutuhan akan sistem database yang semakin meningkat menjadikan data menjadi aset yang bernilai tinggi. Dengan demikian penting untuk menjaga data agar tetap ada kapan saja dibutuhkan. Akan tetapi resiko terjadinya kerusakan (failure) pada database yang mengakibatkan data tidak dapat diakses atau bahkan mengakibatkan data loss dapat terjadi setiap saat. Gangguan tersebut dapat berupa maintenance, kerusakandatabase, kerusakan media dandata corruption.Databasejuga dapat rusak akibat adanya bencana alam seperti kebakaran, gempa bumi dan banjir.

Kerugian yang terjadi dari rusaknya database secara tiba-tiba akan sangat besar. Hal ini dapat diatasi apabila database yang rusak dapat langsung digantikan olehdatabasecadangan (secondary) sehingga sistem dapat berjalan dengan baik. Oleh sebab itu dibutuhkan sebuah disaster recovery plan yang dapat menjamin data tetap konsisten walaupundatabasemengalami gangguan bahkanfailure(kerusakan).

Adapun teknik penyelamatan data yang sering dilakukan, yaitu backup data. Backup data adalah teknik menyalin data ke dalam media lain. Dalam penelitian ini berarti data yang berada pada primary database (utama) disalin ke dalam secondary database (cadangan). Jika primary database mengalami kerusakan maka data tetap aman di dalam secondary database. Dan secondary database akan mengembalikan (restore) data apabilaprimary databasesudah siap untuk digunakan kembali. Namun demikian hal ini belum dapat menjadi solusi terbaik. Karena backup tidak menggantikan kinerja primary database secara langsung yang mengakibatkan data tidak dapat diakses sampai maintenance pada sistem primary database tersebut berakhir.

Beberapa penelitian yang telah dilakukan oleh peneliti yang dituliskan dalam jurnal atau karya ilmiah tentang backup data adalah Wiesmann et al (2000), yang

2

melakukan penelitian teknik replikasi database dengan menggunakan klasifikasi tiga parameter, yaitu arsitektur server, interaksi server, terminasi transaksi. Dengan membandingkan ketiga parameter di atas kesimpulan yang bisa diambil adalahupdate everywhere memiliki potensi yang baik untuk mereplikasi data. Sedangkan pada interaksi linear kekurangannya adalah sumber biaya yang besar. Noraziah (2012) meneliti tentang teknik replikasi di dalam Data Grid Environments. Dan menghasilkan beberapa teknik yang dapat meningkatkan latency jaringan, konsumsi bandwith maupun toleransi kesalahan dalam Data Grid Environments. Tawar & Wahyuningsih (2011) menguji dua metode backup data yang terdapat pada server database MySQL antara lain MySQLDump dan replikasi. Kedua metode tersebut diuji dengan membandingkan pengukuran memori, penggunaan CPU dan waktu proses pada server saat proses backup terjadi hampir bersamaan dengan proses transaksi input data. Dan kesimpulannya adalah metodebackup menjadikan replikasi lebih efisien dibandingkan dengan MySQLDump dari sisi penggunaan memory dan CPU. Sementara Qian et al (2009) mempertimbangkan skema full backup dan incrementaluntuk sistem database. Dari penelitian tersebut dihasilkan bahwa jumlah optimal untuk meminimalkan biaya dalam melakukanbackupdapat dilakukan dengan menggunakan teknikincremental.

Dari penelitian terdahulu penulis menyimpulkan bahwa replikasi merupakan hal yang harus dilakukan oleh instansi yang tidak ingin kehilangan datanya. Replikasi juga masih merupakan hot issue yang masih terus mengalami pengembangan. Salah satunya adalah standby database. Kemampuan standby database adalah untuk melakukanrecoverydan backuppadaprimary database (Singhet al : 2013).Standby databasedapat melakukanbackupdata dari lingkungan geografis yang berbeda, maka apabila terjadi hal-hal yang dapat menyebabkanprimary databaserusak karena suatu hal, standby database dapat mengambil fungsi peran dari primary database yang mengalami kerusakan. Pada DBMS Oracle, standby database merupakan fitur yang sudah ada di dalam Oracle data guard. Wibowo et al (2007) melakukan analisa standby databasedengan menggunakan Oracle dan menunjukkan tingkat availibilitas yang tinggi karena dapat langsung diaktifkan dan beroperasi begitu terjadi failure terhadap primary database. Dan oleh sebab itu penulis melakukan riset dan analisis terhadapstandby databasesebagaidisaster recovery.

3

1.2. Perumusan Masalah

Berikut adalah Perumusan Masalah dari penelitian ini:

1. Membangun perangkat lunak yang mendukung konsep standby database pada lingkungan DBMS MySQL.

2. Menganalisa kelemahan dari implementasi standby database pada lingkungan DBMS MySQL.

3. Menguji sistemstandby databasebisa bekerja secarareal time.

4. Menguji waktu respon dan throughput pada replikasi dari server primary databaseke serverstandby database.

1.3. Batasan Masalah

Dari Perumusan Masalah di atas penulis membatasi tesis ini dengan:

a. Simulasi skenario pengujian menggunakan jaringan yang telah terisolasi dengan topologi star.

b. Parameter yang diuji adalah waktu respon dan throughput. c. Failuresistem berupa matinya jaringan serverprimary database. d. Simulasi hanya dilakukan pada sebuah serverstandby database.

1.4. Tujuan Penelitian

Tujuan penelitian ini adalah membuat standby database yang mampu melakukan backup data secara realtime pada lingkungan DBMS MySQL dan menggantikan primary database pada saat primary database mengalami kerusakan (failure) serta menguji waktu respon dan throughput pada proses replikasi dari primary database serverkestandby database serveryang diharapkan mampu mengatasi kehilangan data jika terjadi gangguan seperti bencana alam, kerusakandatabasedan kerusakan media.

1.5. Manfaat Penelitian

Manfaat dari penelitian tesis ini, yaitu:

1. Memberikan uraian secara lebih terperinci tentang sistem kerja standby database dimulai dari proses replikasi (logging) dan perubahan dari standby database

4

menjadiprimary database (failover) serta persiapanprimary database yang lama menjadistandby databasedalam lingkungan DBMS MySQL.

2. Penelitian ini diharapkan dapat dijadikan sebagai salah satu solusi yang dapat menangani kehilangan data sehingga data tetap dapat diakses kapan saja oleh user.

3. Sebagai referensi bagi hasil studi dan peneliti selanjutnya yang diminati dan mengembangkan penelitian ini.

5

BAB 2

TINJAUAN PUSTAKA

2.1. Data

Data adalah sesuatu yang mewakili objek dan peristiwa yang memiliki arti yang sangat penting bagiuser (Hofferet al, 2005). Dalam pengertian yang lain data adalah fakta yang dapat disimpan dan memiliki arti (Navathe & Elmasri, 2000). Sehingga dapat disimpulkan bahwa data adalah fakta yang telah terjadi, memiliki arti, dan dapat disimpan secara teratur sedemikian rupa sehingga menjadi sebuah form yang dapat digunakan kembali suatu waktu. Data yang saling berhubungan akan dikumpulkan dan disimpan dalam suatu database. Hal ini jelaskan oleh (Connolly, 2002) yang menyatakan bahwa database adalah suatu koleksi data yang saling berhubungan secara logikal, dan sebuah deskripsi data yang dirancang untuk memenuhi kebutuhan informasi suatu organisasi. Database mempunyai sumber data dalam pengumpulan data, bervariasi derajat interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan oleh beberapa user untuk berbagai kepentingan (Waliyanto, 2000). Untuk memasukkan, mengubah, menghapus, memodifikasi dan memperoleh data/informasi dengan praktis dan efisien digunakan sebuah program komputer yang disebut DBMS (Data Base Management System).

2.2. Disaster Recovery

Disaster recovery adalah proses, kebijakan dan prosedur yang berkaitan dengan persiapan untuk pemulihan (recovery) atau kelanjutan pada infrastruktur teknologi yang sangat penting (vital) bagi organisasi setelah bencana yang disebabkan oleh alam maupun manusia. Bencana dapat diklasifikasikan ke dalam dua kategori, yaitu:

a. Yang pertama adalah bencana alam seperti banjir, angin topan, tornado atau gempa bumi. Sementara mencegah bencana alam sangat sulit, memastikan langkah-langkah seperti perencanaan yang baik adalah solusi yang lebih tepat.

6

Langkah-langkah tersebut diharapkan mampu menghindari ataupun mengurangi kerugian akibat bencana (disaster).

b. Bencana buatan manusia. Bencana juga dapat terjadi akibat perbuatan manusia. Sebagai contoh kegagalan infrastruktur dan terorisme. Dalam hal ini pengawasan dan perencanaan juga diharapkan dapat menghindari kerugian.

Menurut (Gregory, 2009) Disaster Recovery Plan (DRP) adalah bagian dari sebuah proses yang lebih besar sebagai perencanaan kelangsungan bisnis dan termasuk di dalamnya perencanaan untuk memulai kembali aplikasi, data, perangkat keras (hardware), komunikasi elektronik (networking) dan infrastruktur teknologi informasi lainnya. Langkah-langkah kontrol pemulihan (recovery) bencana teknologi informasi dapat diklarifikasikan menjadi tiga jenis, yaitu:

1. Langkah preventive, kontrol yang dilakukan untuk mencegah sebuah bencana yang akan terjadi.

2. Langkah deteksi, kontrol yang bertujuan untuk mendeteksi atau menemukan kejadian yang tidak diinginkan.

3. Langkah korektif, kontrol yang ditujukan untuk memperbaiki atau memulihkan sistem setelah bencana atau peristiwa.

Disaster recovery plan yang baik memastikan bahwa ketiga jenis kontrol didokumentasikan dan diuji secara teratur.

2.3. KonsepBackup

Menurut (Tawar & Wahyuningsih, 2011) Proses backup dalam teknologi informasi mengacu pada pembuatan salinan data, sehingga salinan tambahan tersebut dapat digunakan untuk mengembalikan (restore) semula setelah peristiwa kehilangan data. Backupdata merupakan salah satu pengelolaan data agar data tetap terjaga saat terjadi perubahan atau kehilangan data.Backupsangat berguna terutama untuk dua tujuan:

a. Untuk memulihkan keadaan setelah bencana (disaster recovery)

b. Untuk mengembalikan sejumlah kecilfilesetelah sengaja dihapus atau rusak. Konsistensi data dalam prosesbackupharus dijaga, sebelum melakukan backup data. Secara umum tipebackupterbagi menjadi dua, yaitu:

a. Full Backup, yaitu tipe backup yang menyalin file secara keseluruhan dalam satu waktu dengan mengabaikanattribut archive bit file. Setelah file di-backup

7

maka archive bit dari file tersebut akan dihapus sampai file tersebut dimodifikasi. Ketika archive bit diset kembali, ini menandakan bahwa file tersebut telah berubah dan perlu di-backuplagi.

b. Incremental Backup, adalah backup data yang mengalami perubahan sejak backupterakhir dilakukan. Hanya file denganarchive bityang akan di-backup. Hal ini akan menghemat penggunaan pita tapi memerlukan waktu yang lama untuk me-restore data karena data tersebar pada pita yang berbeda-beda. Menurut (Elmasri & Rames : 2011) incremental backup sering digunakan karena hanya mengganti perubahan yang terjadi sejak backup terakhir yang telah disimpan.

2.4. Replikasi

Replikasi dicapai dengan memiliki sistem standby, yang merupakan duplikasi dari database produksi. Replikasi standby diperbaharui setelah database produksi memanipulasi data, sehingga membuat sistem standby sangat dekat dengan sistem utama (Radulescu, 2002). Replikasi adalah suatu teknik untuk melakukan copy dan pendistribusian data dan objek-objekdatabasedari satudatabasekedatabaselain dan melakukan sinkronisasi antara database sehingga konsistensi data dapat terjamin (Tawar & Wahyuningsih, 2011).

Pada dasarnya sistem replikasi membutuhkan minimal dua buah server untuk digunakan sebagai master dan slave. Dengan menggunakan teknik replikasi, data dapat didistribusikan ke lokasi yang berbeda melalui koneksi jaringan lokal maupun internet.

Beberapa keuntungan dari replikasi adalah sebagai berikut:

1. Memungkinkan beberapa lokasi menyimpan data yang sama. Hal ini sangat berguna pada saat lokasi-lokasi tersebut membutuhkan data yang sama atau memerlukan server yang terpisah dalam pembuatan aplikasi laporan.

2. Aplikasi transaksi onlineterpisah dari aplikasi pembacaan seperti proses analisis databasesecaraonline, datasmartsatau datawarehouse.

3. Memungkin otonomi yang besar. Pengguna dapat bekerja dengan meng-copy data pada saat tidak terkoneksi kemudian melakukan perubahan untuk dibuat databasebaru pada saat terkoneksi.

8

4. Data dapat ditampilkan seperti layaknya melihat data tersebut dengan menggunakan aplikasi berbasisWeb.

5. Meningkatkan kinerja pembacaan.

6. Membawa data mendekati lokasi individu atau kelompok pengguna. Hal ini akan membantu mengurangi masalah karena modifikasi data dan pemrosesan query yang dilakukan oleh banyak pengguna karena data dapat didistribusikan melalui jaringan dan data dapat dibagi berdasarkan kebutuhan masing-masing unit atau pengguna.

7. Penggunaan replikasi sebagai bagian dari strategistandby server.

8. Menyembunyikan perbedaan antara layananreplicateddan non-replicated. Menurut (Wiesman et al, 2000) replikasi database memiliki tiga parameter dalam menentukan karakteristik yang terbaik untuk mereplikasi data, yaitu:

1. Arsitektur Server

Parameter kunci pertama untuk dipertimbangkan adalah transaksi yang dieksekusi pada tempat pertama. Ada dua kemungkinan identifikasi, yaitu Replikasi copy primary yang memiliki situs yang spesifik untuk di copy oleh setiap data yang saling terkait. Serta replikasi update everywhere yang memungkinkan updateke item data yang akan dilakukan di mana saja dalam sistem.

2. Interaksi Server

Untuk parameter ini terdapat dua hal yang harus dipertimbangkan, yaitu interaksi konstan, protokol dalam kategori ini melakukan pesan tunggal per transaksi dengan mengelompokkan semua operasi dari transaksi dalam satu pesan. Selanjutnya adalah interaksi linear yang biasanya berkaitan dengan teknik yang apabila sebuah server database merambat ke setiap operasi dari sebuah transaksi pada basis per operasi.

3. Terminasi Transaksi

Sedangkan pada parameter terakhir juga terdapat dua hal yang harus dipertimbangkan, yaitu terminasi voting yang membutuhkan babak tambahan pesan untuk mengkoordinasi replika yang berbeda. Dan terminasi non-voting yang menyiratkan bahwa situs dapat memutuskan sendiri apakah akan melakukan atau membatalkan transaksi.

9

Dengan membandingkan ketiga karakteristik tersebut Wiesman menyimpulkan bahwa update everywherememiliki potensi yang baik untuk mereplikasi data.

Teknik replikasi di dalam Data Grid Environments menurut Noraziah (2012) adalah:

1. A Weight-Based Dynamic Replica Replacement. Strategi ini dihitung berdasarkan waktu akses dalam jendela waktu di masa depan, berdasarkan akses padahistoryterakhir.

2. Distributed Popularity Based Replica Placement Algorithm. Dikembangkan untuk jaringan data hirarkis. Strategi ini memanfaatkan history akses data untuk mengenali file yang sering muncul dan menentukan lokasi replikasi yang optimal untuk meningkatkan kinerja akses data dengan meminimalkan replikasi yangoverheadpada pola jalur data yang diberikan.

3. A New Replication Strategy for Dynamic Data Grids diusulkan untuk memperhitungkan situs yang dinamis. Strategi ini dapat meningkatkan ketersediaan berkas, meningkatkan waktu respon dan dapat mengurangi konsumsibandwidth.

4. Enhance Fast Spread Replication Strategy adalah versi yang disempurnakan pada Fast Spread untuk strategi replikasi data grid. Strategi ini diusulkan untuk meningkatkan total waktu respon dan total konsumsibandwidth.

5. A Value-Based Replication Strategy untuk mengurangi jaringan latency dan sementara itu untuk meningkatkan kinerja keseluruhan sistem.

6. Agent Based Replica Placement Algorithmdiusulkan untuk menentukan calon lokasi untuk penempatan replika yang mengurangi biaya akses,network traffic dan agregat waktu respon untuk aplikasi.

2.5. Primary DatabasedanStandby Database

Primary database adalah database utama yang digunakan untuk menyimpan data. Databaseini diharapkan mampu diakses setiap saat. Maka dari itu jika terjadi transisi roledanprimary database mati, maka secara otomatis pengaksesan terhadap primary databasetersebut juga tidak dapat dilakukan.

Standby database merupakan replikasi database yang terdiri dari backup data dari sebuah primary database. Dengan penerapan redo log archive dari primary

10

database untuk standby database, sehingga data dapat disimpan di dalam server database yang tersinkronisasi. Sebuah standby database memiliki tujuan utama sebagai disaster recovery, backup, analisis, dan reporting (laporan). Jika primary database hancur atau rusak, admin dapat melakukan failover ke standby database, dalam kasus ini standby database menjadi primary database yang baru. Admin juga dapat membuka standby database dengan opsi read only, sehingga dapat berfungsi sebagai sebuahdatabase reportingindependen.

2.5.1. Failover

Failover yaitu mode backup operational pada saat fungsi komponen sistem (seperti processor, server, network, atau database) dilakukan oleh secondary system componentsketika komponen utama mengalami kegagalan atauscheduled down time. Pada konfigurasi standby database semua pengguna aplikasi melakukan transaksi pada primary database. Namun apabila server primary database mengalami kegagalan secara tidak terduga, maka admin harus melakukan failover. Failover adalah operasi yang mengubah standby databasemenjadiprimary database sehingga dapat berjalan secara normal. Operasi ini juga disebut aktivasi standby database. Penting untuk diperhatikan bahwa setelah melakukan failover, admin tidak dapat mengembalikanstandby databaseyang saat ini telah menjadi primary databaseuntuk menjadistandby databasekembali.

2.5.2. Redo Log File

Redo log file merupakan bagian terpenting dalam proses database untuk melakukan proses recovery. Redo log files sebagai tempat catatan setiap transaksi yang terjadi. Berisikan file yang digunakan untuk melakukan instance recovery ketika database mengalami kegagalan.

2.5.3. Archived Log File

Tujuan utama archived log file adalah untuk melindungi database dari kegagalan instance dan kerusakan media disk melalui pengarsipan secara online dengan mengaktifkan proses pengarsipan ke dalamredo log file.

11

2.6. MetodeStandby Database

Standby databaseterdiri dari tiga metode. Masing-masing metode memiliki kelebihan dan kelemahan. Oleh karena itu seorang admin harus mampu memilih metode standby database yang sesuai dengan sistem yang ada. Berikut adalah tiga metode standby database.

2.6.1. Metode Standby Database secara Manual

Admin memiliki pilihan untuk menempatkan database dengan menggunakan metode manualrecovery. Untuk melakukan metode ini, adminharus terus menerus dan secara manual mentransfer dan menerapkan archived redo log ke standby database untuk tetap disinkronkan denganprimary database. Berikut adalah proses standby database dengan menggunakan moderecoverymanual seperti pada gambar 2.1.

Gambar 2.1.Standby databasepada moderecoverymanual [Oracle : 1999]

Metode recovery manual berguna dalam lingkungan yang mana admin tidak menghubungkan primary database dan standby database. Karena alasan tertentu primary database tidak dapat secara otomatis mentransfer archived redo log ke standby database untuk melakukan recovery data. Admin membutuhkan aksi secara manual dalam halrecoveryuntuk memperbaharuistandby database.

2.6.2. Metode Standby Database secara Managed Recovery

Pada metode ini admin dapat menempatkan standby database dengan cara managed recovery. Metode ini mengacu kepada standby database yang secara otomatis menerima archived redo logs dari primary database. Keuntungan utama dari menjalankan metode ini adalah admin tidak harus mentransfer atau menerapkan

12

archived redo logsecara manual. Di bawah ini adalah proses update secara otomatis pada sebuahstandby databasepada gambar 2.2.

Gambar 2.2.Updatesecara otomatis pada sebuahstandby database[Oracle : 1999] 2.6.3. Read-Only Mode untuk Query

Admin juga dapat membukastandby database dalam mode read only setelah manual terminasi atau managed recovery. Pada saat melakukan mode read only,admin dapat melihatquery database bahkan menyimpan data di tablespacesementara selama data sudah di dalam standby database tanpa mempengaruhi file data atau redo log. Kemudian admin dapat mengembalikan standby database untuk mode recovery manual atau managed recovery tanpa harus menutupnya. Berikut adalah proses standby databasedalam moderead onlyyang ada pada gambar 2.3.

13

Dalam lingkunganmanaged standby, standbyserver terus menerimaarchived redo log oleh primary database dan file kontrol trus diperbaharui (update) dengan record yang ada. Akibatnya, pengarsipan terus berlanjut pada server standby, meskipunstandby database tidak melakukanrecoverydalam moderead only.

Standby database yang menggunakan metoderead only berguna ketika admin ingin mengurangi jumlah query yang ada pada primary database. Jika tablespace di dalam sebuah primary database jarang berubah tetapi sering diakses, admin dapat mengarahkan query ke standby database sehingga primary database tidak menjadi overloaddengan permintaan akses.

14

BAB 3

METODOLOGI PENELITIAN

Standby database server merupakan sebuah server yang berfungsi mereplikasi (menyalin) data dari sebuah database untuk menyediakan kontinuitas availability primary database serversaatfailure(rusak) terjadi. Pada penelitian ini akan dilakukan beberapa pengujian yang akan memperlihatkan cara kerja standby database melakukan backup data terhadap primary database dan cara kerja standby database servermenggantikanprimary database serverpada saat terjadi failure.

Pada tesis ini simulasi standby database yang dilakukan adalah dengan menggunakan DBMS MySQL. MySQL adalah sebuah perangkat lunak sistem manajemen basis data SQL yang multithread, multi-user, dengan 6 juta instalasi. MySQL banyak digunakan untuk kepentingan penanganan database karena selain handal juga bersifatopen source. Konsekuensi dari open source, perangkat lunak ini dapat dipakai oleh siapa saja tanpa membayar dan source code-nya bisa diunduh oleh siapa saja. Akan tetapi fungsi standby database tidak dimiliki oleh DBMS MySQL secara default. Sehingga penulis harus membangun aplikasi yang dapat memberikan fungsi yang sesuai dengan konsepstandby databasepada DBMS MySQL.

Pembahasan dalam tesis ini akan menggunakan struktur data inventori pada sebuah gudang supermarket. Aplikasi yang dibangun merupakantools simulasi untuk menganalisa sistem standby database dengan menggunakan metode managed recovery sehingga tidak terlalu memperhatikan faktor pendukung seperti interface yanguser friendly. Aplikasi ini berjalan dengan cara seorangadminmemasukkan data barang dan kemudian menganalisis alur data yang berjalan dari aplikasi input barang menuju keprimary databasehingga kestandby database.

15

3.1. Rancangan Penelitian

Penelitian ini menggunakan metode penelitian eksperimen (Experimental Research). Pengumpulan data dan informasi dengan menggunakan metode observasi yaitu meninjau dan mengamati secara langsung pada server primary database dan server standby database untuk mendapatkan gambaran tentang replikasi yang terjadi pada saat admin melakukan transaksi serta mengamati aktifnya server standby database pada saat serverprimary databaserusak pada lingkungan DBMS MySQL.

3.2. Perangkat dan Data yang digunakan dalam penelitian 3.2.1. Perangkat

Pada penelitian ini alat penelitian yang digunakan berupa perangkat keras dan perangkat lunak sebagai berikut:

a. Perangkat keras (hardware) 1. Satu unitswitch hub.

2. Dua unit personal computer Processor Intel(R) Core(TM)2Duo 1.80 GHz untukdatabase server.

3. Satu unit personal computer Processor Intel(R) Core(TM)2Duo 1.80 GHz untuk klien.

b. Perangkat lunak (software)

1. Sistem Operasi Windows 7 untukdatabase serverdan klien. 2. Microsoft Visual Studio 2010 Professional

3. MySQL untukdatabase server. 4. XAMPP V 1.3.1 Win32

5. Bandwith Meter Pro V 2.6.0

3.2.2. Data yang digunakan

Data yang digunakan pada penelitian ini adalah berupa data acak pada sebuah gudang supermarket yang penulis unduh dari internet.

3.3. Model Jaringan untuk Simulasi

Adapun skenario jaringan untuk pengujian sistem ini adalah seperti pada gambar 3.1. sebagai berikut:

16

Gambar 3.1. Rancangan topologi jaringan yang dibangun untuk simulasi

3.4. Langkah Kerja Jaringan

Secara garis besar alur kerja jaringan ini adalah sebagai berikut:

1. Jaringan ini mempunyai dua server, yaitu server untuk primary database dan server untuk standby database. Dan satu klien yang bertindak sebagai admin pergudangan.

2. Pada saat admin pergudangan ingin meng-input data barang maka sistem akan secara otomatis mengirim data tersebut ke server primary database. Setiap data yang berada di dalam primary database akan dimasukkan ke dalam tabel_log dan kemudian akan dikirimkan kestandby databasedalam proses replikasi data. 3. Topologi jaringan yang digunakan adalah topologi star untuk semua jaringan.

Dan pada setiap jaringan akan diberikan IP Static kelas C yang akan menghubungkan ketiga jaringan.

3.5. Variabel Penelitian

Variabel dalam penelitian ini terdiri dari variabel dependen (terikat) dan variabel independen (bebas). Variabel yang nilainya terikat tergantung dari variabel lain. Variabel terikat pada penelitian ini adalah waktu respon (Y). Waktu respon adalah waktu perjalanan data dari sebuah server database menuju server database lainnya pada proses replikasi. Atribut yang mempengaruhi waktu respon dalam penelitian ini adalah waktu respon danthroughput.

Sedangkan variabel bebas adalah yang nilainya tidak tergantung pada nilai variabel lain. Variabel bebas pada penelitian ini yaitu incremental backup (X). incremental backup menyalin file yang telah berubah sejak terakhir backup dibuat.

17

Keuntungan utama untuk backup secara incremental yaitu file yang lebih sedikit disalin sehingga prosesbackupberjalan dengan cepat.

3.6. Proses Penelitian

Proses penelitian ini meliputi pengumpulan data, perancangan skenario simulasi, pembuatan eksperimen simulasi berdasarkanflowchart, dan analisa data.

3.6.1. Analisa Data

Analisa data dilakukan melalui penelitian laboratorium dengan membuat jaringan yang terisolasi menggunakan 1 (satu) unitswitchdan 2 (dua) unitdatabase serverdan 1 (satu) unit klien sesuai topologi yang dirancang untuk bisa mewakili jaringan nyata dan juga diuji sesuai skenario simulasi yang dilakukan dengan beberapa kondisi dan kemudian melakukan pengujian waktu yang diperlukan untuk mereplikasi dan throughputyang dimiliki pada saat replikasi terjadi.

3.6.2. Rancangan Skenario Simulasi

Skenario simulasi pengujian secara umum terdiri atas dua bagian yaitu pengujian tentang replikasi (logging) dan pengujian failover. Sebagai langkah awal masing-masing laptop harus terhubung secaraLocal Area Network (LAN) pada kelas Internet Protocol(IP) yang sama. Pada proses terjadinya replikasi, awalnya admin menginput data yang ditujukan untuk primary database. Setelah itu admin mengaktifkan real time logginguntuk mereplikasi data dari primary databaseke standby database.Real time logging bertugas untuk membaca setiap perubahan yang terjadi pada primary database. Semua perubahan baik ituinputdata baru, edit, ataupundeleteyang tercatat pada real time logging akan diaplikasikan kepada standby database. Kemudian real time logging akan memeriksa kembali apakah ada perubahan data lainnya di dalam server primary database. Jika ada maka proses pereplikasian data masih akan terus terjadi. Hal ini akan terus terjadi hinggareal time loggingmenyatakan bahwaprimary database sudah tidak melakukan perubahan baik itu input data, edit data, ataupun deletedata.

Secara default user akan mengakses data melalui primary database. Hal ini akan terus terjadi apabila primary database selalu dalam keadaan normal. Namun

18

apabila primary database mengalami kerusakan (failure), maka standby database akan menggantikan fungsiprimary database.Standby databasemenjamin bahwa data yang dimiliki tidak akan hilang ketika primary database rusak. Hal ini disebabkan karena setiap transaksi yang terjadi antara klien danprimary database akan langsung direplikasikan ke server standby database dengan cara mengumpulkan log file di dalam archived log. Selama primary database dalam perbaikan, maka semua klien masih dapat mengakses data secara normal menggunakan standby database. Proses pengalihan (switch) standby database menjadi primary database disebut failover. Failover diaktifkan oleh seorang admin pada saat server primary database rusak. Untuk melihat gambaran kerja replikasi serta failover yang terjadi di dalam proses standby databasedapat dilihat pada gambar 3.2.

19

Berikut adalahpseudocodedari metodeincremental backup: a. Level 0 mem-backupsemua blok

b. Incremental Level 1 mem-backup blok yang telah berubah pada Level 1, 0 terakhir

c. Incremental Level 2 mem-backup blok yang telah berubah pada Level 2, 1, 0 terakhir

d. Incremental Level 3 mem-backup blok yang telah berubah pada Level 3, 2, 1, 0 terakhir

e. IncrementalLevel 4 mem-backupblok yang telah berubah pada Level 4, 3, 2, 1, 0 terakhir

f. Incremental Level n mem-backup blok yang telah berubah pada Level n – _{1, 0}

terakhir

Untuk dapat mengetahui gambaran umum proses standby database dapat dilihat pada gambar 3.3.

Gambar 3.3. Prosesstandby database

Klien mengambil atau menginput data melalui primary database. Data yang di-input ke primary database tereplikasi ke standby database. Pada saat primary database rusak, standby database langsung menggantikan kerja sistem primary database. Sehingga klien melakukan transaksi data ke standby database. Proses transaksi data kembali keprimary databasepada saatprimary databasedapat berjalan secara normal. Serta data yang ada pada standby database kembali direplikasi ke primary database.

Replikasi pada saat Primary databasetelah

menjadistandby database yang baru

Pengambilan data pada saat

Primary Databasemati Pengambilan

data pada saat Primary Databaseaktif

Primary Database Standby Database

client replikasi

20

Proses replikasi yang terjadi antara primary database dan standby database hingga aktifnya redo logs di dalam standby database jika primary database mengalami kerusakan seperti pada gambar 3.4.

3.4. Skema dari sistemstandby database

Penjelasan dari Gambar 3.4. Skema dari sistem standby database di atas adalah sebagai berikut :

a. Primary Database

Primary database akan menulis data ke Redo logs. Kemudian isi dari Redo Logs akan dituliskan ke Archived Logs. Lalu Archived Logs tersebut akan di-copy ke Archived Logs dalam standby database jika logtime dalam keadaan aktif. Pada simulasi ini tabel yang ada padaprimary databaseadalah sebagai berikut:

- tbl_barang adalah tabel yang berisikan data barang yang di-inputi oleh admin. Ada 3 bagian penting yang harus terdaftar pada data barang yaitu kode barang, nama barang dan harga.

- tbl_log ialah table yang berfungsi untuk menyimpan dan mengumpulkan log yang tercipta dari transaksi data.

- tbl_server adalah tabel yang menyimpan beberapa data yang dimiliki oleh calon standby database, diantaranya adalahIP Address,username,password, dan juga databaseyang dimiliki oleh serverstandby database.

- tbl_status berfungsi untuk memberikan informasi kepada admin bahwa server telah tersambung dengan baik atau tidak terhadap aplikasi.

Primary database

Redo Logs

Archive Logs

User

Standby database

Redo Logs

21

- tbl_trans yaitu tabel yang mencatat jumlah barang yang terdapat di dalam gudang.

b. Standby Database

Archived Logyang sudah di-copydariprimary database, akan dituliskan keArchieved Logsdistandby database. Lalu Redo Logsdistandby databasehanya akan digunakan jika primary database mati. Standby database memiliki tabel yang mutlak sama denganprimary database. Ini karenastandby databasemerupakandatabasepengganti apabila primary database rusak secara tiba-tiba. Oleh karena itu pada saat primary database aktif,standby databasemelakukan backup data secara tersinkronisasi.

c. Redo Log Files

Redo log files digunakan sebagai tempat catatan setiap transaksi yang terjadi. Fungsi utama redo log files digunakan untuk kebutuhan proses recovery. Jika pada saat database mengalami kegagalan dan data yang diperbaharui belum tersimpan di data file, redo log files akan melakukan recovery data yang telah diperbaharui dan mengembalikan posisi transaksi terakhir saat database belum mengalami kegagalan.

Setiap transaksi yang dilakukan olehadminyang menuju ke primary database akan disimpan pada sebuah redo log dan kemudian dikumpulkan oleh archive logs dan kemudian direplikasi ke standby database. Redo log yang berfungsi untuk menyimpan log yang dikirimkan dariprimary databasedapat dilihat pada gambar 3.5.

22

Redo Log Buffer yang berisi cache redo informasi digunakan pada saat terjadinyarecoverymenyimpan parsed version DDL (Data Definition Language) dan DML (Data Manipulation Language) sebelum di-flush ke log file. DML adalah kumpulan perintah SQL yang berhubungan dengan pekerjaan mengolah data di dalam tabel. Sedangkan DDL adalah kumpulan perintah SQL yang dapat digunakan untuk membuat dan mengubah struktur dan definisi tipe data dari objek-objek database seperti tabel, index,triggerdanview.

Pada simulasi yang penulis lakukan dengan menggunakan DBMS MySQL, archived log file disimulasikan dengan sebuah tabel log yang mencatat seluruh kegiatan data yang terjadi diantara admin dan primary database. Isi dari tabel log adalah sebagai berikut:

• Id_log sebagai primary key, yang berfungsi untuk memberikan nomor id setiap terjadinya transaksi data secara terurut.

• Log_tabel ialah log yang memberikan informasi tentang asal tabel yang merupakan tempat data melakukan transaksi data.

• Log_date adalah log yang mencatat tanggal terjadinya transaksi data antara admindenganprimary database.

• Log_time yaitu log yang mencatat waktu respon yang dimiliki standby database dalam mereplikasi data yang ada padaprimary database.

• Log_query adalah log yang mencatat transaksi yang dilakukan oleh admin terhadap primary database baik itu berupa data masukan, edit maupun hapus. Apabila data yang telah di-input mengalami perubahan oleh admin, maka log_query akan mencatat perubahan tersebut dengan log yang berbeda. Artinya log yang berisikan tentang informasi admin meng-input barang tidak akan di hapus apabila data barang tersebut mengalami perubahan kedepannya.

• Log_status ialah log yang mencatat status data yang ada pada primary database tereplikasi kestandby databaseatau tidak.

Log file adalah file yang mencatat peristiwa yang terjadi dalam pelaksanaan sistem untuk memberikan jejak audit yang dapat digunakan untuk memahami aktivitas sistem dan untuk mendiagnosis masalah. Prosesnya adalahDatabase Writer (DBWR) bertugas untuk menuliskan data yang berubah ke data file. Kumpulan dari data file tersebut disimpan di dalam buffer cache. Log Writer (LGWR) berfungsi

23

memindahkan isi redo log buffer ke redo log file. Proses log file dapat dilihat pada gambar 3.6.

Pada log file terjadi proses checkpoint yaitu proses ketika DBWR menulis data ke dalam datafile.Checkpointdilakukan apabila:

a. Log switch.

b. Alter tablespacexxxoffline/read only. c. Shutdownselainabort.

d. Database bufferpenuh.

Selanjutnya diimplementasikan tiga model skenario simulasi dalam penelitian ini. Ketiga simulasi tersebut dititikberatkan pada jumlah waktu respon yang dihasilkan pada saatprimary databasedanstandby databasemelakukan proses replikasi.

3.6.2.1. Skenario I, Primary Database dan Standby Database berada dalam keadaan normal

Pada skenario I ini primary database dan standby database berada dalam kondisi hidup dan koneksi yang terhubung diantaranya (termasuk juga ke klien) dalam keadaan hidup. Skenario simulasi I bertujuan untuk melihat primary database melakukan proses replikasi dengan metode incremental backup terhadap standby database. Hipotesa pada simulasi ini, proses replikasi akan berjalan secara real time. Hal ini dapat terjadi karena metode incremental backup bekerja dengan mereplikasi data yang diinput maupun dimanipulasi pada waktu yang hanya berselang dengan ukuranms.

Posisi saat ini

Dibutuhkan untuk Recovery Incremental Checkpoint

24

Simulasi ini akan dihitung jumlah waktu dan throughput saat primary database melakukan replikasi ke standby database yang keduanya dalam keadaan normal.

3.6.2.2. Skenario II, Standby Database dalam keadaan normal tetapi Primary Database mati dalam keadaan proses menginput data

Sedangkan pada skenario II,primary database,standby databasedan klien terkoneksi ke jaringan secara normal. Kemudian primary database akan dimatikan secara tiba-tiba. Kondisi ini dibuat untuk melihat proses aktifnya failover di dalam standby database sehingga secara langsung dapat menggantikan primary database sehingga klien dapat tetap mengakses data. Pada saat standby database melakukan switching, standby databaseakan menjadiprimary databaseyang baru.

3.6.2.3. Skenario III, Primary Database dalam keadaan normal tetapi dengan Standby Database yang baru

Skenario III mewakili proses terbentuknya standby database yang baru. Karena standby database yang lama telah menjadi primary database yang baru dan terjadi kevakuman standby database. Dimana pada saat admin tetap melakukan transaksi data pada primary database namun dengan kondisi belum ada standby database. Skenario ini log file akan terkumpul di archived log menunggu untuk dikirimkan ke standby database. Saat standby database yang baru dapat beroperasi kembali, dibutuhkan waktu untuk mensinkronkan data yang ada pada primary database ke standby database. Sehingga penulis akan menghitung jumlah waktu yang dibutuhkan oleh standby database untuk melakukan replikasi terhadap primary database karena pada saat standby database mati data pada primary database akan tetap terus bertambah.

25

BAB 4

HASIL DAN PEMBAHASAN

4.1. Parameter ReplikasiDatabasepada 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

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

BAB 5

KESIMPULAN DAN SARAN

5.1. Kesimpulan

Berikut adalah beberapa kesimpulan yang penulis ambil dari penelitian ini:

1. Replikasi yang dilakukan dengan menggunakan metode incremental backup sangat baik di terapkan di dalam sistem standby database. Karena mampu menghasilkan waktu respon yang begitu kecil dan throughput yang besar. Dalam simulasi penelitian ini rata-rata waktu respon yang dibutuhkan untuk mereplikasikan data per operasi yang ada pada primary database ke standby databaseadalah 0,6Sdanthroughputsebesar 5kbps.

2. Dalam suatu transaksi data, jika primary database mengalami failure (rusak) maka standby database akan menjadi primary database dengan proses failover. Dapat dilihat pada simulasi II, standby database berhasil melakukan failover terhadap primary database yang rusak. Dengan mengaktifkan menu

“transform to primary”, fungsi primary database diambil alih oleh standby database. Sehingga data dapat terus diakses walaupun primary database mengalami kerusakan.

3. Setelah terjadinya failover, dibutuhkan sebuah server standby database yang baru. Untuk mensinkronkan server standby database yang baru dengan primary database dilakukan teknik initiate standby database yang dilakukan dengan metodefull backup. Dapat dilihat pada simulasi III, proses sinkronisasi standby database terhadap primary database dengan jumlah 106 record menghasilkan waktu 17 s.

41

5.2. Saran

Penulis memiliki kekurangan dalam hal kemampuan dan waktu yang dimiliki pada penelitian ini. Berikut adalah saran yang berguna untuk pengembangan penelitian selanjutnya:

1. Pada penelitian ini, failover dilakukan dengan cara mengaktifkan menu

“transform to primary”. Hal ini dilakukan karena DBMS MySQL belum

memiliki fungsi failover secara built in. Setelah failover berhasil, IP server pada aplikasi pergudangan harus di setting kembali menuju primary database yang baru. Pada pengembangan selanjutnya diharapkan dapat menemukan cara yang lebih baik dalam mengaktifkanfailover.

2. Untuk membuat sebuah failover yang dapat bekerja secara otomatis dapat dilakukan dengan menggunakaninternet control message protocol.

DAFTAR PUTAKA

Connolly, T & Beag, C. 2002.Database System: A Practical Approach in Design, Implementation, and Management. Third Edition. Addisson Wesley. Gregory, P. 2009. CISA Exam Guide: All-in-One is All You Need. McGraw-Hill

Osborne: New York.

Hoffer, J.A, Prescott, M.B, Topi, H. 2005. Modern Database Management. Seventh Edition. Pearson Education Inc.

Noraziah, A. 2012. Replication Techniques in Data Grid Environment. Lecture Notes in Computer Science Volume 7197, 2012, pp 549-559.

Navathe, S.B & Elmasri, R. 2011. Fundamentals of Database Systems. Sixth Edition. Pearson Education Inc: Massachusets.

Oracle. 1999. Oracle8i Standby Database Concepts and Administration. http://docs.oracle.com/cd/A84870_01/doc/server.816/a76995/standbyc.ht m (05 Agustus 2013).

Qian, C, Huang, Y, Zhao, X, Nakagawa, T. 2010. Optimal Backup Policies for a Database System with Periodic Incremental Backup. Proceedings of the 2009 International Symposium on Information Processing (ISIP’09), pp. 281-285

Radulescu, S.B. 2002. High Availability Solution for a Transactional Database System. Tesis. Universitas Concordia. Canada.

Smith, D.M. 2003. The Cost of Lost Data.Graziadio Business Review, September: 20-23.

Singh, S, Rishi, R, Taneja, G, Manocha, A. 2013. Reability and Avaibility Analysis of Database System with Standby Unit Provide by the System Provider. International Journal of Soft Computing and Engineering (IJSCE)3: 235-237.

Tawar & Wahyuningsih, S. 2011. Pembandingan Metode Back Up Database My SQL antara Replikasi dan MySQLDump. Jurnal Sistem Informasi Indonesia1: 45-52.

43

Wibowo, A, Darmantoro, D, Kusumo, D.S. 2007. Analisis dan Implementasi Standby Database dengan Oracle (Studi kasus: Backup Standby Database pada Perusahaan Jasa Komunikasi). Prosiding Seminar Nasional Aplikasi Teknologi Informasi 2007, pp. E-7–_E-10.

Wiesmann, M, Pedone, F, Schiper, A, Kemme, B, Alonso, G. 2000. Database Replication Techniques: a Three Parameter Classification. Proceedings The 19th IEEE Symposium, pp. 206 - 215.

Waliyanto. 2000. Sistem Basis Data Analisis dan Pemodelan Data. Yogyakarta: J&J Learning.

DAFTAR PUBLIKASI ILMIAH PENULIS (TESIS)

No. Judul Artikel Penulis

Publikasi (Seminar, Jurnal dll) Waktu Publikasi Tempat 1. 2. Replikasi pada Standby Database Menggunakan Metode Incremental Backup Otomatisasi Failoverpada Standby Database menggunakan Internet Control Message Protocol (ICMP) Defry Hamdhana Defry Hamdhana, Muh. Iqbal (Jurnal Teknik Elektro-2014) Jurnal (SNASTIKOM-2014) Proceeding Januari 27, 2014 Maret 12, 2014 Lhokseumawe-Indonesia Medan-Indonesia

LAMPIRAN

DAFTAR PUBLIKASI ILMIAH PENULIS (TESIS)

No. Judul Artikel Penulis

Publikasi (Seminar, Jurnal dll) Waktu Publikasi Tempat 1. 2. Replikasi pada Standby Database Menggunakan Metode Incremental Backup Otomatisasi Failoverpada Standby Database menggunakan Internet Control Message Protocol (ICMP) Defry Hamdhana Defry Hamdhana, Muh. Iqbal (Jurnal Teknik Elektro-2014) Jurnal (SNASTIKOM-2014) Proceeding Januari 27, 2014 Maret 12, 2014 Lhokseumawe-Indonesia Medan-Indonesia