Variabel Penelitian Proses Penelitian

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 ke standby database dalam 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 dan throughput. 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. Universitas Sumatera Utara Keuntungan utama untuk backup secara incremental yaitu file yang lebih sedikit disalin sehingga proses backup berjalan dengan cepat.

3.6. Proses Penelitian

Proses penelitian ini meliputi pengumpulan data, perancangan skenario simulasi, pembuatan eksperimen simulasi berdasarkan flowchart , dan analisa data. 3.6.1. Analisa Data Analisa data dilakukan melalui penelitian laboratorium dengan membuat jaringan yang terisolasi menggunakan 1 satu unit switch dan 2 dua unit database server dan 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 throughput yang 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 secara Local 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 logging untuk mereplikasi data dari primary database ke standby database. Real time logging bertugas untuk membaca setiap perubahan yang terjadi pada primary database. Semua perubahan baik itu input data baru, edit, ataupun delete yang 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 hingga real time logging menyatakan bahwa primary database sudah tidak melakukan perubahan baik itu input data, edit data, ataupun delete data. Secara default user akan mengakses data melalui primary database. Hal ini akan terus terjadi apabila primary database selalu dalam keadaan normal. Namun Universitas Sumatera Utara apabila primary database mengalami kerusakan failure, maka standby database akan menggantikan fungsi primary database. Standby database menjamin bahwa data yang dimiliki tidak akan hilang ketika primary database rusak. Hal ini disebabkan karena setiap transaksi yang terjadi antara klien dan primary 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 database dapat dilihat pada gambar 3.2. Gambar 3.2. Flowchart sistem kerja standby database Universitas Sumatera Utara Berikut adalah pseudocode dari metode incremental backup : a. Level 0 mem- backup semua 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. Incremental Level 4 mem-backup blok 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. Proses standby 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 ke primary database pada saat primary database dapat berjalan secara normal. Serta data yang ada pada standby database kembali direplikasi ke primary database. Replikasi pada saat Primary database telah menjadi standby database yang baru Pengambilan data pada saat Primary Database mati Pengambilan data pada saat Primary Database aktif Primary Database Standby Database client replikasi Universitas Sumatera Utara 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 sistem standby 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 pada primary database adalah 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 adalah IP Address, username, password, dan juga database yang dimiliki oleh server standby 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 Archive Logs Universitas Sumatera Utara - tbl_trans yaitu tabel yang mencatat jumlah barang yang terdapat di dalam gudang. b. Standby Database Archived Log yang sudah di-copy dari primary database, akan dituliskan ke Archieved Logs di standby database. Lalu Redo Logs di standby database hanya akan digunakan jika primary database mati. Standby database memiliki tabel yang mutlak sama dengan primary database. Ini karena standby database merupakan database pengganti apabila primary database rusak secara tiba-tiba. Oleh karena itu pada saat primary database aktif, standby database melakukan 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 oleh admin yang 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 dari primary database dapat dilihat pada gambar 3.5. Gambar 3.5. Redo log files Universitas Sumatera Utara Redo Log Buffer yang berisi cache redo informasi digunakan pada saat terjadinya recovery menyimpan 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, trigger dan view. 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 admin dengan primary database. • Log_time yaitu log yang mencatat waktu respon yang dimiliki standby database dalam mereplikasi data yang ada pada primary 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 ke standby database atau 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 adalah Database 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 Universitas Sumatera Utara 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. Checkpoint dilakukan apabila: a. Log switch. b. Alter tablespace xxx offline read only. c. Shutdown selain abort. d. Database buffer penuh. Selanjutnya diimplementasikan tiga model skenario simulasi dalam penelitian ini. Ketiga simulasi tersebut dititikberatkan pada jumlah waktu respon yang dihasilkan pada saat primary database dan standby database melakukan 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 ukuran ms. Posisi saat ini Dibutuhkan untuk Recovery Incremental Checkpoint Gambar 3.6. Proses log file Universitas Sumatera Utara 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 database dan 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 database akan menjadi primary database yang 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. Universitas Sumatera Utara

BAB 4 HASIL DAN PEMBAHASAN