Cara menggunakan mysql multi channel replication

  • Bisakah saya meningkatkan budak saya dari 5,6 ke 5,7 dan menghubungkan lebih banyak master ke sana?
  • Apakah replikasi multi-sumber memerlukan penggunaan GTID?
  • Situasi apa yang akan menjamin penggunaan pengaturan replikasi multi-sumber?
  • Bagaimana replikasi multi-sumber menangani resolusi konflik?
  • Apakah replikasi multi-sumber akan di-backport ke versi sebelumnya seperti 5.5 atau 5.1?
  • Konsepnya sederhana, tetapi bagaimana cara mengelola semua master berbeda yang terhubung ke slave?
  • Bisakah saya menggunakan budak multi-utas dalam pengaturan replikasi multi-sumber?
  • Bisakah replikasi multi-utas digunakan dengan replikasi semi-sinkron?
  • Bagaimana filter replikasi berlaku sekarang karena ada banyak saluran?
  • Berapa banyak master yang dapat saya tiru untuk satu budak?
  • Replikasi multi-sumber masih sangat baru, apakah ada bagian yang akan berubah?
  • Bisakah replikasi multi-sumber menangani konflik nama database di antara saluran?

Bisakah saya meningkatkan budak saya dari 5,6 ke 5,7 dan menghubungkan lebih banyak master ke sana?

Saat memutakhirkan agar versi master lebih rendah/lebih awal dari versi budak selalu ada risiko besar tidak akan berhasil. Ini karena versi yang lebih baru mungkin telah membuat perubahan yang tidak kompatibel yang berarti versi yang lebih lama tidak akan dapat memproses atau memahami perubahan tersebut di versi yang lebih baru.
Namun, selalu ada kemungkinan bahwa itu akan berhasil, tetapi selalu disarankan bahwa jika Anda ingin pergi dengan cara ini, cobalah pada pengaturan pengujian terlebih dahulu sebelum menerapkannya dalam produksi.

Apakah replikasi multi-sumber memerlukan penggunaan GTID?

Tidak, tetapi penting untuk memastikan bahwa GTID diaktifkan di semua server dalam proses replikasi atau tidak sama sekali. Anda tidak dapat memiliki beberapa menggunakan GTID dan beberapa tidak menggunakan fitur GTID.

Situasi apa yang akan menjamin penggunaan pengaturan replikasi multi-sumber?

Ada sejumlah kasus penggunaan yang melibatkan konsolidasi data dari beberapa server menjadi satu:

  • Kurangi server yang dipecah menjadi satu server pelaporan untuk memberikan laporan dan tampilan yang terkonsolidasi
  • Mirip dengan server pelaporan tunggal, tetapi dalam kasus penggunaan ini akan menjadi server cadangan tunggal
  • Konsolidasi server jarak jauh melalui satu server untuk replikasi-geo dan/atau transfer data

Bagaimana replikasi multi-sumber menangani resolusi konflik?

Dengan beberapa master semua mereplikasi ke satu server, pasti ada konflik di beberapa titik. Cara replikasi multi-sumber menangani hal ini saat ini adalah menyerahkan tanggung jawab kepada pengembang aplikasi. Cara aplikasi menegakkan keamanan dan menghindari konflik adalah dengan memastikan master selalu bekerja pada kumpulan data yang berbeda. Bahkan dengan skenario ini, aplikasi harus mendeteksi pengecualian apa pun dan menanganinya dengan tepat sehingga layanan tidak gagal.

Apakah replikasi multi-sumber akan di-backport ke versi sebelumnya seperti 5.5 atau 5.1?

Jawaban singkatnya adalah – tidak! Ini adalah fitur baru yang membutuhkan kode baru yang hanya tersedia mulai 5.7 dan seterusnya.

Konsepnya sederhana, tetapi bagaimana cara mengelola semua master berbeda yang terhubung ke slave?

Versi 5.7 telah memperkenalkan sintaks baru untuk mengelola perubahan yang ditambahkan dengan replikasi multi-sumber. Penambahan ini sebagian besar adalah FOR CHANNEL dan ALL CHANNELS klausa ke perintah yang ada seperti:

  • GANTI GURU MENJADI…
  • BERHENTI/MULAI BUDAK…
  • LOG RELAY FLUSH…

Bisakah saya menggunakan budak multi-utas dalam pengaturan replikasi multi-sumber?

Ya, ada kemampuan untuk menggunakan budak multi-utas sebagai server penerima untuk replikasi multi-sumber. Namun, harus ditunjukkan bahwa ada dua cara berbeda yang dapat diterapkan – partisi basis data atau pengurutan komit induk. Ini berada di luar cakupan dokumen ini, tetapi Anda dapat memperoleh informasi lebih lanjut dari basis pengetahuan dan/atau online.

Bisakah replikasi multi-utas digunakan dengan replikasi semi-sinkron?

Mirip dengan GTID, jawabannya di sini adalah ya, jika fitur semi-sinkron berjalan di semua server dalam pengaturan replikasi. Anda tidak dapat hanya memiliki sebagian implementasi server semi-sinkron dalam pengaturan replikasi multi-sumber.

Bagaimana filter replikasi berlaku sekarang karena ada banyak saluran?

Filter replikasi diterapkan secara global di semua saluran. Saat ini tidak ada opsi untuk filter per saluran yang akan digunakan.

Berapa banyak master yang dapat saya tiru untuk satu budak?

Begitulah pepatah how long is a piece of stringstasiun! Pada dasarnya tidak ada batasan yang diterapkan di server mengenai berapa banyak master yang dapat direplikasi ke budak, yaitu, berapa banyak saluran yang dapat ditentukan untuk replikasi. Poin penting di sini adalah Anda mempertimbangkan perencanaan kapasitas Anda dan memahami bahwa memiliki 20 server yang mereplikasi ke satu pengaturan yang identik untuk slave, bahkan dengan multi-threading, mungkin akan menyebabkan masalah kinerja.

Replikasi multi-sumber masih sangat baru, apakah ada bagian yang akan berubah?

Area perubahan yang paling jelas adalah penerapan filter replikasi per saluran, dan mungkin membatasi jumlah saluran/master yang dapat direplikasi ke satu slave.

Bisakah replikasi multi-sumber menangani konflik nama database di antara saluran?

Jawabannya adalah TIDAK, tetapi di MySQL 8.0, ini dapat diimplementasikan sebagai –replicate-rewrite-db:channel_1:(db_name1->db_name2)

Juga, filter replikasi berdasarkan saluran telah dikembangkan di 8.0 – https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html