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

  Vol. 2, No. 8, Agustus 2018, hlm. 2869-2876 http://j-ptiik.ub.ac.id

  

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

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

_{1 2 3} Gilang Ramadhan , Mahendra Data , Kasyful Amron

  Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: gilang@ub.ac.id, mahendra.data@ub.ac.id, 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

  peran yang sangat penting dalam sebuah sistem 1.

   PENDAHULUAN aplikasi. Semua proses bisnis yang berjalan pada

  sebuah sistem aplikasi akan membutuhkan Reliabilitas dan availabilitas sebuah kinerja database yang baik sebagai penyedia database server menjadi hal yang sangat krusial data. Ketika database server mengalami seiring dengan berkembangnya industri kegagalan, maka dipastikan akan menghentikan teknologi informasi dan komunikasi (Aditya, semua proses bisnis dari sistem secara 2015). Hal ini dikarenakan database memiliki keseluruhan. Pentingnya peran database ini yang

  Fakultas Ilmu Komputer Universitas Brawijaya

2869 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

  balancing antar database server dan performa

  bandwith yang dibutuhkan dari masing-masing database cluster . Dari pengujian yang telah

  pada penelitiannya membandingkan performa replikasi pada DBMS PostgreSQL dan MariaDB Galera Cluster. Performa yang diuji meliputi CPU load, disk load, troughtput, maupun

  database cluster . Gianpaolo Silvestrini (2014)

  Selain fokus pada load balancing, ada juga penelitian yang fokus pada performa dari

  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.

  query per detik yang diproses sebuah server.

  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

  topik ini banyak dilakukan. Penelitian yang dilakukan banyak membahas mengenai load

  database dengan cara membagi beban pekerjaan tiap database server. (Aditya, 2015).

  database cluster membuat penelitian tentang

  Dengan berkembangnya teknologi

  2. PENELITIAN TERKAIT

  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.

  database cluster yang dimiliki.

  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

  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.

  dilakukan, dua DBMS yang diuji memiliki performa yang tidak jauh berbeda sehingga pemilihan jenis DBMS bisa disesuaikan berdasarkan kebutuhan dari sistem yang akan digunakan 3.

DASAR TEORI

  MariaDB Galera cluster merupakan sebuah aplikasi database clustering yang mendukung

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

  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.

  only hanya pada awal proses replikasi saja saat

  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

  state snapshot

  menawarkan kelebihan dari metode physical

  snapshots . Baik Rsync dan Xtrabackup-2

  Rsync dan Xtrabackup-v2 merupakan metode yang termasuk dalam physical state

  3.4 Rsync vs Xtrabackup-v2

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

  synchronous multi-master

  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.

  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.

  cluster . Salah satu yang paling populer

  besar DBMS saat ini telah mendukung database

  failure dari sebuah sistem database. Sebagian

  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

  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.

  service , dll.) tersendiri yang bekerja secara

  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,

  Database Cluster sendiri merupakan kumpulan

  solusi untuk menjamin reliabilitas dan availabilitas dari sebuah database server.

  3.2. Database Cluster Database cluster merupakan salah satu

  3.3. MariaDB Galera Cluster bertindak sebagai klien dimana perangkat yang dirancang dengan topologi sesuai dengan menginisiai proses sinkronisasi. Yang kedua gambar 1. 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

  Gambar 1. Testbed Pengujian

  mencatat log sequence number (LSN) saat Ada beberapa perangkat lunak yang

  Xtrabackup mulai berjalan dan melakukan digunakan pada testbed penelitian ini antara lain: replikasi data (Percona, 2017). Ketika ada perubahan data, Xtrabackup akan akan

• MariaDB versi 10.1.18. Pada versi ini, melakukan pemeriksaan pada database dan MariaDB Galera cluster sudah terintegrasi di dalamnya.

  diwaktu yang bersamaan, akan ada proses yang memeriksa log transaksi dan kemudian akan

• Wanem versi 3.0 yang akan digunakan mulai melakukan pembaruan data berdasarkan untuk emulasi kondisi jaringan sesuai log transaksi yang dimiliki. Proses replikasi dengan skenario pengujian. Xtrabackup akan diawali dengan dilakukannya
• VirtualBox versi 5.1.6 yang akan digunakan replikasi tabel MyISAM dan sebelum untuk membangun testbed penelitian.

  berjalannya proses replikasi. Diwaktu yang bersamaan, Xtrabackup akan mengunci

  4.2 Perancangan Skenario Pengujian database untuk mencegah adanya perubahan

  Pengujian akan dilakukan dengan menguji data pada saat proses replikasi tabel MyISAM. dua metode SST yang digunakan pada penelitian

  Ketika replikasi tabel MyISAM selesai, maka ini, yaitu metode SST Rsync dan Xtrabackup-v2. Xtrabackup akan merilis kunci terhadap

  Untuk scenario pertama, kedua metode ini akan

  database dan menjalankan proses replikasi. Hal

  diuji dengan empat jenis kegagalan untuk ini yang membuat Xtrabackup secara teknis mengetahui bagaimana performa kedua metode membutuhkan waktu replikasi yang sedikit lebih SST ini ketika mengalami kegagalan. Empat banyak jika dibandingkan Rsync yang jenis kegagalan itu adalah: melakukan blocking selama proses replikasi  Database service down, kondisi dimana berlangsung. database service pada salah satu node dimatikan secara normal. Skenario ini

4. PERANCANGAN

  digunakan untuk mensimulasikan kondisi Proses perancangan pada penelitian ini saat adanya kebutuhan untuk mematikan terbagi menjadi dua bagian. Bagian pertama service salah satu database yang disebabkan adalah proses perancangan testbed dan bagian oleh maintenance salah satu node dalam kedua adalah perancangan skenario pengujian. sebuah cluster.  Jaringan down, kondisi dimana jaringan

4.1 Perancangan Testbed pada salah satu node sengaja diputus.

  kondisi ini mensimulasikan ketika koneksi

  Testbed penelitian dibangun pada satu

  salah satu node dalam cluster terputus yang komputer fisik yang menjalankan beberapa disebabkan oleh gangguan link pada salah komputer virtual di dalamnya menggunakan satu node yang membuat koneksi node aplikasi VirtualBox. Komputer virtual tersebut tersebut terputus.

  Pengujian dilakukan dengan menjalankan  Database server down, kondisi dimana program inject data sebanyak 30000 baris pada salah satu node dimatikan paksa sehingga salah satu node diikuti dengan menjalankan

  database service akan berhenti bekerja secara ubnormal. Kondisi ini salah satu kondisi kegagalan pada node lainnya.

  Kemudian dampak dari kegagalan tiap skenario mensimulasikan ketika sebuah node dalam tersebut akan dicatat. Langkah berikutnya adalah sebuah cluster mengalami gangguan yang membuat node tersebut berhenti bekerja. memulihkan kondisi kegagalan dan memantau kondisi cluster setelah kondisi kegagalan

   Packet loss 10%, kondisi dimana packet tersebut dipulihkan. loss pada koneksi salah satu node sengaja

  Skenario pengujian yang kedua adalah dibangkitkan sebesar 10% menggunakan pengujian untuk mengukur waktu replikasi yang aplikasi Wanem. Skenario ini dibutuhkan untuk menjalankan replikasi. Waktu mensimulasikan keadaan ketika adanya replikasi diukur berdasarkan file log MariaDB penurunan performa jaringan salah satu untuk mengetahui berapa lama waktu yang node dalam sebuah cluster. dibutuhkan sebuah node ketika baru bergabung

  Empat jenis kegagalan ini masing-masing dalam cluster hingga proses SST selesai. akan diuji dengan jumlah node yang berbeda,

  Pengujian akan dilakukan pada beberapa cluster yaitu menggunakan dua dan tiga node. Tujuan dengan besar data yang berbeda dan masing- dari perbedaan jumlah node ini adalah untuk masing akan diuji pada metode SST Rsync dan mengetahui dampak jumlah node terhadap Xtrabackup. availabilitas dan reabilitas cluster. Detail dari

  Skenario pengujian ketiga adalah pengujian skenario pengujian bisa dilihat pada tabel 1. yang dilakukan untuk menguji bagaimana pengaruh pemilihan metode SST pada perilaku

  Tabel 1. Skenario Pengujian

  cluster. Pengujian dilakukan dengan

  No. SST Jenis kegagalan Jumlah

  menjalankan proses SST pada cluster¸kemudian

  Pengujian Node

  dilakukan penambahan data pada node yang

  1 Rsync database

  2

  berperan sebagai donor. Akan dicatat dan

  service down

  dianalisa, apa yang terjadi pada donor dan pada

  2 Rsync database

  3 cluster dan apa yang mempengaruhi hal tersebut. service down

  3 Rsync Jaringan down

  2 5.

HASIL DAN ANALISIS PENGUJIAN

  4 Rsync Jaringan down

  3 Hasil pengujian yang telah dilakukan sesuai

  5 Rsync Database server

  2

  dengan skenario pada tabel 1, bisa dilihat pada

  down

  tabel 2 yang menunjukan hasil pengujian

  6 Rsync Database server

  3 menggunakan metode SST Rsync. down

  7 Rsync packet loss 10%

  2 Tabel 2. Hasil pengujian metode Rsync

  8 Rsync packet loss 10%

  3 No Kondisi Setelah Dampak

  9 Xtrabacku database

  2 Pengujian Cluster Dipulihkan p-v2 service down 1 normal; node normal; replikasi

  10 Xtrabacku database 3 lain tetap tetap berjalan dan p-v2 service down dapat data konsisten beroperasi

  11 Xtrabacku Jaringan down

  2 p-v2 2 normal; node normal; replikasi lain tetap tetap berjalan dan

  Xtrabacku

  12 Jaringan down

  3 dapat data konsisten p-v2 beroperasi

  13 Xtrabacku Database server

  2 3 error; Cluster normal; replikasi p-v2 down tidak dapat tetap berjalan dan

  14 Xtrabacku Database server

  3 diakses. data konsisten p-v2 down normal; node normal; replikasi

  4

  15 Xtrabacku packet loss 10%

  2 lain tetap tetap berjalan dan p-v2 dapat data konsisten Xtrabacku

  16 packet loss 10% 3 beroperasi p-v2

  5 error; Cluster tidak dapat diakses. normal; replikasi tetap berjalan dan data konsisten

  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.

  service dimatikan secara normal, maka node

  tidak mempengaruhi proses replikasi yang sedang berjalan baik dijalankan pada dua atau tiga node. Hal ini dikarenakan saat database

  packet loss 10%. Kedua skenario kegagalan ini

  Dari empat skenario kegagalan yang diuji, ada dua skenario yang membuat cluster tetap beroperasi saat kegagalan dijalankan. Yaitu skenario kegagalan database service down dan

  replikasi selesai pada node tersebut. Sehingga semakin besar data yang ada pada cluster, maka pesan error tersebut akan semakin lama muncul.

  node tersebut belum bisa diakses sampai proses

  ’ pada node yang baru dipulihkan. Error ini muncul dikarenakan proses replikasi yang sedang berjalan pada node yang baru saja dipulihkan sehingga database pada

  for application use

  berjalan saat skenario kegagalan dilakukan namun mengalami error saat cluster dipulihkan. Pesan error 1407 muncul dengan yang bertuliskan ‘WSREP has not yet prepared node

  cluster tiga node. Proses inject data tetap

  skenario kegagalan database server down pada

  Error yang kemudian terjadi adalah pada

  cluster tidak bisa diakses. Saat kondisi cluster

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

  ’. Pesan ini muncul pada kedua skenario kegagalan yang mengalami error dan membuat

  get lock

  muncul pesan ‘Deadlock found when trying to

  cluster akan langsung mengalami error dan

  dan database server down pada cluster dengan dua node. Saat skenario kegagalan dijalankan,

  error pada skenario kegagalan jaringan down

  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

  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

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

  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

  Tabel 3. Hasil Pengujian Metode Xtrabackup-v2 No Pengujian Dampak Kondisi Setelah Cluster Dipulihkan

  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.

  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

  tersebut akan memberikan sinyal pada node lain jika akan keluar dari cluster tersebut sehingga proses replikasi masih berjalan pada node yang masih beroperasi.

• 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

  memiliki performa yang hampir sama ketika mengalami kegagalan yang terjadi pada cluster.

  Perbandingan Waktu Replikasi Rsync Xtrabackup-v2

  200 MB 300 MB 400 MB 500 MB W ak tu R ep lik asi ukuran data

  500 1000 1500 2000

  IEEE, hal. 226 –233.

  IEEE 18th International Enterprise Distributed Object Computing Conference.

  Reliability and Availability Properties of Distributed Database Systems. In 2014

  bandung: IEEE. Domaschka, J., Hauser, C.B. & ERB, B., 2014.

  (HA) MariaDB Galera Cluster across data center with optimized WRR scheduling algorithm of LVS-TUN.

  Ca’FOscari di Venezia. Aditya, B., Juhana, T., 2015. A high availability

  databases for web application: architecture and performance analysis. S2 Universitas

  Silvestrini,G., 2014. Replicated open source

  blocking (Xtrabackup/ Xtrabackup-v2)

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

  6. KESIMPULAN

  tidak dalam read only selama proses SST berlangsung.

  only selama proses SST dan Xtrabackup-v2

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

  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

  Gambar 2. Perbandingan Waktu Replikasi

  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.

  cluster . Hasil pengujian waktu replikasi bisa

  Pengujian yang dilakukan selanjutnya adalah pengujian waktu replikasi dan perilaku

  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.

  cluster mengalami kegagalan baik pada Rsync

  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

DAFTAR PUSTAKA

  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: https://launchpad.net/codership-mysql.