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

(1)

Fakultas Ilmu Komputer

Universitas Brawijaya

2869

Analisis Performa State Snapshot Transfers (SST) Tipe Blocking (Rsync)

dan Non Blocking (Xtrabackup-V2) pada MariaDB Galera Cluster

Gilang Ramadhan1_{, Mahendra Data}2_{, Kasyful Amron}3

Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 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, Xtrabackup-v2, dan Mysqldump. Penelitian ini akan membandingkan kinerja metode SST Rsync dan Xtrabackup-v2. 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 dapat mempengaruhi waktu replikasi. Metode Rsync secara umum memiliki waktu replikasi yang lebih cepat dibandingkan dengan Xtrabackup-v2.

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, Xtrabackup-v2, and Mysqldump. This study focused to compare the performance of Rsync method and Xtrabackup-v2 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 Xtrabackup-v2.

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

(2)

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 mendapatkan 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 Xtrabackup-v2.

Penelitian ini akan fokus pada analisis perbandingan kinerja metode SST Rsync dan Xtrabackup-v2. Kedua metode ini dipilih atas dasar perbedaan tipe dari kedua metode ini yaitu Rsync yang bertipe blocking dan Xtrabackup-v2 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 Xtrabackup-v2, 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 dapat 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 dapat 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 dapat 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)

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 dapat 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 konsistensi data yang dimiliki atau sebaliknya, database tersebut memiliki data yang konsisten namun memiliki availabilitas rendah karena koneksi yang sering terputus, maka database tersebut masih belum cukup layak untuk digunakan.

3.2. 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 dapat 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 konsistensi data

dari tiap node dalam sebuah cluster tetap terjaga dan dapat 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 konsistensi data yang terjamin dan memiliki availabilitas yang tinggi sehingga lebih toleran terhadap kegagalan sistem.

3.3. 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 dapat 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 Xtrabackup-v2

Rsync dan Xtrabackup-v2 merupakan metode yang termasuk dalam physical state snapshots. Baik Rsync dan Xtrabackup-2 menawarkan kelebihan dari metode physical state snapshot dimana proses replikasi dapat berjalan dengan cepat. Namun terdapat 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 Xtrabackup-v2, 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 Xtrabackup-v2, namun Rsync tidak memerlukan akses root ataupun konfigurasi database.

Terdapat tiga elemen penting dalam penggunaan Rsync. Yang pertama adalah yang

(4)

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 terdapat 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 terdapat 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 10.1.18. 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 5.1.6 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 Xtrabackup-v2. 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)

 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.

Tabel 1. Skenario Pengujian

No. Pengujian

SST Jenis kegagalan Jumlah

Node 1 Rsync database service down 2 2 Rsync database service down 3

3 Rsync Jaringan down 2

4 Rsync Jaringan down 3

5 Rsync Database server

down

2

6 Rsync Database server

down

3

7 Rsync packet loss 10% 2

8 Rsync packet loss 10% 3

9 Xtrabacku p-v2 database service down 2 10 Xtrabacku p-v2 database service down 3 11 Xtrabacku p-v2 Jaringan down 2 12 Xtrabacku p-v2 Jaringan down 3 13 Xtrabacku p-v2 Database server down 2 14 Xtrabacku p-v2 Database server down 3 15 Xtrabacku p-v2 packet loss 10% 2 16 Xtrabacku p-v2 packet loss 10% 3

Pengujian dilakukan dengan menjalankan program inject data sebanyak 30000 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 masing-masing 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 Kondisi Setelah Cluster Dipulihkan 1 normal; node lain tetap dapat beroperasi normal; replikasi tetap berjalan dan data konsisten 2 normal; node lain tetap dapat beroperasi normal; replikasi tetap berjalan dan data konsisten

3 error; Cluster

tidak dapat diakses.

normal; replikasi tetap berjalan dan data konsisten 4 normal; node lain tetap dapat beroperasi normal; replikasi tetap berjalan dan data konsisten

(6)

5 error; Cluster tidak dapat diakses.

normal; replikasi tetap berjalan dan data konsisten 6 normal; node lain tetap dapat beroperasi error; Replikasi sempat terhenti dan muncul error 1407 namun tidak berapa lama replikasi berjalan normal kembali 7 normal; node lain tetap dapat beroperasi normal; replikasi tetap berjalan dan data konsisten 8 normal; node lain tetap dapat beroperasi normal; replikasi tetap berjalan dan data konsisten

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 Xtrabackup-v2.

Tabel 3. Hasil Pengujian Metode Xtrabackup-v2

No

Pengujian Dampak

Kondisi Setelah Cluster Dipulihkan

1 normal; node

lain tetap dapat beroperasi

normal; replikasi tetap berjalan dan data konsisten

2 normal; node

3 error; Cluster

4 normal; node

5 error; Cluster

6 normal; node

error; Replikasi sempat terhenti dan muncul error 1407 namun tidak berapa lama replikasi berjalan normal kembali 7 normal; node lain tetap dapat beroperasi

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 Xtrabackup-v2 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 beroperasi. Namun saat dilakukan pemeriksaan data pada database, kedua node berisi data yang telah masuk pada database sebelum error terjadi, berdasarkan hal ini dapat 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 beroperasi 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 beroperasi.

(7)

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 Xtrabackup-v2. Pemilihan metode SST juga perlu diperhatikan mengingat masing-masing 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 Xtrabackup-v2. Adanya perbedaan waktu dari dua metode ini dikarenakan adanya proses blocking pada Rsync yang membuat proses SST dapat langsung berjalan. Hal ini membuat proses replikasi lebih cepat jika dibandingkan pada metode Xtrabackup-v2 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. Terdapat 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.

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 mendapatkan perubahan data saat melakukan proses SST. Sebaliknya Xtrabackup-v2 masih bisa berjalan saat ada perubahan data, hanya saja proses perubahan data tidak langsung berjalan, dikarenakan Xtrabackup-v2 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 Xtrabackup-v2 tidak dalam read only selama proses SST berlangsung.

6. KESIMPULAN

Berdasarkan pengujian dan analisis terhadap hasil pengujian yang telah didapat, dapat disimpulkan bahwa:

- Pengujian performa MariaDB Galera Cluster dapat dilakukan dengan menguji MariaDB Galera Cluster dengan beberapa kondisi kegagalan yang mungkin terjadi. - Cluster yang memiliki tiga node terbukti

lebih toleran dan dapat menangani seluruh skenario kegagalan yang diujikan, dengan catatan hanya satu node yang mengalami kegagalan.

- Metode SST blocking (Rsync) dan non blocking (Xtrabackup/ Xtrabackup-v2) memiliki performa yang hampir sama ketika mengalami kegagalan yang terjadi pada cluster.

- Waktu replikasi pada metode rsync sedikit lebih cepat dibandingkan dengan metode Xtrabackup-v2

DAFTAR PUSTAKA

Silvestrini,G., 2014. Replicated open source databases for web application: architecture and performance analysis. S2 Universitas Ca’FOscari di Venezia.

Aditya, B., Juhana, T., 2015. 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., 2014.

Reliability and Availability Properties of Distributed Database Systems. In 2014 IEEE 18th International Enterprise Distributed Object Computing Conference. IEEE, hal. 226–233. 0 500 1000 1500 2000 200 MB 300 MB 400 MB 500 MB W ak tu R ep lik asi ukuran data

Perbandingan Waktu Replikasi

(8)

MariaDB., 2014a. About Galera Replication.

Tersedia di:

https://mariadb.com/kb/en/mariadb/about-galera-replication/.

MariaDB., 2014b. About MariaDB. Tersedia di: https://mariadb.org/about/ .

Pacitti, E. ET AL., 2005. Preventive Replication in a Database Cluster. Distributed and Parallel Databases, 18(3), hal.223–251. Yurchenko, A., 2009. MySQL patches by

Codership. Tersedia di: