BAB III ANALISIS DAN PERANCANGAN

Transkripsi

1 BAB III ANALISIS DAN PERANCANGAN Fault tolerance merupakan properti sistem yang memungkinkan sistem tersebut tetap beroperasi walaupun terjadi kegagalan pada satu atau beberapa komponennya. Properti fault tolerance tersebut salah satunya didukung oleh kemampuan recovery sistem ketika komponennya mengalami kegagalan. DBMS (Database Management System) merupakan salah satu sistem yang memiliki kemampuan roll-back recovery. Pada keadaan normal, DBMS mampu mengeksekusi perintah maupun serangkaian perintah dalam suatu transaksi. Sebaliknya, jika terjadi kegagalan seperti putusnya koneksi ke database, DBMS akan melakukan roll-back untuk mengembalikan state database ke state semula sebelum terjadi kegagalan. Mekanisme roll-back menyebabkan suatu transaksi yang sedang berlangsung akan di-abort. Segala perubahan terhadap database yang dilakukan oleh transaksi yang di-abort harus diundo dengan mengembalikan state database dan resource yang digunakan oleh transaksi tersebut harus dilepaskan. Pada implementasi saat ini, DBMS menangani setiap koneksi sebagai koneksi yang unik dan independen satu sama lain. Meskipun client memiliki dua buah koneksi ke database di mana salah satu koneksi berfungsi sebagai backup, DBMS akan memperlakukan koneksi backup tersebut sebagai koneksi baru. Selain itu, DBMS tidak menyimpan segala perubahan terhadap database beserta resource yang digunakan oleh transaksi yang di-abort, sehingga koneksi backup tidak dapat melanjutkan transaksi karena tidak mengetahui state terakhir database dan tidak memiliki resource yang diperlukan. Mekanisme DBMS normal ini tidak mendukung replikasi koneksi pada sistem three tier, karena menyebabkan koneksi backup tidak dapat melanjutkan transaksi ketika koneksi primary terputus. Agar suatu koneksi backup dapat mengambil alih eksekusi transaksi dari suatu koneksi yang terputus, DBMS perlu menangani pembentukan koneksi backup dan penyimpanan state database serta resource yang diperlukan ke koneksi. Ketika suatu koneksi terputus, DBMS dapat mengalihkan state database dan resource yang III-1

2 III-2 diperlukan ke koneksi backup sehingga transaksi dapat dilanjutkan seakan-akan tidak terjadi kegagalan koneksi. Berdasarkan identifikasi masalah di atas, diperlukan modifikasi terhadap DBMS agar: 1. DBMS mengetahui role suatu koneksi, primary atau backup, berdasarkan primary_id pada Client Authentication Packet. 2. DBMS dapat mengalihkan state database dan resource dari suatu koneksi primary ke koneksi backup-nya ketika terjadi kegagalan. 3.1 Rancangan Solusi Rancangan solusi untuk masalah di atas dibagi menjadi dua bagian utama, yaitu: 1. Rancangan solusi pembentukan koneksi backup, untuk memberitahu DBMS mengenai role dari suatu koneksi. Pembentukan koneksi backup memerlukan penanganan yang berbeda karena MySQL server memperlakukan setiap koneksi sebagai koneksi yang unik dan tidak berhubungan satu sama lain. Agar MySQL server mengenali role setiap koneksi, akan digunakan suatu id unik sebagai penanda koneksi. Setiap koneksi primary dan backup-nya akan memiliki id koneksi yang sama. Id koneksi ini didapat saat koneksi primary berhasil terbentuk, dan akan diperlukan untuk otentikasi koneksi backup-nya. Rancangan solusi agar MySQL server mengenali role suatu koneksi selengkapnya akan dijelaskan di Subbab Rancangan solusi failover, untuk mengatur pengalihan state database dan resource dari suatu koneksi primary ke koneksi backup. Ketika koneksi terputus di tengah berjalannya suatu transaksi, MySQL server akan melakukan roll-back recovery. Mekanisme roll-back tersebut akan menyebabkan transaksi yang sedang berlangsung di-abort, perubahan state database di-undo, dan resource yang terlibat dalam transaksi tersebut direlease. Informasi terkait transaksi seperti state terakhir database dan resource

3 III-3 yang digunakan tidak disimpan di memory, sehingga tidak dapat diakses oleh koneksi lain. Agar dapat melakukan pengalihan state database dan resource ketika koneksi terputus, MySQL server perlu mengetahui keberadaan koneksi backup dan menyimpan informasi terkait transaksi. Untuk itu diperlukan suatu struktur data global yang berfungsi mendata koneksi yang ditangani oleh server, serta informasi yang dimiliki masing-masing koneksi. Ketika mendeteksi putusnya suatu koneksi, server akan mencari koneksi backup di struktur data tersebut, jika ditemukan kemudian server akan mengalihkan state database dan resource ke koneksi backup. Rancangan solusi failover selengkapnya akan dijelaskan di Subbab dan Asumsi Ada beberapa asumsi yang diberikan dalam pembuatan rancangan solusi: 1. Failover di sisi client sudah ditangani (client backup mengetahui bahwa primary mengalami crash, mengetahui state terakhir primary, dan meneruskan transaksi yang terputus). Penanganan failover di sisi client telah banyak diimplementasikan pada library manajemen proses seperti JGroups [JGR07]. JGroups dapat mendeteksi serta menangani removal anggota grup proses yang mengalami crash, lalu mengirim notifikasi secara reliable multicast, sehingga grup tersebut mengetahui anggota mana yang mengalami crash. 2. Mekanisme passing informasi id dari client primary ke backup tidak akan dirancang secara spesifik. Terdapat beberapa mekanisme passing yang mungkin diimplementasikan, misalnya menggunakan file eksternal, melalui koneksi TCP/IP, atau output pada monitoring device.

4 III Rancangan Solusi Koneksi Backup Id unik penanda koneksi untuk penanganan koneksi backup didefinisikan sebagai thread_number pada Handshake Initialization Packet yang dikirimkan server ke client saat inisialisasi koneksi. Thread_number merupakan id thread server yang akan menangani setiap koneksi client. Pada implementasi thread_number sebagai id unik penanda koneksi, suatu koneksi primary dapat tercatat sebagai backup pada MySQL server ketika telah terjadi perulangan thread_number. MySQL mengalokasikan 4 byte untuk thread_number, sehingga setelah pembentukan koneksi ke , thread_number akan dimulai kembali dari awal. Kesalahan pencatatan tersebut mungkin terjadi ketika terdapat koneksi primary dengan suatu id koneksi tertentu yang sama dengan thread_number dari suatu koneksi primary yang baru dibentuk. Pada kasus tersebut, koneksi yang baru akan dianggap sebagai backup. Namun kesalahan tersebut sangat kecil kemungkinannya untuk terjadi karena keterbatasan MySQL dalam penanganan koneksi. MySQL server mampu menangani sampai dengan thread. Dengan demikian kesalahan pencatatan hanya mungkin terjadi jika terdapat koneksi primary yang terhubung ke MySQL server dalam waktu sangat lama. Untuk mengimplementasikan solusi di mana thread_number digunakan sebagai id koneksi, diperlukan atribut tambahan pada kelas ConnectionImpl untuk menyimpan id koneksi tersebut. Pada pembentukan koneksi primary, atribut tersebut akan diassign oleh method getthreadid dari kelas MysqlIO saat proses handshaking dengan MySQL server. Setelah koneksi primary terbentuk, pada pembentukan koneksi backup akan disisipkan id koneksi pada Client Authentication Packet agar MySQL server mengetahui bahwa koneksi yang sedang dibentuk merupakan backup dari suatu koneksi primary dengan id koneksi tersebut. Agar MySQL server mengenali id koneksi tersebut, diperlukan modifikasi pada fungsi otentikasi client.

5 III Struktur Data Saat terjadinya kegagalan pada koneksi primary, informasi mengenai koneksi tersebut harus dapat diakses oleh koneksi backup. Untuk mempermudah pengaksesan informasi tersebut, setiap koneksi yang terbentuk akan disimpan di MySQL server dalam suatu struktur data multimap, dengan id koneksi bertipe ulong sebagai key dan objek THD yang merupakan deskriptor koneksi sebagai value. Value kedua dan setelahnya pada multimap merupakan backup dari value pertama dengan key yang bersesuaian. key value 1 value 2 id_koneksi-1 id_koneksi-2 id_koneksi-n THD (primary) THD (primary) THD (backup) Gambar III-1 Struktur data multimap Ketika mendeteksi terjadinya pemutusan koneksi, MySQL server akan membereskan semua informasi terkait koneksi tersebut dari memory lalu mematikan thread yang menangani koneksi tersebut. Agar suatu transaksi yang sedang berlangsung tidak dibatalkan, MySQL server dapat mengetahui keberadaan backup untuk koneksi tersebut dengan mencari di multimap di atas. Jika ditemukan objek THD backup yang id koneksinya bersesuaian dengan id koneksi dari koneksi yang terputus, maka akan dilakukan transfer state. State yang ditransfer merupakan atribut objek THD yang penting untuk melanjutkan transaksi seperti kelompok lock, database, transaksi, dan handler data. Struktur data multimap ini akan diimplementasikan di file sql_parse.cc pada MySQL Rancangan Protokol Komunikasi MySQL Connector/J dan MySQL Setiap kali mendeteksi adanya koneksi dari client, MySQL server akan melakukan identifikasi dengan mengirimkan Handshake Initialization Packet yang berisi protocol_version, server_version, scramble_buff, server_capabilities,

6 III-6 server_language, server_status, dan thread_number. Pada pembentukan koneksi primary, thread_number tersebut akan disimpan sebagai id koneksi. Selanjutnya, client akan mengirimkan Client Authentication Packet yang terdiri dari client_flags, max_packet_size, charset_number, primary_id, user, scramble_buff, dan database_name. Primary_id merupakan field untuk merepresentasikan id koneksi yang disisipkan pada Client Authentication Packet. Client Authentication Packet dirancang agar maksimal terdiri dari 128 byte, yaitu 4 byte header dan 124 byte body, sehingga penyisipan primary_id akan mengakibatkan pemotongan sejumlah byte filler. Pada koneksi primary, primary_id identik dengan thread_number, sehingga primary hanya perlu mengirimkan null. Sebaliknya, koneksi backup harus meminta id koneksi dari primary melalui suatu fungsi getter yang disediakan oleh koneksi. Fungsi getter tersebut akan diimplementasikan di kelas com.mysql.jdbc.connectionimpl pada MySQL Connector/J. Tabel III-1 Body dari Client Authentication Packet Bytes Nama Deskripsi Kapabilitas server yang ingin digunakan 4 client_flags 4 max_packet_size oleh client, meliputi server_capabilities pada Handshake Initialization Packet. Jumlah byte maksimum dalam setiap paket untuk client. 1 charset_number Character set yang digunakan. 19 (filler) always 0x00 4 primary_id Id koneksi primary. n (null terminated) user (dikurangi dari 23 byte menjadi 19 byte untuk penyisipan 4 byte primary_id). Identifikasi. (1+x) scramble_buff Password yang telah dienkripsi dengan

7 III-7 Bytes Nama Deskripsi salt dari server (opsional). 1 (filler) always 0x00 - y (null terminated) databasename Nama database yang akan digunakan (opsional). Setelah menerima Client Authentication Packet, MySQL server akan melakukan parsing terhadap paket tersebut. Sebelum melakukan pemeriksaan user dan password dengan fungsi check_user, server akan memeriksa primary_id terlebih dahulu. Jika primary_id dari suatu koneksi berisi null, maka koneksi tersebut akan dianggap sebagai koneksi primary. MySQL server akan membuat elemen multimap baru dengan thread_number dari koneksi sebagai key dan objek THD yang merupakan deskriptor koneksi sebagai value pertama. Jika primary_id dari suatu koneksi tidak null, maka koneksi tersebut akan dianggap sebagai koneksi backup. MySQL server akan memeriksa keberadaan koneksi primary yang akan di-backup dengan mencari di multimap. Jika terdapat elemen multimap yang memiliki key sesuai primary_id, maka objek THD dari koneksi akan ditambahkan sebagai value berikutnya. Sebaliknya, jika server tidak menemukan elemen dengan key tersebut, maka koneksi backup dianggap tidak valid dan akan diputus. Pada koneksi backup, MySQL server akan melakukan pemeriksaan tambahan untuk memastikan user dari koneksi backup sama dengan user dari koneksi primary. Pemeriksaan ini dilakukan untuk menjamin keberlangsungan transaksi, karena setiap user umumnya memiliki hak akses terhadap database yang berbeda dengan user lainnya. Tanpa memperhatikan kesamaan user, suatu transaksi mungkin tidak dapat dilanjutkan karena koneksi backup tidak berhak melakukan perubahan terhadap database, padahal koneksi primary-nya memiliki hak tersebut. Selanjutnya, MySQL server akan melakukan otorisasi user, password, dan database dengan memanggil fungsi check_user.

8 III-8 Rancangan protokol komunikasi MySQL Connector/J dan MySQL diilustrasikan dengan diagram pada Gambar III-2. Implementasi pemeriksaan role koneksi (primary atau backup), update multimap, dan pemeriksaan kesamaan user akan dilakukan di fungsi check_connection pada file sql_parse.cc Rancangan Solusi Failover Reaksi standar MySQL server ketika mendeteksi terjadinya pemutusan koneksi adalah membereskan semua informasi mengenai koneksi tersebut dari memory kemudian mematikan thread yang mengurusi koneksi tersebut. Untuk mencegah suatu transaksi dibatalkan, maka state transaksi tersebut harus tetap disimpan di dalam memory walaupun thread tersebut berhenti sehingga thread lain yang menjadi backup dapat melihat state tersebut dan melanjutkan koneksi. Dengan adanya struktur data multimap yang mendata keberadaan seluruh koneksi, apabila suatu koneksi terputus, server dapat memeriksa keberadaan koneksi backup dan tidak langsung membereskan resource transaksi yang tersimpan di memory. Jika server menemukan koneksi backup, akan dilakukan transfer state dari koneksi primary ke koneksi backup. State yang berkaitan dengan transaksi antara lain kelompok lock, database, transaksi, dan handler data. Transfer state dilakukan sebelum pemanggilan fungsi close_connection yang akan membereskan koneksi TCP dan fungsi end_thread yang akan memanggil destruktor dari objek THD. Implementasi transfer state tersebut akan dilakukan di file sql_parse.cc.

9 III State Diagram Perilaku MySQL Server Berikut state diagram yang menggambarkan perilaku MySQL server dalam menangani suatu koneksi. cek primary id koneksi backup koneksi primary tidak null null koneksi tidak terputus cek validitas primary id eksekusi transaksi dan cek koneksi valid tidak valid koneksi terputus cek kesamaan user tidak sama destruct koneksi tidak ada cek keberadaan backup sama belum aktif selesai ada menunggu aktif transfer state dan resource ke backup aktif Gambar III-2 State diagram perilaku MySQL server