Analisis Performa State Snapshot Transfers (SST) Tipe Blocking (Rsync) dan Non Blocking (Xtrabackup-V2) pada MariaDB Galera Cluster

Transkripsi

1 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X Vol. 2, No. 8, Agustus 2018, hlm Analisis Performa State Snapshot Transfers (SST) Tipe Blocking (Rsync) dan Non Blocking (Xtrabackup-V2) pada MariaDB Galera Cluster Gilang Ramadhan 1, Mahendra Data 2, Kasyful Amron 3 Program Studi Teknik Informatika, 1 gilang@ub.ac.id, 2 mahendra.data@ub.ac.id, 3 kasyful@ub.ac.id Abstrak Reliabilitas dan availabilitas database server menjadi hal yang krusial pada sebuah sistem aplikasi. Pentingnya peran database server ini membuat banyaknya penelitian yang dilakukan untuk meningkatkan reliabilitas dan availabiltas sebuah database server. Salah satunya adalah dengan mekanisme replikasi database. MariaDB merupakan salah satu DBMS yang memiliki mekanisme replikasi melalui aplikasi MariaDB Galera Cluster. MariaDB Galera Cluster memiliki beberapa metode State Snapshot Transfer (SST) yang digunakan untuk proses replikasi, antara lain Rsync, Xtrabackup, Xtrabacku, dan Mysqldump. Penelitian ini akan membandingkan kinerja metode SST Rsync dan Xtrabacku. Dari hasil pengujian disimpulkan bahwa kedua metode ini memiliki kinerja yang hampir sama. Jumlah node pada cluster menjadi faktor yang mempengaruhi bagaimana kinerja cluster saat mengalami kegagalan. Cluster dengan dua node akan lebih rentan mengalami error jika salah satu node mengalami kegagalan, sehingga jumlah node minimal yang disarankan pada sebuah cluster adalah tiga node dengan catatan hanya ada satu node node yang mengalami kegagalan. Hasil pengujian yang dilakukan juga menghasilkan sebuah kesimpulan bahwa pemilihan metode SST dan jumlah node mempengaruhi waktu replikasi. Metode Rsync secara umum memiliki waktu replikasi yang lebih cepat dibandingkan dengan Xtrabacku. Kata kunci: replikasi, database, cluster, MariaDB Galera Cluster Abstract Reliability and availability of database server becomes the crucial things of application system. There are so many researches that have been done in order to increase the reliabilty and availability of database server. The example is using database replication mechanism. MariaDB is one of DBMS that has a replication mechanism through MariaDB Galera Cluster application. MariaDB Galera Cluster has several methods called State Snapshot transfer (SST) which is used for replication process, namely Rsync, Xtrabackup, Xtrabacku, and Mysqldump. This study focused to compare the performance of Rsync method and Xtrabacku method. The experimental results show that both methods have a similar performance. Number of nodes in a cluster can affect the performance of cluster. Cluster with two nodes would be more vulnerable to become an error if one of the node becomes has failed. Therefore, the minimum number of nodes on a cluster is three on condition that there is just one node that failed. This experiment also results another conclusion that SST method that used and number of nodes can affect the replication times. Rsync method has a shorter duration of replication compared to the Xtrabacku. Keywords: replication, database, cluster, MariaDB Galera Cluster 1. PENDAHULUAN Reliabilitas dan availabilitas sebuah database server menjadi hal yang sangat krusial seiring dengan berkembangnya industri teknologi informasi dan komunikasi (Aditya, 2015). Hal ini dikarenakan database memiliki peran yang sangat penting dalam sebuah sistem aplikasi. Semua proses bisnis yang berjalan pada sebuah sistem aplikasi akan membutuhkan kinerja database yang baik sebagai penyedia data. Ketika database server mengalami kegagalan, maka dipastikan akan menghentikan semua proses bisnis dari sistem secara keseluruhan. Pentingnya peran database ini yang Fakultas Ilmu Komputer Universitas Brawijaya 2869

2 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2870 membuat sebuah database diharuskan memiliki up time yang mendekati 100%. Di sisi lain pentingnya peran database juga disertai dengan besarnya peluang sebuah database mengalami kegagalan sistem. Ada beberapa cara yang dikembangkan untuk meningkatkan reliabilitas dan availabilitas sebuah sistem database, salah satunya adalah menggunakan teknik replikasi. Replikasi adalah teknik penggandaan data pada beberapa lokasi fisik yang berbeda untuk satu data logis yang sama (Domaschka dkk., 2014). Penggunaan teknik replikasi ini akan mengurangi resiko terjadinya kegagalan sistem ketika terjadi kerusakan pada salah satu database pada sistem tersebut. Selain itu replikasi juga digunakan untuk meningkatkan availabilitas sistem database dengan cara membagi beban pekerjaan tiap database server. (Aditya, 2015). Proses replikasi MariaDB Galera Cluster terjadi ketika sebuah node bergabung dalam sebuah cluster (joiner node), joiner node ini akan menkan replikasi data secara keseluruhan dari salah satu node yang sudah ada dalam cluster tersebut (donor node). Proses ini disebut dengan State Snapshot Transfer (SST). Ada beberapa metode SST yang bisa digunakan pada MariaDB Galera Cluster, yaitu Rsync, Mysqldumb, Xtrabackup, dan Xtrabacku. Penelitian ini akan fokus pada analisis perbandingan kinerja metode SST Rsync dan Xtrabacku. Kedua metode ini dipilih atas dasar perbedaan tipe dari kedua metode ini yaitu Rsync yang bertipe blocking dan Xtrabacku yang bertipe non-bloking. Pada saat replikasi sedang berlangsung, Rsync akan membuat node yang sedang melakukan replikasi berada pada mode read only sampai dengan proses replikasi selesai. Sebaliknya pada Xtrabacku, proses blocking hanya berjalan dalam waktu yang singkat pada awal proses replikasi saja. Dengan perbedaan cara kerja dari kedua metode yang dipilih, diharapkan hasil penelitian ini menunjang administrator sistem dalam memilih metode SST yang tepat disesuaikan dengan database cluster yang dimiliki. Hasil penelitian ini disusun dengan struktur sebagai berikut. Bagian pertama adalah penelitian terkait mengenai penelitian sebelumnya yang telah dilakukan mengenai teknik-teknik replikasi. Bagian kedua adalah dasar teori mengenai reliabilitas, availabilitas, klaster database, jenis replikasi dan DBMS MariaDB secara umum. Bagian ini digunakan untuk menyamakan presepsi mengenai teori dan istilah-istilah yang digunakan. Bagian ketiga adalah perancangan metode serta testbed yang digunakan dalam penelitian ini. Bagian keempat adalah penjabaran hasil percobaan serta analisis dari hasil percobaan yang telah dilakukan. Bagian terakhir dari penelitian ini adalah penyampaikan kesimpulan dari keseluruhan percobaan yang telah dilakukan. 2. PENELITIAN TERKAIT Dengan berkembangnya teknologi database cluster membuat penelitian tentang topik ini banyak dilakukan. Penelitian yang dilakukan banyak membahas mengenai load balancing antar database server dan performa dari database cluster itu sendiri. Seperti yang dilakukan Bagus Aditya (2015) pada penelitiannya yang menggunakan infrastruktur Linux Virtual Server (LVS) dan optimalisasi algoritma penjadwalan Weighten Round-Robin (WRR) sebagai load balancer pada MariaDB Galera Cluster. Penelitian ini dilakukan pada beberapa data center yang terpisah secara geografis dengan tujuan untuk meminimalisir kemungkinan resiko bencana alam pada salah satu negara yang mempengaruhi sebuah data center. Optimalisasi dilakukan dengan melakukan pemeriksaan berkala pada beberapa variabel yang menggambarkan performa dan beban kerja dari masing-masing server. Beberapa variabel tersebut antara lain banyaknya client yang terhubung dan rata-rata query per detik yang diproses sebuah server. Dari kedua variabel tersebut akan diketahui beban dari setiap server dan server dengan beban terkecil akan menjadi server prioritas. Berdasarkan pengujian yang dilakukan, Optimalisasi yang dilakukan membuat algoritma WRR memberikan respon yang lebih cepat dibanding algortima WRR biasa. Hal ini dikarenakan cluster akan lebih dinamis dalam menentukan server prioritas yang akan mempengaruhi performa dari cluster itu sendiri. Selain fokus pada load balancing, ada juga penelitian yang fokus pada performa dari database cluster. Gianpaolo Silvestrini (2014) pada penelitiannya membandingkan performa replikasi pada DBMS PostgreSQL dan MariaDB Galera Cluster. Performa yang diuji meliputi CPU load, disk load, troughtput, maupun bandwith yang dibutuhkan dari masing-masing database cluster. Dari pengujian yang telah dilakukan, dua DBMS yang diuji memiliki performa yang tidak jauh berbeda sehingga

3 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2871 pemilihan jenis DBMS bisa disesuaikan berdasarkan kebutuhan dari sistem yang akan digunakan 3. DASAR TEORI 3.1. Availabilitas Dan Reliabilitas Availabilitas adalah tingkat ketersediaan suatu sistem untuk diakses dan dipergunakan ketika diperlukan. Sedangkan reliabilitas adalah ukuran kemampuan suatu sistem dalam memberikan hasil yang benar ketika dipergunakan pada berbagai keadaan (Domaschka dkk., 2014). Dari penjelasan ini disimpulkan bahwa sebenarnya availabilitas dan reliabilitas memiliki makna yang berbeda dan tidak saling terikat satu sama lain. Namun, pada kenyataannya, availabilitas tanpa reliabilitas atau sebaliknya mengakibatkan sistem tersebut tidak banyak berguna (Domaschka et al. 2014). Contohnya ketika sebuah database memiliki availabilitas tinggi dalam melayani akses user, namun tidak bisa menjamin si data yang dimiliki atau sebaliknya, database tersebut memiliki data yang namun memiliki availabilitas rendah karena koneksi yang sering terputus, maka database tersebut masih belum cukup layak untuk digunakan Database Cluster Database cluster merupakan salah satu solusi untuk menjamin reliabilitas dan availabilitas dari sebuah database server. Database Cluster sendiri merupakan kumpulan dari beberapa database server yang secara logika dipandang sebagai satu kesatuan sistem database. Satu database server dalam satu cluster, atau biasa disebut sebagai node, memiliki perangkat keras (CPU, memory, disk, dll.) dan perangkat lunak (sistem operasi, service, dll.) tersendiri yang bekerja secara independen. Namun secara logika, antar node dalam database cluster tersebut saling terhubung melalui sebuah perangkat lunak yang mengelola seluruh node di dalam cluster tersebut (Pacitti et al. 2005). Dengan kata lain database cluster adalah sistem database yang terdiri dari beberapa database server yang dimaksudkan untuk memberikan skalabilitas dan availabilitas dari sebuah sistem aplikasi secara keseluruhan. Di dalam sebuah database cluster terjadi proses replikasi data dari satu node dengan node lain. Proses ini yang membuat si data dari tiap node dalam sebuah cluster tetap terjaga dan mencegah terjadinya single point of failure dari sebuah sistem database. Sebagian besar DBMS saat ini telah mendukung database cluster. Salah satu yang paling populer diantaranya adalah MariaDB Galera Cluster (MariaDB 2014b). Kemampuan ini yang membuat sebuah database server memiliki reliabilitas yang tinggi karena si data yang terjamin dan memiliki availabilitas yang tinggi sehingga lebih toleran terhadap kegagalan sistem MariaDB Galera Cluster MariaDB Galera cluster merupakan sebuah aplikasi database clustering yang mendukung synchronous multi-master. Dengan kata lain semua node yang ada dalam cluster akan berperan sebagai master sehingga aplikasi membaca maupun menulis pada node manapun. MariaDB Galera cluster menggunakan Write- Set Replication API (Wsrep-API) yang merupakan pengembangan API dari Mysql Replication buatan Codership (Yurchenko 2009). Pada awal pengembangannya, MariaDB Galera Cluster merupakan package terpisah dari DBMS MariaDB. Namun MariaDB Galera Cluster sudah terintegrasi didalam DMBS MariaDB versi 10.1, sehingga pengguna tidak perlu lagi melakukan instalasi package MariaDB Galera Server secara manual (MariaDB 2014b). 3.4 Rsync vs Xtrabacku Rsync dan Xtrabacku merupakan metode yang termasuk dalam physical state snapshots. Baik Rsync dan Xtrabackup-2 menawarkan kelebihan dari metode physical state snapshot dimana proses replikasi berjalan dengan cepat. Namun ter perbedaan dari kedua metode tersebut, antara lain, Rsync akan membuat node yang sedang menjalankan replikasi dalam keadaan read only sampai proses replikasi selesai dilakukan. Di sisi lain jika Xtrabacku, node yang sedang melakukan replikasi berada dalam posisi read only hanya pada awal proses replikasi saja saat mereplikasi tabel sistem (MyISAM) dari MariaDB galera, 2015). Perbedaan lain dari kedua metode ini adalah adanya kebutuhan konfigurasi database akses root pada Xtrabacku, namun Rsync tidak memerlukan akses root ataupun konfigurasi database. Ter tiga elemen penting dalam penggunaan Rsync. Yang pertama adalah yang

4 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2872 bertindak sebagai klien dimana perangkat yang menginisiai proses sinkronisasi. Yang kedua adalah server sebagai perangkat yang akan memberikan datanya. Yang ketiga adalah yang disebut dengan istilah generator yang mengatur manajemen data dan melakukan identifikasi ketika ter perubahan terhadap data tersebut. Rsync bekerja dengan berjalannya service Rsync pada server dan menunggu koneksi dari klien (Rsync, 2017). Generator akan berjalan dengan melakukan pemeriksaan pada data yang dimiliki server dan mulai melakukan proses replikasi pada klien. Generator akan terus berjalan sehingga ketika ter perubahan data pada server, generator akan mengirimkan pembaruan data pada klien. Di sisi lain, Xtrabackup bekerja dengan mencatat log sequence number (LSN) saat Xtrabackup mulai berjalan dan melakukan replikasi data (Percona, 2017). Ketika ada perubahan data, Xtrabackup akan akan melakukan pemeriksaan pada database dan diwaktu yang bersamaan, akan ada proses yang memeriksa log transaksi dan kemudian akan mulai melakukan pembaruan data berdasarkan log transaksi yang dimiliki. Proses replikasi Xtrabackup akan diawali dengan dilakukannya replikasi tabel MyISAM dan sebelum berjalannya proses replikasi. Diwaktu yang bersamaan, Xtrabackup akan mengunci database untuk mencegah adanya perubahan data pada saat proses replikasi tabel MyISAM. Ketika replikasi tabel MyISAM selesai, maka Xtrabackup akan merilis kunci terhadap database dan menjalankan proses replikasi. Hal ini yang membuat Xtrabackup secara teknis membutuhkan waktu replikasi yang sedikit lebih banyak jika dibandingkan Rsync yang melakukan blocking selama proses replikasi berlangsung. 4. PERANCANGAN Proses perancangan pada penelitian ini terbagi menjadi dua bagian. Bagian pertama adalah proses perancangan testbed dan bagian kedua adalah perancangan skenario pengujian. 4.1 Perancangan Testbed Testbed penelitian dibangun pada satu komputer fisik yang menjalankan beberapa komputer virtual di dalamnya menggunakan aplikasi VirtualBox. Komputer virtual tersebut dirancang dengan topologi sesuai dengan gambar 1. Gambar 1. Testbed Pengujian Ada beberapa perangkat lunak yang digunakan pada testbed penelitian ini antara lain: MariaDB versi Pada versi ini, MariaDB Galera cluster sudah terintegrasi di dalamnya. Wanem versi 3.0 yang akan digunakan untuk emulasi kondisi jaringan sesuai dengan skenario pengujian. VirtualBox versi yang akan digunakan untuk membangun testbed penelitian. 4.2 Perancangan Skenario Pengujian Pengujian akan dilakukan dengan menguji dua metode SST yang digunakan pada penelitian ini, yaitu metode SST Rsync dan Xtrabacku. Untuk scenario pertama, kedua metode ini akan diuji dengan empat jenis kegagalan untuk mengetahui bagaimana performa kedua metode SST ini ketika mengalami kegagalan. Empat jenis kegagalan itu adalah: Database service down, kondisi dimana database service pada salah satu node dimatikan secara normal. Skenario ini digunakan untuk mensimulasikan kondisi saat adanya kebutuhan untuk mematikan service salah satu database yang disebabkan oleh maintenance salah satu node dalam sebuah cluster. Jaringan down, kondisi dimana jaringan pada salah satu node sengaja diputus. kondisi ini mensimulasikan ketika koneksi salah satu node dalam cluster terputus yang disebabkan oleh gangguan link pada salah satu node yang membuat koneksi node tersebut terputus.

5 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2873 Database server down, kondisi dimana salah satu node dimatikan paksa sehingga database service akan berhenti bekerja secara ubnormal. Kondisi ini mensimulasikan ketika sebuah node dalam sebuah cluster mengalami gangguan yang membuat node tersebut berhenti bekerja. Packet loss 10%, kondisi dimana packet loss pada koneksi salah satu node sengaja dibangkitkan sebesar 10% menggunakan aplikasi Wanem. Skenario ini mensimulasikan keadaan ketika adanya penurunan performa jaringan salah satu node dalam sebuah cluster. Empat jenis kegagalan ini masing-masing akan diuji dengan jumlah node yang berbeda, yaitu menggunakan dua dan tiga node. Tujuan dari perbedaan jumlah node ini adalah untuk mengetahui dampak jumlah node terhadap availabilitas dan reabilitas cluster. Detail dari skenario pengujian bisa dilihat pada tabel 1. No. Pengujian Tabel 1. Skenario Pengujian SST Jenis kegagalan Jumlah Node 1 Rsync database service down 2 Rsync database service down 3 Rsync Jaringan down 2 4 Rsync Jaringan down 3 5 Rsync Database server down 6 Rsync Database server down 7 Rsync packet loss 10% 2 8 Rsync packet loss 10% 3 9 Xtrabacku 10 Xtrabacku 11 Xtrabacku 12 Xtrabacku 13 Xtrabacku 14 Xtrabacku 15 Xtrabacku 16 Xtrabacku database service down database service down Jaringan down 2 Jaringan down 3 Database server down Database server down 2 3 packet loss 10% 2 packet loss 10% 3 Pengujian dilakukan dengan menjalankan program inject data sebanyak baris pada salah satu node diikuti dengan menjalankan salah satu kondisi kegagalan pada node lainnya. Kemudian dampak dari kegagalan tiap skenario tersebut akan dicatat. Langkah berikutnya adalah memulihkan kondisi kegagalan dan memantau kondisi cluster setelah kondisi kegagalan tersebut dipulihkan. Skenario pengujian yang kedua adalah pengujian untuk mengukur waktu replikasi yang dibutuhkan untuk menjalankan replikasi. Waktu replikasi diukur berdasarkan file log MariaDB untuk mengetahui berapa lama waktu yang dibutuhkan sebuah node ketika baru bergabung dalam cluster hingga proses SST selesai. Pengujian akan dilakukan pada beberapa cluster dengan besar data yang berbeda dan masingmasing akan diuji pada metode SST Rsync dan Xtrabackup. Skenario pengujian ketiga adalah pengujian yang dilakukan untuk menguji bagaimana pengaruh pemilihan metode SST pada perilaku cluster. Pengujian dilakukan dengan menjalankan proses SST pada cluster kemudian dilakukan penambahan data pada node yang berperan sebagai donor. Akan dicatat dan dianalisa, apa yang terjadi pada donor dan pada cluster dan apa yang mempengaruhi hal tersebut. 5. HASIL DAN ANALISIS PENGUJIAN Hasil pengujian yang telah dilakukan sesuai dengan skenario pada tabel 1, bisa dilihat pada tabel 2 yang menunjukan hasil pengujian menggunakan metode SST Rsync. Tabel 2. Hasil pengujian metode Rsync No Pengujian Dampak 1 normal; node 2 normal; node 3 error; Cluster tidak diakses. 4 normal; node Kondisi Setelah Cluster Dipulihkan

6 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer error; Cluster tidak diakses. 6 normal; node 7 normal; node 8 normal; node error; Replikasi sempat terhenti dan muncul error 1407 namun tidak berapa lama replikasi berjalan normal kembali Selain itu hasil pengujian juga bisa dilihat pada tabel 3 yang merupakan hasil pengujian dengan skenario kegagalan yang sama dengan pengujian sebelumnya namun menggunakan metode SST Xtrabacku. Tabel 3. Hasil Pengujian Metode Xtrabacku No Pengujian Dampak 1 normal; node 2 normal; node 3 error; Cluster tidak diakses. 4 normal; node 5 error; Cluster tidak diakses. 6 normal; node 7 normal; node Kondisi Setelah Cluster Dipulihkan error; Replikasi sempat terhenti dan muncul error 1407 namun tidak berapa lama replikasi berjalan normal kembali 8 normal; node Seperti yang bisa dilihat pada tabel 2 dan tabel 3 dimana kedua metode SST memiliki hasil pengujian yang hampir sama. Baik Rsync maupun Xtrabacku sama-sama mengalami error pada skenario kegagalan jaringan down dan database server down pada cluster dengan dua node. Saat skenario kegagalan dijalankan, cluster akan langsung mengalami error dan muncul pesan Deadlock found when trying to get lock. Pesan ini muncul pada kedua skenario kegagalan yang mengalami error dan membuat cluster tidak bisa diakses. Saat kondisi cluster dipulihkan, maka cluster akan kembali. Namun saat dilakukan pemeriksaan data pada database, kedua node berisi data yang telah masuk pada database sebelum error terjadi, berdasarkan hal ini disimpulkan bahwa cluster dengan dua node memiliki potensi kehilangan data jika proses insert data terjadi pada waktu yang bersamaan dengan salah satu kondisi kegagalan walaupun cluster telah berhasil dipulihkan. Error yang kemudian terjadi adalah pada skenario kegagalan database server down pada cluster tiga node. Proses inject data tetap berjalan saat skenario kegagalan dilakukan namun mengalami error saat cluster dipulihkan. Pesan error 1407 muncul dengan yang bertuliskan WSREP has not yet prepared node for application use pada node yang baru dipulihkan. Error ini muncul dikarenakan proses replikasi yang sedang berjalan pada node yang baru saja dipulihkan sehingga database pada node tersebut belum bisa diakses sampai proses replikasi selesai pada node tersebut. Sehingga semakin besar data yang ada pada cluster, maka pesan error tersebut akan semakin lama muncul. Dari empat skenario kegagalan yang diuji, ada dua skenario yang membuat cluster tetap saat kegagalan dijalankan. Yaitu skenario kegagalan database service down dan packet loss 10%. Kedua skenario kegagalan ini tidak mempengaruhi proses replikasi yang sedang berjalan baik dijalankan pada dua atau tiga node. Hal ini dikarenakan saat database service dimatikan secara normal, maka node tersebut akan memberikan sinyal pada node lain jika akan keluar dari cluster tersebut sehingga proses replikasi masih berjalan pada node yang masih.

7 Waktu Replikasi Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2875 Berdasarkan pengujian yang telah dilakukan, jumlah node dan pemilihan metode SST merupakan aspek yang perlu diperhatikan dalam penerapan sebuah replikasi database. Jumlah node sangat berpengaruh pada saat cluster mengalami kegagalan baik pada Rsync maupun Xtrabacku. Pemilihan metode SST juga perlu diperhatikan mengingat masingmasing metode SST memiliki kelebihan dan kekurangan sehingga pemilihan SST mana yang akan digunakan perlu disesuaikan dengan sistem yang akan dibuat. Pengujian yang dilakukan selanjutnya adalah pengujian waktu replikasi dan perilaku cluster. Hasil pengujian waktu replikasi bisa dilihat pada gambar 2, waktu replikasi yang dibutuhkan oleh metode Rsync berjalan lebih cepat jika dibandingkan dengan waktu replikasi pada metode Xtrabacku. Adanya perbedaan waktu dari dua metode ini dikarenakan adanya proses blocking pada Rsync yang membuat proses SST langsung berjalan. Hal ini membuat proses replikasi lebih cepat jika dibandingkan pada metode Xtrabacku yang dimana proses blocking berjalan pada awal replikasi untuk melakukan replikasi tabel MyISAM dan membuat proses replikasi baru akan berjalan setelah proses blocking selesai. Hal ini dibuktikan pada timestamp log MariaDB saat dilakukan pengujian. Ter adanya delay dari pada saat joiner ditambahkan, proses replikasi tidak langsung berjalan dikarenakan adanya proses blocking untuk melakukan replikasi tabel MyISAM terlebih dahulu dan setelahnya proses replikasi data bisa berjalan. Perbandingan Waktu Replikasi MB 300 MB 400 MB 500 MB Rsync ukuran data Xtrabacku Gambar 2. Perbandingan Waktu Replikasi Selain itu, pemilihan metode SST juga mempengaruhi perilaku cluster itu sendiri. Pengujian yang dilakukan pada kedua cluster dimana melakukan penambahan data pada donor pada saat donor tersebut sedang menjalankan proses SST menghasilkan perilaku yang berbeda. Rsync akan mengalami kegagalan ketika menkan perubahan data saat melakukan proses SST. Sebaliknya Xtrabackupv2 masih bisa berjalan saat ada perubahan data, hanya saja proses perubahan data tidak langsung berjalan, dikarenakan Xtrabacku juga mengalami blocking pada awal proses SST. Hal ini sesuai dengan teori yang dijelaskan pada laman resmi Galera Cluster maupun MariaDB dimana Rsync membuat donor menjadi read only selama proses SST dan Xtrabacku tidak dalam read only selama proses SST berlangsung. 6. KESIMPULAN Berdasarkan pengujian dan analisis terhadap hasil pengujian yang telah di, disimpulkan bahwa: - Pengujian performa MariaDB Galera Cluster dilakukan dengan menguji MariaDB Galera Cluster dengan beberapa kondisi kegagalan yang mungkin terjadi. - Cluster yang memiliki tiga node terbukti lebih toleran dan menangani seluruh skenario kegagalan yang diujikan, dengan catatan hanya satu node yang mengalami kegagalan. - Metode SST blocking (Rsync) dan non blocking (Xtrabackup/ Xtrabacku) memiliki performa yang hampir sama ketika mengalami kegagalan yang terjadi pada cluster. - Waktu replikasi pada metode rsync sedikit lebih cepat dibandingkan dengan metode Xtrabacku DAFTAR PUSTAKA Silvestrini,G., Replicated open source databases for web application: architecture and performance analysis. S2 Universitas Ca FOscari di Venezia. Aditya, B., Juhana, T., A high availability (HA) MariaDB Galera Cluster across data center with optimized WRR scheduling algorithm of LVS-TUN.bandung: IEEE. Domaschka, J., Hauser, C.B. & ERB, B., Reliability and Availability Properties of Distributed Database Systems. In 2014 IEEE 18th International Enterprise Distributed Object Computing Conference. IEEE, hal

8 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2876 MariaDB., 2014a. About Galera Replication. Tersedia di: MariaDB., 2014b. About MariaDB. Tersedia di: Pacitti, E. ET AL., Preventive Replication in a Database Cluster. Distributed and Parallel Databases, 18(3), hal Yurchenko, A., MySQL patches by Codership. Tersedia di: