HA untuk MySQL dan MariaDB - Membandingkan Replikasi Master-Master dengan Galera Cluster

Replikasi Galera relatif baru jika dibandingkan dengan replikasi MySQL, yang didukung secara native sejak MySQL v3.23. Meskipun replikasi MySQL dirancang untuk replikasi satu arah master-slave, itu dapat dikonfigurasi sebagai pengaturan master-master aktif dengan replikasi dua arah. Meskipun mudah diatur, dan beberapa kasus penggunaan mungkin mendapat manfaat dari "peretasan" ini, ada sejumlah peringatan. Di sisi lain, klaster Galera adalah jenis teknologi yang berbeda untuk dipelajari dan dikelola. Apakah itu layak?

Dalam posting blog ini, kita akan membandingkan replikasi master-master dengan cluster Galera.

Konsep Replikasi

Sebelum kita beralih ke perbandingan, mari kita jelaskan konsep dasar di balik dua mekanisme replikasi ini.

Umumnya, modifikasi apa pun ke database MySQL menghasilkan acara dalam format biner. Acara ini diangkut ke node lain tergantung pada metode replikasi yang dipilih - replikasi MySQL (asli) atau replikasi Galera (ditambal dengan API wsrep).

Replikasi MySQL

Diagram berikut menggambarkan aliran data transaksi yang berhasil dari satu node ke node lain saat menggunakan replikasi MySQL:

Peristiwa biner ditulis ke dalam log biner master. Budak melalui slave_IO_thread akan menarik peristiwa biner dari log biner master dan mereplikasinya ke log relai. slave_SQL_thread kemudian akan menerapkan acara dari log relai secara asinkron. Karena sifat replikasi yang tidak sinkron, server slave tidak dijamin memiliki data saat master melakukan perubahan.

Idealnya, replikasi MySQL akan membuat slave dikonfigurasi sebagai server hanya-baca dengan mengatur read_only=ON atau super_read_only=ON. Ini adalah tindakan pencegahan untuk melindungi slave dari penulisan yang tidak disengaja yang dapat menyebabkan inkonsistensi data atau kegagalan selama master failover (misalnya, transaksi yang salah). Namun, dalam pengaturan replikasi aktif-aktif master-master, baca-saja harus dinonaktifkan pada master lain untuk memungkinkan penulisan diproses secara bersamaan. Master utama harus dikonfigurasi untuk mereplikasi dari master sekunder dengan menggunakan pernyataan CHANGE MASTER untuk mengaktifkan replikasi sirkular.

Replikasi Galera

Diagram berikut menggambarkan alur replikasi data dari transaksi yang berhasil dari satu node ke node lain untuk Galera Cluster:

Acara dienkapsulasi dalam writeset dan disiarkan dari node originator ke node lain di cluster dengan menggunakan replikasi Galera. Writeset menjalani sertifikasi pada setiap node Galera dan jika lolos, thread applier akan menerapkan writeset secara asinkron. Ini berarti bahwa server budak pada akhirnya akan menjadi konsisten, setelah persetujuan dari semua node yang berpartisipasi dalam pemesanan total global. Ini secara logis sinkron, tetapi penulisan dan komitmen yang sebenarnya ke tablespace terjadi secara independen, dan dengan demikian secara asinkron pada setiap node dengan jaminan bahwa perubahan akan menyebar ke semua node.

Menghindari Tabrakan Kunci Utama

Untuk menyebarkan replikasi MySQL dalam pengaturan master-master, seseorang harus menyesuaikan nilai kenaikan otomatis untuk menghindari tabrakan kunci utama untuk INSERT antara dua atau lebih master yang mereplikasi. Ini memungkinkan nilai kunci utama pada master untuk saling menyisipkan dan mencegah nomor kenaikan otomatis yang sama digunakan dua kali di salah satu node. Perilaku ini harus dikonfigurasi secara manual, tergantung pada jumlah master dalam pengaturan replikasi. Nilai auto_increment_increment sama dengan jumlah master yang mereplikasi dan auto_increment_offset harus unik di antara mereka. Misalnya, baris berikut harus ada di dalam my.cnf yang sesuai:

Master1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Master2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

Demikian juga, Galera Cluster menggunakan trik yang sama untuk menghindari tabrakan kunci utama dengan mengontrol nilai kenaikan otomatis dan mengimbangi secara otomatis dengan wsrep_auto_increment_control variabel. Jika disetel ke 1 (default), akan otomatis menyesuaikan auto_increment_increment dan auto_increment_offset variabel sesuai dengan ukuran cluster, dan ketika ukuran cluster berubah. Ini menghindari konflik replikasi karena auto_increment. Dalam lingkungan master-slave, variabel ini dapat disetel ke OFF.

Konsekuensi dari konfigurasi ini adalah nilai kenaikan otomatis tidak akan berurutan, seperti yang ditunjukkan pada tabel Cluster Galera tiga node berikut:

Jika aplikasi melakukan operasi penyisipan pada node berikut dalam urutan berikut:

• Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

Maka nilai primary key yang akan disimpan dalam tabel akan menjadi:

• 1, 6, 8, 9, 12, 13, 15 ..

Sederhananya, saat menggunakan replikasi master-master (replikasi MySQL atau Galera), aplikasi Anda harus dapat mentolerir nilai kenaikan otomatis yang tidak berurutan dalam kumpulan datanya.

Untuk pengguna ClusterControl, perhatikan bahwa ini mendukung penyebaran replikasi master-master MySQL dengan batas dua master per cluster replikasi, hanya untuk penyiapan aktif-pasif. Oleh karena itu, ClusterControl tidak dengan sengaja mengonfigurasi master dengan auto_increment_increment dan auto_increment_offset variabel.

Konsistensi Data

Galera Cluster hadir dengan mekanisme kontrol alirannya, di mana setiap node dalam cluster harus mengikuti saat mereplikasi, atau jika tidak, semua node lain harus melambat untuk memungkinkan node yang paling lambat mengejar ketinggalan. Ini pada dasarnya meminimalkan kemungkinan lag budak, meskipun mungkin masih terjadi tetapi tidak sepenting pada replikasi MySQL. Secara default, Galera memungkinkan node menjadi setidaknya 16 transaksi di belakang dalam menerapkan melalui variabel gcs.fc_limit . Jika Anda ingin melakukan pembacaan kritis (PILIH yang harus mengembalikan informasi paling mutakhir), Anda mungkin ingin menggunakan variabel sesi, wsrep_sync_wait .

Galera Cluster di sisi lain hadir dengan perlindungan terhadap inkonsistensi data di mana sebuah node akan diusir dari cluster jika gagal menerapkan writeset apa pun karena alasan apa pun. Misalnya, ketika node Galera gagal menerapkan writeset karena kesalahan internal oleh mesin penyimpanan yang mendasarinya (MySQL/MariaDB), node akan menarik dirinya keluar dari cluster dengan kesalahan berikut:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

Untuk memperbaiki konsistensi data, node yang melanggar harus disinkronkan ulang sebelum diizinkan untuk bergabung dengan cluster. Ini dapat dilakukan secara manual atau dengan menghapus direktori data untuk memicu transfer status snapshot (sinkronisasi penuh dari donor).

Replikasi master-master MySQL tidak menerapkan perlindungan konsistensi data dan slave diizinkan untuk menyimpang misalnya, mereplikasi subset data atau tertinggal, yang membuat slave tidak konsisten dengan master. Ini dirancang untuk mereplikasi data dalam satu aliran - dari master ke slave. Pemeriksaan konsistensi data harus dilakukan secara manual atau melalui alat eksternal seperti Percona Toolkit pt-table-checksum atau mysql-replication-check.

Resolusi Konflik

Umumnya, replikasi master-master (atau multi-master, atau dua arah) memungkinkan lebih dari satu anggota dalam cluster untuk memproses penulisan. Dengan replikasi MySQL, jika terjadi konflik replikasi, utas SQL slave berhenti menerapkan kueri berikutnya hingga konflik teratasi, baik dengan melewatkan acara replikasi secara manual, memperbaiki baris yang melanggar, atau menyinkronkan ulang slave. Sederhananya, tidak ada dukungan resolusi konflik otomatis untuk replikasi MySQL.

Galera Cluster memberikan alternatif yang lebih baik dengan mencoba kembali transaksi yang melanggar selama replikasi. Dengan menggunakan wsrep_retry_autocommit variabel, seseorang dapat menginstruksikan Galera untuk secara otomatis mencoba kembali transaksi yang gagal karena konflik di seluruh cluster, sebelum mengembalikan kesalahan ke klien. Jika diatur ke 0, tidak ada percobaan ulang yang akan dicoba, sementara nilai 1 (default) atau lebih menentukan jumlah percobaan ulang. Ini berguna untuk membantu aplikasi yang menggunakan autocommit untuk menghindari deadlock.

Konsensus dan Kegagalan Node

Galera menggunakan Group Communication System (GCS) untuk memeriksa konsensus node dan ketersediaan antar anggota cluster. Jika node tidak sehat, node tersebut akan secara otomatis dikeluarkan dari cluster setelah gmcast.peer_timeout nilai, default ke 3 detik. Node Galera yang sehat dalam status "Disinkronkan" dianggap sebagai node yang andal untuk melayani membaca dan menulis, sementara yang lain tidak. Desain ini sangat menyederhanakan prosedur pemeriksaan kesehatan dari tingkat atas (penyeimbang beban atau aplikasi).

Dalam replikasi MySQL, master tidak peduli dengan budaknya, sedangkan budak hanya memiliki konsensus dengan master tunggalnya melalui slave_IO_thread proses saat mereplikasi peristiwa biner dari log biner master. Jika master mati, ini akan menghentikan replikasi dan upaya untuk membuat kembali tautan akan dilakukan setiap slave_net_timeout (default ke 60 detik). Dari perspektif aplikasi atau penyeimbang beban, prosedur pemeriksaan kesehatan untuk slave replikasi setidaknya harus mencakup pemeriksaan status berikut:

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• variabel hanya baca
• variabel super_read_only (MySQL 5.7.8 dan yang lebih baru)

Dalam hal failover, secara umum, replikasi master-master dan node Galera adalah sama. Mereka memegang kumpulan data yang sama (walaupun Anda dapat mereplikasi subset data dalam replikasi MySQL, tetapi itu tidak umum untuk master-master) dan berbagi peran yang sama dengan master, mampu menangani membaca dan menulis secara bersamaan. Oleh karena itu, sebenarnya tidak ada failover dari sudut pandang database karena keseimbangan ini. Hanya dari sisi aplikasi yang membutuhkan failover untuk melewati node yang tidak beroperasi. Perlu diingat bahwa karena replikasi MySQL tidak sinkron, ada kemungkinan bahwa tidak semua perubahan yang dilakukan pada master akan disebarkan ke master lainnya.

Penyediaan Node

Proses membawa sebuah node menjadi sinkron dengan cluster sebelum replikasi dimulai, dikenal sebagai provisioning. Dalam replikasi MySQL, penyediaan node baru adalah proses manual. Seseorang harus mengambil cadangan master dan mengembalikannya ke node baru sebelum menyiapkan tautan replikasi. Untuk node replikasi yang ada, jika log biner master telah diputar (berdasarkan expire_logs_days , default ke 0 berarti tidak ada penghapusan otomatis), Anda mungkin harus menyediakan kembali node menggunakan prosedur ini. Ada juga alat eksternal seperti Percona Toolkit pt-table-sync dan ClusterControl untuk membantu Anda dalam hal ini. ClusterControl mendukung sinkronisasi ulang slave hanya dengan dua klik. Anda memiliki opsi untuk menyinkronkan ulang dengan mengambil cadangan dari master aktif atau cadangan yang ada.

Di Galera, ada dua cara untuk melakukan ini - transfer status inkremental (IST) atau transfer snapshot status (SST). Proses IST adalah metode yang disukai di mana hanya transaksi yang hilang yang ditransfer dari cache donor. Proses SST mirip dengan mengambil cadangan penuh dari donor, biasanya cukup intensif sumber daya. Galera akan secara otomatis menentukan proses sinkronisasi mana yang akan dipicu berdasarkan status joiner. Dalam kebanyakan kasus, jika sebuah node gagal untuk bergabung dengan sebuah cluster, cukup hapus datadir MySQL dari node yang bermasalah dan mulai layanan MySQL. Proses penyediaan Galera jauh lebih sederhana, sangat berguna saat menskalakan cluster Anda atau memasukkan kembali node bermasalah ke dalam cluster.

Terpasang Lepas vs Terpasang Kencang

Replikasi MySQL bekerja dengan sangat baik bahkan pada koneksi yang lebih lambat, dan dengan koneksi yang tidak berkelanjutan. Ini juga dapat digunakan di berbagai perangkat keras, lingkungan, dan sistem operasi. Sebagian besar mesin penyimpanan mendukungnya, termasuk MyISAM, Aria, MEMORY, dan ARCHIVE. Pengaturan yang digabungkan secara longgar ini memungkinkan replikasi master-master MySQL bekerja dengan baik di lingkungan campuran dengan sedikit batasan.

Node Galera digabungkan dengan erat, di mana kinerja replikasi secepat node paling lambat. Galera menggunakan mekanisme kontrol aliran untuk mengontrol aliran replikasi di antara anggota dan menghilangkan lag slave. Replikasi bisa cepat atau lambat di setiap node dan diatur secara otomatis oleh Galera. Oleh karena itu, disarankan untuk menggunakan spesifikasi perangkat keras yang seragam untuk semua node Galera, terutama yang berkaitan dengan CPU, RAM, subsistem disk, kartu antarmuka jaringan, dan latensi jaringan antar node dalam cluster.

Kesimpulan

Singkatnya, Galera Cluster lebih unggul jika dibandingkan dengan replikasi master-master MySQL karena dukungan replikasi sinkron dengan konsistensi yang kuat, ditambah fitur yang lebih canggih seperti kontrol keanggotaan otomatis, penyediaan node otomatis dan budak multi-utas. Pada akhirnya, ini tergantung pada bagaimana aplikasi berinteraksi dengan server database. Beberapa aplikasi lawas yang dibuat untuk server database mandiri mungkin tidak berfungsi dengan baik pada penyiapan yang dikelompokkan.

Untuk menyederhanakan poin kami di atas, alasan berikut membenarkan kapan harus menggunakan replikasi master-master MySQL:

• Hal-hal yang tidak didukung oleh Galera:
  • Replikasi untuk tabel non-InnoDB/XtraDB seperti MyISAM, Aria, MEMORY, atau ARCHIVE.
  • Transaksi XA.
  • Replikasi berbasis pernyataan antar master (misalnya, ketika bandwidth sangat mahal).
  • Mengandalkan penguncian eksplisit seperti pernyataan LOCK TABLES.
  • Log kueri umum dan log kueri lambat harus diarahkan ke tabel, bukan file.
• Penyiapan yang digabungkan secara longgar di mana spesifikasi perangkat keras, versi perangkat lunak, dan kecepatan koneksi sangat berbeda pada setiap master.
• Bila Anda sudah memiliki rantai replikasi MySQL dan Anda ingin menambahkan master aktif/cadangan lain untuk redundansi guna mempercepat failover dan waktu pemulihan jika salah satu master tidak tersedia.
• Jika aplikasi Anda tidak dapat dimodifikasi untuk mengatasi keterbatasan Galera Cluster dan memiliki penyeimbang beban berbasis MySQL seperti ProxySQL atau MaxScale bukanlah pilihan.

Alasan memilih Galera Cluster daripada replikasi master-master MySQL:

• Kemampuan untuk menulis dengan aman ke banyak master.
• Konsistensi data dikelola secara otomatis (dan dijamin) di seluruh database.
• Node database baru dengan mudah diperkenalkan dan disinkronkan.
• Kegagalan atau inkonsistensi otomatis terdeteksi.
• Secara umum, fitur ketersediaan tinggi yang lebih canggih dan tangguh.