BAB IV IMPLEMENTASI DAN PENGUJIAN Bab ini membahas tentang implementasi dan pengujian perangkat lunak yang dibangun pada tugas akhir ini. Implementasi akan dibahas pada Subbab 4.1, sedangkan pengujian akan dibahas pada Subbab 4.2.
4.1 Implementasi Pada Subbab Implementasi akan dijelaskan mengenai batasan implementasi, lingkungan perangkat keras dan perangkat lunak, serta implementasi yang dilakukan berdasarkan perancangan. Penjelasan pada Subbab
ini meliputi lingkungan
pengembangan yang digunakan, batasan implementasi, serta proses dan hasil implementasi.
4.1.1 Lingkungan Pengembangan Aplikasi ini dikembangkan dengan spesifikasi perangkat keras dan perangkat lunak sebagai berikut: 1. Sistem operasi Windows XP Professional Version 2002 Service Pack 2 2. Prosesor Intel Pentium 4 2.40 GHz 3. RAM 1 GB 4. Microsoft Visual Studio 2005 Version 8.0 5. Microsoft 32-bit C/C++ Optimizing Compiler Version 14.00 6. Source code MySQL 5.0.51 7. Apache Ant 1.7.0 8. Java 2 Standard Edition Development Kit Version 5.0 Update 6 9. Java 2 Standard Edition Development Kit Version 6 Update 5 10. Source code MySQL Connector/J 5.1.6
4.1.2 Batasan Implementasi Batasan implementasi dukungan pembentukan koneksi backup dan penanganan failover pada DBMS MySQL adalah sebagai berikut: IV-1
IV-2
Implementasi yang sama belum tentu berjalan dengan baik untuk versi MySQL yang berbeda, terutama apabila terdapat banyak perubahan pada paket MySQL dan kelas THD.
4.1.3 Proses dan Hasil Implementasi Pengembangan aplikasi terdiri dari beberapa tahap, yaitu imple mentasi penanganan pembentukan koneksi backup dan implementasi pengalihan state dan resource antar thread pada pemutusan koneksi.
4.1.3.1 Implementasi Penanganan Pembentukan Koneksi Baru Ketika terjadi pembentukan koneksi dari client ke MySQL server, server akan memeriksa apakah terdapat elemen multimap yang memiliki key yang bersesuaian dengan primary id koneksi tersebut. Jika ditemukan, maka koneksi dengan primary id tersebut sudah mempunyai primary yang telah dibentuk sebelumnya, sehingga koneksi tersebut akan dijadikan backup dari koneksi primary. Jika tidak ditemukan, maka koneksi yang baru terbentuk akan menjadi koneksi primary. Implementasi fisik untuk penanganan pembentukan koneksi baru dilakukan di file mysqld.cc dan sql_parse.cc
pada
MySQL
dan
file
FTJDBC4Connection.java
dan
FTConnectionImpl.java pada MySQL Connector/J.
4.1.3.2 Implementasi Failover pada Pemutusan Koneksi Ketika terjadi pemutusan koneksi, MySQL server akan memeriksa keberadaan koneksi backup pada multimap. Jika ditemukan, sebelum cleanup dieksekusi akan dilakukan transfer state dan resource dari objek THD primary ke objek THD backup. State-state yang ditransfer adalah state mengenai database yang digunakan, lock terhadap tabel, tabel, transaksi, dan handler data yang berasosiasi dengan storage engine yang digunakan. Implementasi fisik penanganan failover dilakukan di file mysqld.cc dan sql_parse.cc pada MySQL.
IV-3
4.2 Pengujian Tujuan dilakukannya pengujian terhadap suatu perangkat lunak adalah untuk mengetahui apakah aplikasi telah berjalan sesuai dengan sasaran pembuata n. Pengujian aplikasi ini dilakukan dengan menguji apakah pembentukan koneksi backup dengan identifier id koneksi primary (primary id) dan penanganan failover berhasil dilakukan tanpa menghilangkan properti ACID dari transaksi. Penjelasan pada Subbab Pengujian meliputi tujuan pengujian, lingkungan pengujian, data uji, kasus uji, dan analisis hasil pengujian. Terdapat dua kasus utama yang akan digunakan untuk pengujian aplikasi, yaitu kasus uji pembentukan koneksi backup dan kasus uji failover pada pemutusan koneksi.
4.2.1 Tujuan Pengujian Terdapat beberapa hal yang menjadi tujuan pengujian terhadap perangkat lunak yang dikembangkan ini, yaitu: 1. Memeriksa apakah pembentukan koneksi backup dapat ditangani dengan baik setelah dilakukan perubahan pada MySQL Connector/J. 2. Memeriksa apakah perubahan yang dilakukan pada MySQL server tidak mengganggu konsistensi database dan properti ACID dari transaksi.
4.2.2 Lingkungan Pengujian Aplikasi ini diuji dengan spesifikasi perangkat keras dan perangkat lunak sebagai berikut : 1. Sistem operasi Windows XP Professional Version 2002 Service Pack 2 2. Prosesor Intel Pentium 4 2.40 GHz 3. RAM 1 GB 4. MySQL 5.0.51 5. Java 2 Runtime Environment Version 6 Update 5 6. MySQL Connector/J 5.1.6 7. Program uji yang dibangun oleh penulis
IV-4
4.2.3 Data Uji Data yang digunakan untuk pengujian adalah tabel account dengan kondisi awal tabel seperti pada tabel berikut. Tabel IV-1 Tabel Account Number
Balance
5
4000
6
5000
7
7000
4.2.4 Kasus Uji Pembentukan Koneksi Backup Kasus uji pembentukan koneksi backup dilakukan untuk menguji kebenaran perilaku MySQL server saat terjadi pembentukan koneksi baru. Untuk mempermudah pengujian, program uji akan menerima masukan primary id dan user.
4.2.4.1 Skenario Pembentukan Koneksi Backup dengan Primary Id yang Invalid Langkah- langkah yang dilakukan pada skenario ini adalah sebagai berikut: 1. Client pertama login dengan primary id 0 dan user name1 Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1. 2. Client kedua login dengan primary id id2 dan user name2 Client kedua teridentifikasi sebagai koneksi yang tidak valid karena tidak terdapat koneksi dengan primary id id2. Selanjutnya, MySQL server akan melakukan pemutusan koneksi client kedua.
4.2.4.2 Skenario Pembentukan Koneksi Backup dengan Primary Id yang Valid dan Nama User yang Invalid Langkah- langkah yang dilakukan pada skenario ini adalah sebagai berikut: 1. Client pertama login dengan primary id 0 dan user name1
IV-5
Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1.
2. Client kedua login dengan primary id id1 dan user name2 Client kedua teridentifikasi sebagai koneksi yang tidak valid karena user-nya berbeda dengan user pada client pertama. Selanjutnya, MySQL server akan melakukan pemutusan koneksi client kedua.
4.2.4.3 Skenario Pembentukan Koneksi Backup dengan Primary Id yang Valid dan Nama User yang Valid Langkah- langkah yang dilakukan pada skenario ini adalah sebagai berikut: 1. Client pertama login dengan primary id 0 dan user name1 Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1. 2. Client kedua login dengan primary id id1 dan user name1 Client kedua teridentifikasi sebagai backup dari client pertama.
4.2.5 Kasus Uji Failover pada Pemutusan Koneksi Kasus uji failover dari client primary ke backup dilakukan untuk menguji kebenaran perilaku MySQL server saat terjadi pemutusan koneksi. Kegagalan koneksi disimulasikan dengan perintah quit atau kill pada program uji.
4.2.5.1 Skenario Satu Primary dan Satu Backup Skenario ini akan menggunakan tabel dan data awal pada Tabel IV-1. Langkahlangkah yang dilakukan pada skenario ini adalah sebagai berikut: 1. Client pertama login dengan primary id 0 dan user name1 Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1. 2. Client kedua login dengan primary id id1 dan user name1 Client kedua teridentifikasi sebagai backup dari client pertama.
IV-6
3. Primary melakukan query berikut INSERT INTO account(balance) VALUES (1000) UPDATE account SET balance = 2000 WHERE number = 5
4. Primary mengalami kegagalan 5. Backup melakukan query be rikut SELECT * FROM account DELETE FROM account WHERE number = 6 COMMIT
Tabel IV-2 Hasil Akhir Skenario Pertama Number
Balance
5
2000
7
7000
8
1000
4.2.5.2 Skenario Failover Beruntun Skenario ini akan menggunakan tabel dan data awal pada Tabel IV-1. Langkahlangkah yang dilakukan pada skenario ini adalah sebagai berikut. 1. Client pertama login dengan primary id 0 dan user name1 Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1. 2. Client kedua login dengan primary id id1 dan user name1 Client kedua teridentifikasi sebagai backup pertama dari client pertama. 3. Client ketiga login dengan primary id id1 dan user name1 Client ketiga teridentifikasi sebagai backup kedua dari client pertama. 4. Primary melakukan query berikut INSERT INTO account(balance) VALUES (1000) UPDATE account SET balance = 2000 WHERE number = 5
5. Primary mengalami kegagalan 6. Backup pertama melakukan query berikut SELECT * FROM account DELETE FROM account WHERE number = 6
7. Backup pertama me ngalami kegagalan
IV-7
8. Backup kedua melakukan query commit
Tabel IV-3 Hasil Akhir Skenario Kedua Number
Balance
5
2000
7
7000
8
1000
4.2.5.3 Skenario Failover pada Dua Grup Skenario ini akan menggunakan tabel dan data awal pada Tabel IV-1. Langkahlangkah yang dilakukan pada skenario ini adalah sebagai berikut: 1. Client pertama login dengan primary id 0 dan user name1 Client pertama teridentifikasi sebagai primary. Pada proses handshaking, primary id client pertama di-assign oleh MySQL server menjadi id1. 2. Client kedua login dengan primary id id1 dan user name1 Client kedua teridentifikasi sebagai backup dari client pertama. 3. Client ketiga login dengan primary id 0 dan user name2 Client ketiga teridentifikasi sebagai primary. Pada proses handshaking, primary id client ketiga di-assign oleh MySQL server menjadi id2. 4. Client keempat login dengan primary id id2 dan user name2 Client keempat teridentifikasi sebagai backup dari client ketiga. 5. Primary pertama melakukan query berikut INSERT INTO account(balance) VALUES (1000) UPDATE account SET balance = 2000 WHERE number = 5
6. Primary kedua melakukan query berikut SELECT * FROM account INSERT INTO account(balance) VALUES (3000)
7. Primary pertama mengalami kegagalan 8. Backup dari primary pertama melakukan query berikut DELETE FROM account WHERE number = 6 ROLLBACK
9. Primary kedua mengalami kegagalan 10. Backup dari primary kedua melakukan query commit
IV-8
Tabel IV-3 Hasil Akhir Skenario Ketiga Number
Balance
5
4000
6
5000
7
7000
9
3000
4.2.6 Analisis Hasil Pengujian Pada Subbab Analisis Hasil Pengujian ini akan dibahas mengenai skenario pada kasus uji yang dijelaskan pada Subbab 4.2.4 dan 4.2.5. Kasus uji pertama pada Subbab 4.2.4 digunakan untuk menguji penanganan pembentukan koneksi baru dengan parameter primary id dan user, sedangkan kasus uji kedua pada Subbab 4.2.5 digunakan untuk menguji failover pada pemutusan koneksi.
Skenario pertama (Subbab 4.2.4.1) dirancang untuk menguji apakah MySQL server dapat mengetahui role suatu koneksi berdasarkan primary id yang dikirimkan oleh client. Pada skenario ini, client pertama berhasil diidentifikasi sebagai koneksi primary karena mengirimkan primary id bernilai 0. Client kedua diidentifikasi sebagai koneksi yang tidak valid karena mengirimkan primary id bernilai id2, padahal belum terdapat koneksi primary yang memiliki primary id bernilai id2.
Skenario kedua (Subbab 4.2.4.2) dirancang untuk menguji apakah MySQL server dapat memeriksa validitas koneksi backup berdasarkan user yang dikirimkan oleh client. Pada skenario ini, client kedua diidentifikasi sebagai koneksi backup dari client pertama yang tidak valid karena mengirimkan user yang berbeda dengan user client pertama.
Skenario ketiga (Subbab 4.2.4.3) dirancang untuk menguji apakah MySQL server dapat mengetahui role suatu koneksi dan validitas koneksi backup. Pada skenario ini, client kedua berhasil diidentifikasi sebagai koneksi backup yang valid dari client
IV-9
pertama karena mengirimkan primary id sesuai primary id client pertama dan user sesuai user client pertama.
Skenario keempat (Subbab 4.2.5.1) dirancang untuk menguji failover sederhana di mana terdapat satu primary dan satu. Query select * from account pada langkah kelima digunakan untuk memeriksa apakah state transaksi yang belum di-commit oleh primary dapat dilihat oleh backup. Skenario ini juga menguji property consistency, durability, dan atomicity pada transaksi di mana data yang telah di-commit langsung tersimpan ke disk dan seluruh statement transaksi tereksekusi.
Skenario kelima (Subbab 4.2.5.2) dirancang untuk menguji failover beruntun pada satu grup client. Pengujian ini perlu dilakukan untuk memeriksa apakah strategi primary-backup dapat berjalan dengan baik untuk kasus kegagalan yang beruntun. Skenario ini menggunakan tiga client yang melakukan koneksi ke server. Client pertama menjadi primary, kemudian client kedua dan ketiga menjadi backup. Apabila client pertama mengalami kegagalan, maka client kedua akan menjadi primary dan client ketiga akan menjadi backup dari client kedua, kemudian apabila client kedua yang sekarang menjadi primary mengalami kegagalan, client ketiga dapat melakukan failover untuk menggantikan posisi client kedua. Hasil akhir skenario kedua pada Tabel IV-3 menunjukkan keberhasilan implementasi untuk skenario failover beruntun.
Skenario keenam (Subbab 4.2.5.3) dirancang untuk menguji properti isolation dari transaksi. Skenario ini menggunakan empat client yang tergabung di dalam dua grup. Client pertama dan kedua menjadi primary dan backup untuk grup pertama, sedangkan client ketiga dan keempat menjadi primary dan backup untuk grup kedua. Query select * from account pada langkah keenam menunjukkan bahwa primary dari grup kedua tidak dapat mengetahui state sementara dari grup pertama yang menandakan keberhasilan isolasi transaksi.
