Kesalahan Teratas yang Harus Dihindari dalam Replikasi MySQL

Menyiapkan replikasi di MySQL itu mudah, tetapi mengelolanya dalam produksi tidak pernah menjadi tugas yang mudah. Bahkan dengan pemosisian otomatis GTID yang lebih baru, masih bisa salah jika Anda tidak tahu apa yang Anda lakukan. Setelah mengatur replikasi, segala macam hal bisa salah. Kesalahan dapat dengan mudah dibuat dan dapat berakhir dengan bencana bagi data Anda.

Postingan ini akan menyoroti beberapa kesalahan paling umum yang dibuat dengan replikasi MySQL, dan bagaimana Anda dapat mencegahnya.

Menyiapkan Replikasi

Saat mengatur replikasi MySQL, Anda perlu melakukan prime pada node slave dengan dataset dari master. Dengan solusi seperti Galera cluster, ini secara otomatis ditangani untuk Anda dengan metode pilihan Anda. Untuk replikasi MySQL, Anda perlu melakukannya sendiri, jadi tentu saja Anda menggunakan alat pencadangan standar.

Untuk MySQL ada berbagai macam alat pencadangan yang tersedia, tetapi yang paling umum digunakan adalah mysqldump. Mysqldump mengeluarkan cadangan logis dari kumpulan data master Anda. Ini berarti salinan data tidak akan menjadi salinan biner, tetapi file besar yang berisi kueri untuk membuat ulang kumpulan data Anda. Dalam kebanyakan kasus, ini akan memberi Anda salinan data Anda (hampir) identik, tetapi ada kasus di mana itu tidak akan terjadi - karena dump berada pada basis per objek. Artinya, bahkan sebelum Anda mulai mereplikasi data, set data Anda tidak sama dengan yang ada di master.

Ada beberapa penyesuaian yang dapat Anda lakukan untuk membuat mysqldump lebih andal seperti dump sebagai satu transaksi, dan juga jangan lupa untuk menyertakan rutin dan pemicu:

mysqldump -uuser -ppass --single-transaction --routines --triggers --all-databases > dumpfile.sql

Praktik yang baik adalah memeriksa apakah node slave Anda 100% sama, yaitu dengan menggunakan pt-table-checksum setelah menyiapkan replikasi:

pt-table-checksum --replicate=test.checksums --ignore-databases mysql h=localhost,u=user,p=pass

Alat ini akan menghitung checksum untuk setiap tabel pada master, mereplikasi perintah ke slave dan kemudian node slave akan melakukan operasi checksum yang sama. Jika ada tabel yang tidak sama, ini harus terlihat jelas di tabel checksum.

Menggunakan Metode Replikasi yang Salah

Metode replikasi default MySQL adalah yang disebut replikasi berbasis pernyataan. Metode ini persis seperti itu:aliran replikasi dari setiap pernyataan yang dijalankan pada master yang akan diputar ulang pada node budak. Karena MySQL sendiri adalah multi-utas tetapi replikasi (tradisional) tidak, urutan pernyataan dalam aliran replikasi mungkin tidak 100% sama. Memutar ulang pernyataan juga dapat memberikan hasil yang berbeda jika tidak dieksekusi pada waktu yang sama persis.

Hal ini dapat mengakibatkan kumpulan data yang berbeda antara master dan slave, karena penyimpangan data. Ini bukan masalah selama bertahun-tahun, karena tidak banyak yang menjalankan MySQL dengan banyak utas simultan, tetapi dengan arsitektur multi-CPU modern, ini sebenarnya menjadi sangat mungkin pada beban kerja normal sehari-hari.

Jawaban dari MySQL adalah apa yang disebut replikasi berbasis baris. Replikasi berbasis baris akan mereplikasi data bila memungkinkan, tetapi dalam beberapa kasus luar biasa masih menggunakan pernyataan. Contoh yang baik adalah perubahan tabel DLL, di mana replikasi kemudian harus menyalin setiap baris dalam tabel melalui replikasi. Karena ini tidak efisien, pernyataan seperti itu akan direplikasi dengan cara tradisional. Ketika replikasi berbasis baris mendeteksi penyimpangan data, itu akan menghentikan utas budak untuk mencegah hal-hal yang lebih buruk.

Lalu ada metode di antara keduanya:replikasi mode campuran. Jenis replikasi ini akan selalu mereplikasi pernyataan, kecuali jika kueri berisi fungsi UUID(), pemicu, prosedur tersimpan, UDF, dan beberapa pengecualian lainnya digunakan. Mode campuran tidak akan menyelesaikan masalah penyimpangan data dan, bersama dengan replikasi berbasis pernyataan, harus dihindari.

Replikasi Melingkar

Menjalankan replikasi MySQL dengan multi-master sering kali diperlukan jika Anda memiliki lingkungan multi-pusat data. Karena aplikasi tidak bisa menunggu master di pusat data lain untuk mengakui tulisan Anda, master lokal lebih disukai. Biasanya offset kenaikan otomatis digunakan untuk mencegah bentrokan data antara master. Memiliki dua master yang melakukan penulisan satu sama lain dengan cara ini adalah solusi yang diterima secara luas.

Namun jika Anda perlu menulis di beberapa pusat data ke dalam database yang sama, Anda akan berakhir dengan beberapa master yang perlu menulis data mereka satu sama lain. Sebelum MySQL 5.7.6 tidak ada metode untuk melakukan replikasi tipe mesh, jadi alternatifnya adalah menggunakan replikasi cincin melingkar sebagai gantinya.

Replikasi dering di MySQL bermasalah karena alasan berikut:latensi, ketersediaan tinggi, dan penyimpangan data. Menulis beberapa data ke server A, dibutuhkan tiga lompatan untuk berakhir di server D (melalui server B dan C). Karena replikasi MySQL (tradisional) adalah utas tunggal, setiap kueri yang berjalan lama dalam replikasi dapat menghentikan seluruh ring. Juga jika salah satu server mati, ring akan rusak dan saat ini tidak ada perangkat lunak failover yang dapat memperbaiki struktur ring. Kemudian penyimpangan data dapat terjadi ketika data ditulis ke server A dan diubah pada saat yang sama di server C atau D.

Secara umum replikasi sirkular tidak cocok dengan MySQL dan harus dihindari dengan cara apa pun. Galera akan menjadi alternatif yang baik untuk penulisan multi-pusat data, karena telah dirancang dengan mempertimbangkan hal tersebut.

Menghentikan Replikasi Anda dengan Pembaruan Besar

Seringkali berbagai pekerjaan batch housekeeping akan melakukan berbagai tugas, mulai dari membersihkan data lama hingga menghitung rata-rata 'suka' yang diambil dari sumber lain. Ini berarti pada interval yang ditentukan, pekerjaan akan membuat banyak aktivitas basis data dan, kemungkinan besar, menulis banyak data kembali ke basis data. Secara alami ini berarti aktivitas dalam aliran replikasi akan meningkat secara merata.

Replikasi berbasis pernyataan akan mereplikasi kueri persis yang digunakan dalam tugas batch, jadi jika kueri membutuhkan waktu setengah jam untuk diproses di master, utas budak akan terhenti setidaknya untuk jumlah waktu yang sama. Ini berarti tidak ada data lain yang dapat direplikasi dan node slave akan mulai tertinggal di belakang master. Jika ini melebihi ambang batas alat failover atau proxy Anda, mungkin akan menjatuhkan node slave ini dari node yang tersedia di cluster. Jika Anda menggunakan replikasi berbasis pernyataan, Anda dapat mencegahnya dengan mengolah data untuk tugas Anda dalam kumpulan yang lebih kecil.

Sekarang Anda mungkin berpikir replikasi berbasis baris tidak terpengaruh oleh ini, karena ini akan mereplikasi informasi baris alih-alih kueri. Ini sebagian benar, karena untuk perubahan DDL, replikasi kembali ke format berbasis pernyataan. Juga sejumlah besar operasi CRUD akan mempengaruhi aliran replikasi:dalam banyak kasus ini masih merupakan operasi berulir tunggal dan dengan demikian setiap transaksi akan menunggu yang sebelumnya diputar ulang melalui replikasi. Ini berarti bahwa jika Anda memiliki konkurensi yang tinggi pada master, slave dapat menghentikan transaksi yang berlebihan selama replikasi.

Untuk menyiasatinya, MariaDB dan MySQL menawarkan replikasi paralel. Implementasinya mungkin berbeda per vendor dan versi. MySQL 5.6 menawarkan replikasi paralel selama kueri dipisahkan oleh skema. MariaDB 10.0 dan MySQL 5.7 keduanya dapat menangani replikasi paralel di seluruh skema, tetapi memiliki batasan lain. Menjalankan kueri melalui utas budak paralel dapat mempercepat aliran replikasi Anda jika Anda menulis banyak. Namun jika tidak, sebaiknya tetap menggunakan replikasi utas tunggal tradisional.

Perubahan Skema

Melakukan perubahan skema pada penyiapan produksi yang berjalan selalu menyusahkan. Ini berkaitan dengan fakta bahwa perubahan DDL sebagian besar waktu akan mengunci tabel dan hanya melepaskan kunci ini setelah perubahan DDL diterapkan. Ini bahkan menjadi lebih buruk setelah Anda mulai mereplikasi perubahan DDL ini melalui replikasi MySQL, yang juga akan menghentikan aliran replikasi.

Solusi yang sering digunakan adalah menerapkan perubahan skema ke node slave terlebih dahulu. Untuk replikasi berbasis pernyataan ini berfungsi dengan baik, tetapi untuk replikasi berbasis baris ini dapat bekerja hingga tingkat tertentu. Replikasi berbasis baris memungkinkan kolom tambahan ada di akhir tabel, jadi selama ia mampu menulis kolom pertama, itu akan baik-baik saja. Pertama-tama terapkan perubahan ke semua budak, lalu failover ke salah satu budak dan kemudian terapkan perubahan ke master dan lampirkan itu sebagai budak. Jika perubahan Anda melibatkan penyisipan kolom di tengah atau penghapusan kolom, ini akan berfungsi dengan replikasi berbasis baris.

Ada alat di sekitar yang dapat melakukan perubahan skema online dengan lebih andal. Perubahan Skema Online Percona (dikenal sebagai pt-osc) akan membuat tabel bayangan dengan struktur tabel baru, menyisipkan data baru melalui pemicu dan mengisi ulang data di latar belakang. Setelah selesai membuat tabel baru, itu hanya akan menukar yang lama dengan tabel baru di dalam transaksi. Ini tidak berfungsi di semua kasus, terutama jika tabel Anda yang ada sudah memiliki pemicu.

Alternatifnya adalah alat Gh-ost baru oleh Github. Alat perubahan skema online ini pertama-tama akan membuat salinan tata letak tabel yang ada, mengubah tabel ke tata letak baru, lalu menghubungkan prosesnya sebagai replika MySQL. Ini akan menggunakan aliran replikasi untuk menemukan baris baru yang telah dimasukkan ke dalam tabel asli dan pada saat yang sama mengisi ulang tabel. Setelah pengisian ulang selesai, tabel asli dan baru akan beralih. Secara alami semua operasi ke tabel baru akan berakhir di aliran replikasi juga, sehingga pada setiap replika migrasi terjadi pada waktu yang sama.

Tabel Memori dan Replikasi

Saat kita membahas masalah DDL, masalah umum adalah pembuatan tabel memori. Tabel memori adalah tabel non-persisten, struktur tabelnya tetap ada tetapi mereka kehilangan datanya setelah restart MySQL. Saat membuat tabel memori baru pada master dan slave, keduanya akan memiliki tabel kosong dan ini akan berfungsi dengan baik. Setelah salah satunya dimulai ulang, tabel akan dikosongkan dan kesalahan replikasi akan terjadi.

Replikasi berbasis baris akan rusak setelah data di node budak mengembalikan hasil yang berbeda, dan replikasi berbasis pernyataan akan berhenti setelah mencoba memasukkan data yang sudah ada. Untuk tabel memori, ini adalah pemutus replikasi yang sering. Cara mengatasinya mudah:cukup buat salinan data baru, ubah mesin ke InnoDB dan sekarang seharusnya replikasi aman.

Menyetel Variabel read_only ke True

Seperti yang kami jelaskan sebelumnya, tidak memiliki data yang sama di node slave dapat merusak replikasi. Seringkali ini disebabkan oleh sesuatu (atau seseorang) yang mengubah data pada node slave, tetapi tidak pada node master. Setelah data master node diubah, ini akan direplikasi ke slave di mana ia tidak dapat menerapkan perubahan dan ini menyebabkan replikasi rusak.

Ada pencegahan mudah untuk ini:menyetel variabel read_only ke true. Ini akan melarang siapa pun untuk membuat perubahan pada data, kecuali untuk replikasi dan pengguna root. Sebagian besar pengelola failover menyetel tanda ini secara otomatis untuk mencegah pengguna menulis ke master yang digunakan selama failover. Beberapa dari mereka bahkan mempertahankan ini setelah failover.

Ini masih meninggalkan pengguna root untuk mengeksekusi kueri CRUD yang salah pada node budak. Untuk mencegah hal ini terjadi, ada variabel super_read_only sejak MySQL 5.7.8 yang bahkan mengunci pengguna root untuk memperbarui data.

Mengaktifkan GTID

Dalam replikasi MySQL, sangat penting untuk memulai slave dari posisi yang benar di log biner. Memperoleh posisi ini dapat dilakukan saat membuat cadangan (xtrabackup dan mysqldump mendukung ini) atau ketika Anda telah berhenti bekerja pada simpul yang Anda buat salinannya. Memulai replikasi dengan perintah CHANGE MASTER TO akan terlihat seperti ini:

mysql> CHANGE MASTER TO MASTER_HOST='x.x.x.x',MASTER_USER='replication_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='master-bin.0001', MASTER_LOG_POS=  04;

Memulai replikasi di tempat yang salah dapat berakibat fatal:data mungkin ditulis ganda atau tidak diperbarui. Hal ini menyebabkan penyimpangan data antara master dan node slave.

Juga ketika gagal atas master ke budak melibatkan menemukan posisi yang benar dan mengubah master ke host yang sesuai. MySQL tidak menyimpan log dan posisi biner dari masternya, melainkan membuat log dan posisi binernya sendiri. Untuk menyelaraskan kembali node slave ke master baru, ini bisa menjadi masalah serius:posisi master yang tepat saat failover harus ditemukan di master baru, dan kemudian semua slave dapat disejajarkan kembali.

Untuk mengatasi masalah ini, Pengidentifikasi Transaksi Global (GTID) telah diterapkan oleh Oracle dan MariaDB. GTID memungkinkan penyelarasan otomatis dari budak, dan di MySQL dan MariaDB server mengetahui dengan sendirinya apa posisi yang benar. Namun keduanya telah mengimplementasikan GTID dengan cara yang berbeda dan karena itu tidak kompatibel. Jika Anda perlu mengatur replikasi dari satu ke yang lain, replikasi harus diatur dengan pemosisian log biner tradisional. Perangkat lunak failover Anda juga harus disadarkan untuk tidak menggunakan GTID.

Kesimpulan

Kami berharap telah memberi Anda cukup tips untuk menghindari masalah. Ini semua adalah praktik umum oleh para ahli di MySQL. Mereka harus mempelajarinya dengan susah payah dan dengan tips ini kami memastikan Anda tidak perlu melakukannya.

Kami memiliki beberapa kertas putih tambahan yang mungkin berguna jika Anda ingin membaca lebih lanjut tentang replikasi MySQL.