Kami sebelumnya telah membuat blog tentang Apa yang Baru di MySQL Galera Cluster 4.0, Menangani Transaksi Besar dengan Replikasi Streaming dan MariaDB 10.4 dan menyajikan beberapa panduan tentang penggunaan fitur Replikasi Streaming baru di seri bagian 1 &bagian 2.
Memindahkan teknologi database Anda dari Replikasi MySQL ke MySQL Galera Cluster mengharuskan Anda memiliki keterampilan yang tepat dan pemahaman tentang apa yang Anda lakukan agar berhasil. Di blog ini kami akan membagikan beberapa tips untuk bermigrasi dari setup Replikasi MySQL ke MySQL Galera Cluster 4.0 one.
Perbedaan Replikasi MySQL dan Cluster Galera
Jika Anda belum terbiasa dengan Galera, kami menyarankan Anda untuk melihat Tutorial Cluster Galera kami untuk MySQL. Galera Cluster menggunakan tingkat replikasi yang sama sekali berbeda berdasarkan replikasi sinkron, berbeda dengan Replikasi MySQL yang menggunakan replikasi asinkron (tetapi dapat dikonfigurasi juga untuk mencapai replikasi semi-sinkron).
Galera Cluster juga mendukung replikasi multi-master. Ia mampu menerapkan paralel tanpa kendala (yaitu, "replikasi paralel"), replikasi multicast, dan penyediaan node otomatis.
Fokus utama Galera Cluster adalah konsistensi data, sedangkan dengan MySQL Replication, rentan terhadap inkonsistensi data (yang dapat dihindari dengan praktik terbaik dan konfigurasi yang tepat seperti menerapkan read-only pada slave untuk menghindari penulisan yang tidak diinginkan dalam budak).
Meskipun transaksi yang diterima oleh Galera diterapkan ke setiap node atau tidak sama sekali, masing-masing node ini mengesahkan kumpulan tulis yang direplikasi dalam antrean applier (komit transaksi) yang juga mencakup informasi tentang semua kunci yang dipegang oleh database selama transaksi. Perangkat tulis ini, setelah tidak ada kunci konflik yang teridentifikasi, akan diterapkan. Sampai saat ini, transaksi dianggap berkomitmen dan terus menerapkannya ke tablespace. Tidak seperti replikasi asinkron, pendekatan ini juga disebut replikasi virtual sinkron karena penulisan dan komit terjadi dalam mode sinkron logis, tetapi penulisan dan komitmen aktual ke tablespace terjadi secara independen dan berjalan asinkron pada setiap node.
Tidak seperti Replikasi MySQL, Galera Cluster adalah benar-benar multi-master, multi-threaded slave, hot-standby murni, tanpa perlu master-failover atau pemisahan baca-tulis. Namun, bermigrasi ke Galera Cluster tidak berarti jawaban otomatis untuk masalah Anda. Galera Cluster hanya mendukung InnoDB, jadi mungkin ada modifikasi desain jika Anda menggunakan mesin penyimpanan MyISAM atau Memori.
Mengonversi Tabel Non-InnoDB ke InnoDB
Galera Cluster memungkinkan Anda untuk menggunakan MyISAM, tetapi bukan untuk ini Cluster Galera dirancang. Galera Cluster dirancang untuk menerapkan konsistensi data secara ketat di semua node dalam Cluster dan ini membutuhkan mesin database yang kuat dan sesuai dengan ACID. InnoDB adalah mesin yang memiliki kemampuan kuat di bidang ini dan disarankan agar Anda menggunakan InnoDB; terutama saat berurusan dengan transaksi.
Jika Anda menggunakan ClusterControl, Anda dapat dengan mudah menentukan instans database untuk tabel MyISAM apa pun yang disediakan oleh Performance Advisors. Anda dapat menemukannya di tab Performance → Advisors. Misalnya,
Jika Anda memerlukan tabel MyISAM dan MEMORY, Anda masih dapat menggunakannya tetapi membuat pastikan data Anda yang tidak perlu direplikasi. Anda dapat menggunakan data Anda yang disimpan untuk read-only dan, gunakan "MULAI TRANSAKSI READONLY" jika diperlukan.
Menambahkan Kunci Utama ke Tabel InnoDB Anda
Karena Galera Cluster hanya mendukung InnoDB, sangat penting bahwa semua tabel Anda harus memiliki indeks cluster, (juga disebut primary key atau unique key). Untuk mendapatkan kinerja terbaik dari kueri, penyisipan, dan operasi database lainnya, sangat penting bagi Anda untuk mendefinisikan setiap tabel dengan kunci unik karena InnoDB menggunakan indeks berkerumun untuk mengoptimalkan operasi pencarian dan DML yang paling umum untuk setiap tabel . Ini membantu menghindari kueri yang berjalan lama dalam cluster dan kemungkinan dapat memperlambat operasi tulis/baca di cluster.
Di ClusterControl, ada penasihat yang dapat memberi tahu Anda tentang hal ini. Misalnya, di cluster master/slave MySQL Replication Anda, Anda akan mendapatkan alarm dari atau melihat dari daftar penasihat. Contoh tangkapan layar di bawah ini menunjukkan bahwa Anda tidak memiliki tabel yang tidak memiliki kunci utama:
Identifikasi Node Master (atau Penulis Aktif)
Galera Cluster adalah murni replikasi multi-master sejati. Namun, itu tidak berarti bahwa Anda semua bebas untuk menulis simpul mana pun yang ingin Anda targetkan. Satu hal yang perlu diidentifikasi adalah, ketika menulis pada node yang berbeda dan transaksi yang bertentangan akan terdeteksi, Anda akan mengalami masalah kebuntuan seperti di bawah ini:
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;Masalah dengan penulisan beberapa node tanpa mengidentifikasi node penulis aktif saat ini, Anda akan berakhir dengan masalah ini yang merupakan masalah yang sangat umum yang pernah saya lihat saat menggunakan Galera Cluster saat menulis pada beberapa node di waktu yang sama. Untuk menghindari hal ini, Anda dapat menggunakan pendekatan penyiapan master tunggal:
Dari dokumentasi,
Untuk melonggarkan kontrol aliran, Anda dapat menggunakan setelan di bawah ini:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Hal di atas memerlukan restart server karena fc_master_slave tidak dinamis.
Aktifkan Mode Debugging Untuk Konflik atau Kebuntuan Logging
Men-debug atau melacak masalah dengan Galera Cluster Anda sangat penting. Kunci di Galera diimplementasikan secara berbeda dibandingkan dengan Replikasi MySQL. Ini menggunakan penguncian optimis ketika berhadapan dengan transaksi di seluruh cluster. Tidak seperti Replikasi MySQL, ia hanya memiliki penguncian pesimistis yang tidak tahu apakah ada transaksi yang sama atau bertentangan yang dieksekusi di co-master pada pengaturan multi-master. Galera masih menggunakan penguncian pesimis tetapi pada node lokal karena dikelola oleh InnoDB, yang merupakan mesin penyimpanan yang didukung. Galera menggunakan penguncian optimis ketika pergi ke node lain. Ini berarti bahwa tidak ada pemeriksaan yang dilakukan dengan node lain di cluster ketika kunci lokal tercapai (penguncian pesimistis). Galera berasumsi bahwa, setelah transaksi melewati fase komit dalam mesin penyimpanan dan node lain diinformasikan, semuanya akan baik-baik saja dan tidak akan ada konflik yang muncul.
Dalam praktiknya, yang terbaik adalah mengaktifkan wsrep_logs_conflicts. Ini akan mencatat detail MDL yang bertentangan serta kunci InnoDB di cluster. Mengaktifkan variabel ini dapat diatur secara dinamis tetapi peringatan setelah ini diaktifkan. Ini akan mengisi file log kesalahan Anda secara verbose dan dapat mengisi disk Anda setelah ukuran file log kesalahan Anda terlalu besar.
Hati-hati dengan Pertanyaan DDL Anda
Tidak seperti Replikasi MySQL, menjalankan pernyataan ALTER hanya dapat memengaruhi koneksi masuk yang memerlukan akses atau referensi tabel yang ditargetkan oleh pernyataan ALTER Anda. Itu juga dapat mempengaruhi budak jika tabelnya besar dan dapat membawa lag budak. Namun, penulisan ke master Anda tidak akan diblokir selama kueri Anda tidak bertentangan dengan ALTER saat ini. Namun, ini sepenuhnya tidak terjadi ketika menjalankan pernyataan DDL Anda seperti ALTER dengan Galera Cluster. Pernyataan ALTER dapat menyebabkan masalah seperti Cluster Galera macet karena penguncian seluruh cluster atau kontrol aliran mulai mengendurkan replikasi sementara beberapa node pulih dari penulisan besar.
Dalam beberapa situasi, Anda mungkin akan mengalami downtime ke Galera Cluster Anda jika tabel tersebut terlalu besar dan merupakan tabel utama dan vital untuk aplikasi Anda. Namun, itu dapat dicapai tanpa downtime. Seperti yang ditunjukkan Rick James di blognya, Anda dapat mengikuti rekomendasi di bawah ini:
RSU vs TOI
- Rolling Schema Upgrade =melakukan satu node secara manual (offline) pada satu waktu
- Total Order Isolation =Galera menyinkronkan sehingga dilakukan secara bersamaan (dalam urutan replikasi) di semua node. RSU dan TOI
Perhatian:Karena tidak ada cara untuk menyinkronkan klien dengan DDL, Anda harus memastikan bahwa klien puas dengan skema lama atau baru. Jika tidak, Anda mungkin perlu menghapus seluruh cluster sekaligus mengalihkan skema dan kode klien secara bersamaan.
DDL "cepat" juga dapat dilakukan melalui TOI. Ini adalah daftar tentatif seperti:
- BUAT/DROP/GANTI NAMA DATABASE/TABEL
- ALTER untuk mengubah DEFAULT
- ALTER untuk mengubah definisi ENUM atau SET (lihat peringatan di manual)
- PERUBAHAN PARTISI tertentu yang cepat.
- DROP INDEX (selain PRIMARY KEY)
- TAMBAHKAN INDEKS?
- ALTER lainnya pada tabel 'kecil'.
- Dengan 5.6 dan terutama 5.7 memiliki banyak kasus ALTER ALGORITHM=INPLACE, periksa ALTER mana yang harus dilakukan ke arah mana.
Jika tidak, gunakan RSU. Lakukan hal berikut secara terpisah untuk setiap node:
SET GLOBAL wsrep_OSU_method='RSU';Ini juga mengeluarkan node dari cluster.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Memasukkan kembali, mengarah ke sinkronisasi ulang (semoga IST cepat, bukan SST lambat)
Pertahankan Konsistensi Cluster Anda
Galera Cluster tidak mendukung filter replikasi seperti binlog_do_db atau binlog_ignore_db karena Galera tidak bergantung pada pencatatan log biner. Itu bergantung pada file ring-buffer yang juga disebut GCache yang menyimpan set tulis yang direplikasi di sepanjang cluster. Anda tidak dapat menerapkan perilaku atau status yang tidak konsisten dari node database tersebut.
Galera, di sisi lain, secara ketat menerapkan konsistensi data di dalam cluster. Masih mungkin ada inkonsistensi di mana baris atau catatan tidak dapat ditemukan. Misalnya, menyetel variabel Anda wsrep_OSU_method RSU atau TOI untuk pernyataan DDL ALTER Anda mungkin membawa perilaku yang tidak konsisten. Periksa blog eksternal ini dari Percona yang membahas tentang inkonsistensi Galera dengan TOI vs RSU.
Menyetel wsrep_on=OFF dan selanjutnya menjalankan kueri DML atau DDL dapat berbahaya bagi cluster Anda. Anda juga harus meninjau prosedur, pemicu, fungsi, peristiwa, atau tampilan tersimpan Anda jika hasilnya tidak bergantung pada status atau lingkungan node. Ketika node tertentu tidak konsisten, itu berpotensi membawa seluruh cluster turun. Setelah Galera mendeteksi perilaku yang tidak konsisten, Galera akan mencoba meninggalkan cluster dan menghentikan node tersebut. Oleh karena itu, mungkin saja semua node tidak konsisten sehingga Anda berada dalam dilema.
Jika node Galera Cluster juga mengalami crash terutama pada periode lalu lintas tinggi, lebih baik untuk tidak segera memulai node tersebut. Sebagai gantinya, lakukan SST penuh atau bawa instans baru sesegera mungkin atau setelah lalu lintas turun. Ada kemungkinan bahwa node dapat membawa perilaku yang tidak konsisten yang mungkin telah merusak data.
Pisahkan Transaksi Besar dan Tentukan Apakah Akan Menggunakan Replikasi Streaming
Mari kita luruskan yang satu ini. Salah satu fitur perubahan terbesar terutama pada Galera Cluster 4.0 adalah replikasi streaming. Versi sebelumnya dari Galera Cluster 4.0, membatasi transaksi <2GiB yang biasanya dikendalikan oleh variabel wsrep_max_ws_rows dan wsrep_max_ws_size. Sejak Galera Cluster 4.0, Anda dapat mengirim> 2GiB transaksi tetapi Anda harus menentukan seberapa besar fragmen yang harus diproses selama replikasi. Itu harus diatur berdasarkan sesi dan satu-satunya variabel yang perlu Anda perhatikan adalah wsrep_trx_fragment_unit dan wsrep_trx_fragment_size. Menonaktifkan Replikasi Streaming sederhana karena menyetel wsrep_trx_fragment_size = 0 akan melakukannya. Perhatikan bahwa, mereplikasi transaksi besar juga memiliki overhead pada node slave (node yang mereplikasi terhadap node penulis/master aktif saat ini) karena log akan ditulis ke tabel wsrep_streaming_log di database MySQL.
Hal lain untuk ditambahkan, karena Anda berurusan dengan transaksi besar, mungkin perlu waktu untuk menyelesaikan transaksi Anda sehingga pengaturan variabel innodb_lock_wait_timeout tinggi harus diperhitungkan. Setel ini melalui sesi bergantung pada waktu yang Anda perkirakan tetapi lebih besar dari waktu yang Anda perkirakan untuk selesai, jika tidak, naikkan batas waktu.
Sebaiknya Anda membaca blog sebelumnya ini tentang aksi replikasi streaming.
Mereplikasi Pernyataan HIBAH
Jika Anda menggunakan GRANT dan operasi terkait, lakukan tindakan pada tabel MyISAM/Aria di database `mysql`. Pernyataan GRANT akan direplikasi, tetapi tabel yang mendasarinya tidak. Jadi ini berarti, INSERT INTO mysql.user ... tidak akan direplikasi karena tabelnya adalah MyISAM.
Namun, hal di atas mungkin tidak benar lagi karena Percona XtraDB Cluster(PXC) 8.0 (saat ini eksperimental) karena tabel skema mysql telah dikonversi ke InnoDB, sementara di MariaDB 10.4, beberapa tabel masih dalam format Aria tetapi yang lain dalam CSV atau InnoDB. Anda harus menentukan versi dan penyedia Galera yang Anda miliki, tetapi sebaiknya hindari penggunaan pernyataan DML yang merujuk pada skema mysql. Jika tidak, Anda mungkin mendapatkan hasil yang tidak diharapkan kecuali Anda yakin bahwa ini adalah PXC 8.0.
Transaksi XA, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK Tidak Didukung
Cluster Galera tidak mendukung Transaksi XA karena Transaksi XA menangani rollback dan melakukan secara berbeda. Pernyataan LOCK/UNLOCK atau GET_LOCK/RELEASE_LOCK berbahaya untuk diterapkan atau digunakan dengan Galera. Anda mungkin mengalami crash atau kunci yang tidak dapat dimatikan dan tetap terkunci. Misalnya,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5Transaksi ini telah dibuka dan bahkan dimatikan tetapi tidak berhasil. Kami menyarankan Anda untuk mendesain ulang klien aplikasi Anda dan menyingkirkan fungsi-fungsi ini saat bermigrasi ke Galera Cluster.
Stabilitas Jaringan adalah KEHARUSAN!!!
Galera Cluster dapat bekerja bahkan dengan topologi antar-WAN atau topologi antar-geo tanpa masalah (lihat blog ini tentang penerapan topologi antar-geo dengan Galera). Namun, jika konektivitas jaringan Anda antara setiap node tidak stabil atau terputus-putus untuk waktu yang tidak terduga, hal itu dapat menimbulkan masalah bagi cluster. Sebaiknya Anda memiliki cluster yang berjalan di jaringan pribadi dan lokal di mana masing-masing node ini terhubung. Saat merancang sebuah node sebagai pemulihan bencana, maka rencanakan untuk membuat sebuah cluster jika ini berada di wilayah atau geografi yang berbeda. Anda dapat mulai membaca blog kami sebelumnya, Menggunakan Replikasi Cluster Galera MySQL untuk Membuat Cluster Geo-Distributed:Bagian Satu karena ini dapat membantu Anda menentukan topologi Cluster Galera Anda.
Hal lain untuk ditambahkan tentang menginvestasikan perangkat keras jaringan Anda, akan menjadi masalah jika kecepatan transfer jaringan Anda memberi Anda kecepatan yang lebih rendah selama membangun kembali sebuah instance selama IST atau lebih buruk di SST terutama jika kumpulan data Anda sangat besar . Ini bisa memakan waktu berjam-jam untuk transfer jaringan dan itu mungkin mempengaruhi stabilitas cluster Anda terutama jika Anda memiliki cluster 3-node sementara 2 node tidak tersedia di mana 2 ini adalah donor dan joiner. Perhatikan bahwa, selama fase SST, node DONOR/JOINER tidak dapat digunakan sampai akhirnya dapat disinkronkan dengan cluster utama.
Di Galera versi sebelumnya, dalam hal pemilihan node donor, donor State Snapshot Transfer (SST) dipilih secara acak. Di Glera 4, ini jauh lebih baik dan memiliki kemampuan untuk memilih donor yang tepat di dalam cluster, karena akan mendukung donor yang dapat memberikan Incremental State Transfer (IST), atau memilih donor di segmen yang sama. Atau, Anda dapat menyetel variabel wsrep_sst_donor ke donor yang tepat yang selalu ingin Anda pilih.
Cadangkan Data Anda dan Lakukan Pengujian Kaku Selama Migrasi dan Sebelum Produksi
Setelah Anda siap dan memutuskan untuk mencoba dan memigrasikan data Anda ke Galera Cluster 4.0, pastikan Anda selalu menyiapkan cadangan. Jika Anda mencoba ClusterControl, melakukan backup akan lebih mudah.
Pastikan Anda bermigrasi ke versi InnoDB yang benar dan jangan lupa untuk selalu menerapkan dan menjalankan mysql_upgrade sebelum melakukan pengujian. Pastikan bahwa semua pengujian Anda melewati hasil yang diinginkan yang dapat ditawarkan oleh Replikasi MySQL kepada Anda. Kemungkinan besar, tidak ada perbedaan dengan mesin penyimpanan InnoDB yang Anda gunakan di Cluster Replikasi MySQL versus Cluster MySQL Galera selama rekomendasi dan tips telah diterapkan dan disiapkan sebelumnya.
Kesimpulan
Migrasi ke Galera Cluster 4.0 mungkin bukan solusi teknologi database yang Anda inginkan. Namun, itu tidak menarik Anda untuk menggunakan Galera Cluster 4.0 selama persyaratan spesifiknya dapat disiapkan, disiapkan, dan disediakan. Galera Cluster 4.0 kini telah menjadi pilihan dan opsi yang sangat kuat terutama pada platform dan solusi yang sangat tersedia. Kami juga menyarankan Anda untuk membaca blog eksternal ini tentang Peringatan Galera atau Batasan Cluster Galera atau manual ini dari MariaDB.
