Buku putih ini mencakup informasi tentang Replikasi MySQL, dengan informasi tentang fitur terbaru yang diperkenalkan di 5. 6, 5. 7 dan 8. 0. Ada juga bagian yang lebih praktis dan praktis tentang cara menerapkan dan mengelola penyiapan replikasi dengan cepat menggunakan ClusterControl
Isi dari whitepaper
- pengantar
- Apa itu replikasi MySQL
- Topologi untuk replikasi MySQL
- Menerapkan penyiapan replikasi MySQL
- Menghubungkan aplikasi ke pengaturan replikasi
- Failover dengan ClusterControl
- Mengelola pengaturan replikasi Mysql Anda
- Masalah dan pemecahan masalah
Unduh kertas putih
1. pengantar
Replikasi MySQL mungkin adalah solusi ketersediaan tinggi paling populer untuk MySQL, dan banyak digunakan oleh properti web teratas seperti Twitter dan Facebook. Meskipun mudah diatur, pemeliharaan berkelanjutan seperti pemutakhiran perangkat lunak, perubahan skema, perubahan topologi, failover, dan pemulihan selalu rumit. Setidaknya sampai MySQL 5. 6
Untungnya, MySQL5. 6 membawa sejumlah peningkatan signifikan pada Replikasi, termasuk ID Transaksi Global, checksum peristiwa, budak multi-utas, dan budak/master yang aman dari kerusakan. Replikasi menjadi lebih baik dengan MySQL 5. 7 dan MySQL 8. 0
Sumber daya terkait
- Whitepaper Cetak Biru Replikasi MySQL
Tutorial ini mencakup informasi dasar tentang Replikasi MySQL, dengan informasi tentang fitur-fitur yang diperkenalkan di 5. 6, 5. 7 dan 8. 0. Pada akhirnya, Anda harus bisa menjawab pertanyaan seperti
- Bagaimana cara menggunakan GTID dengan replikasi?
- Bagaimana cara memulihkan pengaturan saya jika master saya gagal?
- Bagaimana cara mengupgrade server master dan slave tanpa downtime?
- Bagaimana cara mengubah skema database saya di semua server?
- Bagaimana cara menangani slave lag?
- dll.
Ada juga bagian yang lebih praktis dan praktis tentang cara menerapkan dan mengelola penyiapan replikasi dengan cepat menggunakan ClusterControl. Anda memerlukan 4 host/VM jika Anda berencana melakukan ini
2. Apa itu Replikasi MySQL?
Replikasi memungkinkan data dari satu server MySQL [master] untuk direplikasi ke satu atau lebih server MySQL [budak]. Replikasi MySQL sangat mudah untuk disiapkan, dan digunakan untuk menskalakan beban kerja baca, menyediakan ketersediaan tinggi dan redundansi geografis, serta membongkar pencadangan dan pekerjaan analitik
2. 1. Skema Replikasi
Saat ini ada dua skema replikasi yang didukung oleh Replikasi MySQL
- Replikasi asinkron
- Replikasi semi-sinkron
Tidak ada batasan dalam mencampur skema replikasi dalam topologi yang sama. keduanya memiliki pro dan kontra. Pada saat penulisan, tidak ada solusi yang sepenuhnya sinkron untuk replikasi MySQL
2. 1. 1. Replikasi Asinkron
Replikasi MySQL secara default tidak sinkron. Ini adalah skema replikasi tertua, paling populer dan banyak digunakan. Dengan replikasi asinkron, master menulis peristiwa ke log binernya dan budak memintanya saat sudah siap. Tidak ada jaminan bahwa peristiwa apa pun akan mencapai budak mana pun. Ini adalah hubungan tuan-budak yang digabungkan secara longgar, di mana
- Tuan tidak menunggu Budak
- Budak menentukan berapa banyak yang harus dibaca dan dari titik mana dalam log biner
- Slave dapat secara sewenang-wenang berada di belakang master dalam membaca atau menerapkan perubahan
Jika master macet, transaksi yang telah dilakukannya mungkin tidak akan dikirimkan ke budak mana pun. Akibatnya, failover dari master ke slave dalam hal ini dapat mengakibatkan failover ke server yang kehilangan transaksi relatif terhadap master
Replikasi asinkron memberikan latensi penulisan yang lebih rendah, karena penulisan diakui secara lokal oleh master sebelum ditulis ke budak. Ini bagus untuk penskalaan baca karena menambahkan lebih banyak replika tidak memengaruhi latensi replikasi. Kasus penggunaan yang baik untuk replikasi asinkron mencakup penerapan replika baca untuk penskalaan baca, salinan cadangan langsung untuk pemulihan bencana, dan analitik/pelaporan
2. 1. 2. Replikasi Semi-Sinkron
MySQL juga mendukung replikasi semi-sinkron, di mana master tidak mengonfirmasi transaksi ke klien hingga setidaknya satu budak menyalin perubahan ke log relai, dan membilasnya ke disk. Untuk mengaktifkan replikasi semi-sinkron, diperlukan langkah tambahan untuk penginstalan plugin, dan harus diaktifkan pada master dan slave MySQL yang ditunjuk
Semi-sinkron tampaknya menjadi solusi yang baik dan praktis untuk banyak kasus di mana ketersediaan tinggi dan tidak ada kehilangan data penting. Tetapi Anda harus mempertimbangkan bahwa semi-sinkronisasi berdampak pada kinerja karena perjalanan bolak-balik tambahan dan tidak memberikan jaminan yang kuat terhadap kehilangan data. Ketika komit berhasil kembali, diketahui bahwa data ada setidaknya di dua tempat [di master dan setidaknya satu budak]. Jika master melakukan tetapi crash terjadi saat master menunggu pengakuan dari seorang budak, ada kemungkinan bahwa transaksi tersebut mungkin tidak mencapai budak mana pun. Ini bukan masalah besar karena komit tidak akan dikembalikan ke aplikasi dalam kasus ini. Merupakan tugas aplikasi untuk mencoba kembali transaksi di masa mendatang. Yang penting untuk diingat adalah, ketika master gagal dan seorang budak telah dipromosikan, master lama tidak dapat bergabung dengan rantai replikasi. Dalam beberapa keadaan ini dapat menyebabkan konflik dengan data pada budak [ketika master crash setelah budak menerima peristiwa log biner tetapi sebelum master mendapat pengakuan dari budak]. Jadi satu-satunya cara yang aman adalah membuang data pada master lama dan menyediakannya dari awal menggunakan data dari master yang baru dipromosikan
Kasus penggunaan yang baik untuk replikasi semi-sinkron adalah master cadangan untuk mengurangi dampak kegagalan master dengan meminimalkan risiko kehilangan data. Kami akan menjelaskan ini secara rinci di bawah 'Bab 3 – Topologi untuk Replikasi MySQL'
2. 2. Pengenal Transaksi Global [GTID]
Pengidentifikasi Transaksi Global [GTID] diperkenalkan di MySQL 5. 6. GTID adalah pengidentifikasi unik yang dibuat dan dikaitkan dengan setiap transaksi yang dilakukan di server asal [master]. Pengidentifikasi ini unik tidak hanya untuk server tempat asalnya, tetapi juga unik di semua server dalam penyiapan replikasi yang diberikan. Ada pemetaan satu-ke-satu antara semua transaksi dan semua GTID. Perhatikan bahwa MySQL dan MariaDB memiliki implementasi GTID yang berbeda, seperti yang akan kami jelaskan lebih lanjut
2. 2. 1. Replikasi di MySQL 5. 5 dan Sebelumnya
Di MySQL5. 5, melanjutkan penyiapan replikasi yang rusak mengharuskan Anda untuk menentukan file dan posisi log biner terakhir, yang berbeda pada node jika pencatatan biner diaktifkan. Jika master MySQL gagal, replikasi terhenti dan budak harus beralih ke master lain. Anda perlu mempromosikan node budak yang paling baru untuk menjadi master, dan secara manual menentukan file log biner baru dan posisi transaksi terakhir yang dijalankan oleh budak. Opsi lainnya adalah membuang data dari node master baru, mengembalikannya ke slave, dan memulai replikasi dengan node master baru. Opsi ini tentu saja bisa dilakukan, tetapi tidak terlalu praktis dalam produksi
2. 2. 2. Bagaimana GTID Memecahkan Masalah
GTID [Pengidentifikasi Transaksi Global] memberikan pemetaan transaksi yang lebih baik di seluruh node. Di MySQL5. 5. atau sebelumnya, Replikasi bekerja sedemikian rupa sehingga semua node akan menghasilkan file binlog yang berbeda. Peristiwa Binlog sama dan dalam urutan yang sama, tetapi offset file binlog mungkin berbeda. Dengan GTID, budak dapat melihat transaksi unik yang masuk dari beberapa master dan ini dapat dengan mudah dipetakan ke dalam daftar eksekusi budak jika perlu memulai ulang atau melanjutkan replikasi
Setiap transaksi memiliki pengidentifikasi unik yang mengidentifikasinya dengan cara yang sama di setiap server. Tidak penting lagi di mana posisi log biner suatu transaksi dicatat, yang perlu Anda ketahui hanyalah GTID. '966073f3-b6a4-11e4-af2c-080027880ca6. 4'. GTID dibangun dari dua bagian – pengidentifikasi unik server tempat transaksi pertama kali dijalankan, dan nomor urut. Pada contoh di atas, kita dapat melihat bahwa transaksi dijalankan oleh server dengan server_uuid dari '966073f3-b6a4-11e4-af2c-080027880ca6' dan merupakan transaksi ke-4 yang dijalankan di sana. Informasi ini cukup untuk melakukan perubahan topologi yang kompleks – MySQL mengetahui transaksi mana yang telah dijalankan dan karenanya mengetahui transaksi mana yang harus dijalankan selanjutnya. Lupakan log biner, sekarang semuanya ada di GTID
Semua informasi yang diperlukan untuk sinkronisasi dengan master dapat diperoleh langsung dari aliran replikasi. Saat Anda menggunakan GTID untuk replikasi, Anda tidak perlu menyertakan opsi MASTER_LOG_FILE atau MASTER_LOG_POS dalam pernyataan CHANGE MASTER TO;
2. 2. 3. MariaDB GTID vs MySQL GTID
MariaDB memiliki implementasi yang berbeda dari Global Transaction ID [GTID], dan diaktifkan secara default mulai dari MariaDB 10. 0. 2. GTID MariaDB terdiri dari tiga nilai terpisah
- ID Domain – Domain replikasi. Domain replikasi adalah server atau grup server yang menghasilkan aliran replikasi tunggal yang dipesan secara ketat
- Server ID – Nomor pengidentifikasi server untuk mengaktifkan server master dan slave untuk mengidentifikasi diri mereka sendiri secara unik
- ID Grup Peristiwa – Nomor urut untuk kumpulan peristiwa yang selalu diterapkan sebagai unit. Setiap grup acara binlog [mis. transaksi, DDL, pernyataan non-transaksional] dianotasi dengan GTID-nya
Gambar di bawah mengilustrasikan perbedaan antara kedua GTID
Di MariaDB, tidak diperlukan konfigurasi khusus di server untuk mulai menggunakan GTID. Beberapa keunggulan MariaDB GTID
- Sangat mudah untuk mengidentifikasi dari server atau domain mana grup acara berasal
- Anda tidak perlu mengaktifkan logging biner pada budak
- Ini memungkinkan replikasi multi-sumber dengan ID domain yang berbeda
- Mengaktifkan fitur GTID bersifat dinamis, Anda tidak perlu memulai ulang server MariaDB
- Keadaan budak direkam dengan cara yang aman dari kecelakaan
Terlepas dari perbedaan antara keduanya, masih mungkin untuk mereplikasi dari MySQL 5. 6 hingga MariaDB 10. 0 atau sebaliknya. Namun, Anda tidak akan dapat menggunakan fitur GTID untuk memilih posisi binlog yang benar secara otomatis saat beralih ke master baru. Replikasi MySQL gaya lama akan berfungsi
Bacaan lebih lanjut dapat ditemukan di halaman dokumentasi MariaDB GTID dan MySQL GTID
2. 3. Budak Multi-Utas
MySQL5. 6 memungkinkan Anda untuk mengeksekusi peristiwa yang direplikasi secara paralel selama data dibagi menjadi beberapa database. Fitur ini bernama “Multi-Threaded Slave” [MTS] dan mudah diaktifkan dengan menyetel slave_parallel_workers ke nilai > 1. Di MySQL5. 7, sekarang dapat digunakan untuk semua beban kerja, termasuk intra-skema, tidak seperti 5. 6 di mana itu hanya bisa diterapkan dengan satu utas per skema. MySQL8. 0 memperkenalkan kumpulan tulis, yang memungkinkan paralelisasi yang lebih baik dalam menerapkan peristiwa log biner
2. 4. Budak yang Aman dari Kecelakaan
Crash safe berarti bahkan jika slave mysqld/OS crash, Anda dapat memulihkan slave dan melanjutkan replikasi tanpa memulihkan database MySQL ke slave. Agar budak yang aman dari kecelakaan berfungsi, Anda harus menggunakan mesin penyimpanan InnoDB saja, dan di 5. 6 Anda perlu mengatur relay_log_info_repository=TABLE dan relay_log_recovery=1
Daya tahan [sync_binlog = 1 dan innodb_flush_log_at_trx_commit = 1] TIDAK diperlukan
2. 5. Komitmen Grup
InnoDB, seperti mesin database yang sesuai dengan ACID lainnya, menghapus log redo transaksi sebelum dilakukan. InnoDB menggunakan fungsionalitas komit grup untuk mengelompokkan beberapa permintaan flush tersebut bersama-sama untuk menghindari satu flush untuk setiap komit. Dengan komit grup, InnoDB mengeluarkan satu penulisan ke file log untuk melakukan tindakan komit untuk beberapa transaksi pengguna yang dilakukan pada waktu yang sama, secara signifikan meningkatkan throughput
3. Topologi untuk Replikasi MySQL
3. 1. Guru dengan Budak [Replikasi Tunggal]
Ini topologi replikasi MySQL yang paling mudah. Satu master menerima penulisan, satu atau lebih budak mereplikasi dari master yang sama melalui replikasi asinkron atau semi-sinkron. Jika master yang ditunjuk turun, budak terbaru harus dipromosikan sebagai master baru. Budak yang tersisa melanjutkan replikasi dari master baru
3. 2. Master dengan Budak Relai [Replikasi Rantai]
Pengaturan ini menggunakan master perantara untuk bertindak sebagai relai ke budak lain dalam rantai replikasi. Ketika ada banyak budak yang terhubung ke master, antarmuka jaringan master bisa kelebihan beban. Topologi ini memungkinkan replika baca untuk menarik aliran replikasi dari server relai untuk membongkar server master. Pada server relai budak, logging biner dan log_slave_updates harus diaktifkan, di mana pembaruan yang diterima oleh server slave dari server master dicatat ke log biner slave itu sendiri
Menggunakan slave relay memiliki masalah tersendiri
- log_slave_updates memiliki beberapa penalti kinerja
- Lag replikasi pada server slave relay akan menghasilkan delay pada semua slave-nya
- Transaksi nakal di server relai budak akan menginfeksi semua budaknya
- Jika server relai budak gagal dan Anda tidak menggunakan GTID, semua budaknya berhenti mereplikasi dan perlu diinisialisasi ulang
3. 3. Guru dengan Guru Aktif [Replikasi Melingkar]
Juga dikenal sebagai topologi ring, pengaturan ini membutuhkan dua atau lebih server MySQL yang bertindak sebagai master. Semua master menerima penulisan dan menghasilkan binlog dengan beberapa peringatan
- Anda perlu menyetel offset peningkatan otomatis di setiap server untuk menghindari tabrakan kunci utama
- Tidak ada resolusi konflik
- Replikasi MySQL saat ini tidak mendukung protokol penguncian apa pun antara master dan slave untuk menjamin atomisitas pembaruan yang didistribusikan di dua server yang berbeda
- Praktik umum adalah hanya menulis ke satu master dan master lainnya bertindak sebagai hot-standby node. Tetap saja, jika Anda memiliki budak di bawah tingkat itu, Anda harus beralih ke master baru secara manual jika master yang ditunjuk gagal
Anda dapat menggunakan topologi ini dengan ClusterControl 1. 4 dan selanjutnya. Sebelumnya, ClusterControl akan membunyikan alarm karena dua atau lebih master sedang berjalan. Satu master akan dikonfigurasi sebagai hanya-baca sementara yang lainnya dapat ditulis. Namun, penguncian dan penyelesaian konflik perlu ditangani oleh aplikasi itu sendiri. ClusterControl tidak mendukung dua master yang dapat ditulis dalam penyiapan replikasi, salah satu dari dua master tersebut harus dalam mode read_only
3. 4. Master dengan Master Cadangan [Replikasi Berganda]
Master mendorong perubahan ke master cadangan dan ke satu atau lebih budak. Replikasi semi-sinkron digunakan antara master dan master cadangan. Master mengirimkan pembaruan ke master cadangan dan menunggu dengan komit transaksi. Master pencadangan mendapatkan pembaruan, menulis ke log relai, dan mengalir ke disk. Master cadangan kemudian mengakui penerimaan transaksi ke master, dan melanjutkan dengan transaksi komit. Replikasi semi-sinkronisasi berdampak pada kinerja, tetapi risiko kehilangan data diminimalkan
Topologi ini bekerja dengan baik saat melakukan master failover jika master turun. Master pencadangan bertindak sebagai server siaga hangat karena memiliki kemungkinan tertinggi untuk memiliki data terkini jika dibandingkan dengan budak lainnya
3. 5. Banyak Master ke Budak Tunggal [Replikasi Multi-Sumber]
Replikasi Multi-Sumber memungkinkan budak replikasi untuk menerima transaksi dari berbagai sumber secara bersamaan. Replikasi multi-sumber dapat digunakan untuk mencadangkan beberapa server ke satu server, untuk menggabungkan pecahan tabel, dan menggabungkan data dari beberapa server ke satu server
MySQL dan MariaDB memiliki implementasi replikasi multi-sumber yang berbeda, di mana MariaDB harus memiliki GTID dengan gtid-domain-id yang dikonfigurasi untuk membedakan transaksi asal sementara MySQL menggunakan saluran replikasi terpisah untuk setiap master yang direplikasi oleh slave. Di MySQL, master dalam topologi replikasi multi-sumber dapat dikonfigurasi untuk menggunakan replikasi berbasis pengidentifikasi transaksi global [GTID], atau replikasi berbasis posisi log biner
Lebih lanjut tentang replikasi multi-sumber MariaDB dapat ditemukan di postingan blog ini. Untuk MySQL, lihat dokumentasi MySQL
3. 6. Galera dengan Budak Replikasi [Replikasi Hibrida]
Replikasi hibrid adalah kombinasi replikasi asinkron MySQL dan replikasi hampir sinkron yang disediakan oleh Galera. Penyebaran sekarang disederhanakan dengan implementasi GTID dalam replikasi MySQL, di mana pengaturan dan pelaksanaan master failover telah menjadi proses langsung di sisi slave
Performa klaster Galera secepat node paling lambat. Memiliki budak replikasi asinkron dapat meminimalkan dampak pada kluster jika Anda mengirimkan kueri jenis pelaporan/OLAP yang berjalan lama ke budak, atau jika Anda melakukan pekerjaan berat yang memerlukan kunci seperti mysqldump. Budak juga dapat berfungsi sebagai cadangan langsung untuk pemulihan bencana di lokasi dan di luar lokasi
Replikasi hibrid didukung oleh ClusterControl dan Anda dapat menerapkannya langsung dari UI ClusterControl. Untuk informasi lebih lanjut tentang cara melakukannya, harap baca postingan blog – replikasi hybrid dengan MySQL 5. 6 dan replikasi hibrid dengan MariaDB 10. x
4. Menyebarkan Pengaturan Replikasi MySQL
Sekarang kita akan men-deploy topologi replikasi MySQL yang terdiri dari satu master, satu master cadangan [hanya baca], dan dua budak, menggunakan ClusterControl. Arsitektur kami diilustrasikan di bawah ini
Install ClusterControl by following the instructions on the Getting Started page. Do not forget to setup passwordless SSH from ClusterControl to all nodes [including the ClusterControl node itself]. Kami akan menggunakan pengguna root untuk penyebaran. Pada node ClusterControl, jalankan
$ ssh-keygen -t rsa
$ ssh-copy-id 10.0.0.200 # clustercontrol
$ ssh-copy-id 10.0.0.201 # master
$ ssh-copy-id 10.0.0.202 # backup-master
$ ssh-copy-id 10.0.0.203 # slave1
$ ssh-copy-id 10.0.0.204 # slave2Open the ClusterControl UI, go to the ‘Create Database Node’ and open the ‘MySQL Replication’ tab. Pada dialog tersebut terdapat 3 tab yang harus diisi seperti screenshot berikut
4. 1. Pengaturan Umum dan SSH
Di bawah "Pengaturan Umum & SSH", tentukan informasi yang diperlukan
- Pengguna SSH – Tentukan pengguna SSH yang akan digunakan ClusterControl untuk terhubung ke host target
- SSH Key Path – Passwordless SSH requires an SSH key. Tentukan jalur fisik ke file kunci di sini
- Kata Sandi Sudo – Kata sandi Sudo jika pengguna sudo menggunakan kata sandi untuk meningkatkan hak istimewa. Jika tidak, biarkan kosong
- Nomor Port SSH – Cukup jelas. Standarnya adalah 22
- Nama Cluster – Nama cluster setelah digunakan oleh ClusterControl
Pertahankan kotak centang sebagai default sehingga ClusterControl menginstal perangkat lunak dan mengonfigurasi opsi keamanan yang sesuai. If you would like to keep the firewall settings, uncheck the “Disable Firewall” however make sure MySQL related ports are opened before the deployment begins, as shown
4. 2. Tentukan Server MySQL
Pindah ke tab berikutnya, tentukan opsi instalasi dan konfigurasi Server MySQL
- Vendor – Vendor yang didukung saat ini adalah Percona Server, MariaDB dan Oracle
- Versi – versi utama MySQL. Versi 5. 7 [Oracle/Percona] atau 10. 3 [MariaDB] direkomendasikan
- Direktori Data Server – Lokasi fisik direktori data MySQL. Standarnya adalah /var/lib/mysql
- Port Server – port server MySQL. Standarnya adalah 3306
- -ku. cnf Template – Templat konfigurasi MySQL. Biarkan kosong untuk menggunakan template default yang terletak di bawah /usr/share/cmon/templates. Untuk MySQL5. 7, ClusterControl akan menggunakan my. cnf. repl57 untuk MySQL 5. 7, saya. cnf. gtid_replication untuk MySQL 5. 6 dan saya. cnf. replikasi untuk MySQL 5. 5
- Kata Sandi Root – kata sandi root MySQL. ClusterControl akan mengatur ini untuk Anda
- Repositori – Disarankan untuk memilih nilai default, kecuali jika Anda ingin menggunakan repositori yang ada di node database. Anda juga dapat memilih "Buat Repositori Baru" untuk membuat dan mencerminkan repositori vendor database saat ini, lalu menerapkan menggunakan repositori cermin lokal
Replikasi pengguna dan kata sandi akan dihasilkan secara otomatis oleh ClusterControl. Anda dapat mengambilnya nanti di dalam file konfigurasi CMON yang dihasilkan untuk kluster terkait
4. 3. Definisi Topologi
Di sini Anda dapat menentukan topologi Replikasi MySQL seperti apa yang Anda inginkan. Antarmuka memungkinkan sejumlah topologi replikasi untuk digunakan seperti multi master, master cadangan, dan replikasi rantai. Silakan lihat Topologi untuk fitur Replikasi MySQL untuk lebih jelasnya
- IP/Hostname – Tentukan alamat IP atau nama host dari host target. Dalam dialog ini, Anda dapat menentukan topologi replikasi standar master-slave atau multi-master. Untuk replikasi multi-master, Master A akan menjadi penulis sementara Master B akan dimulai sebagai hanya-baca. ClusterControl harus dapat menjangkau server yang ditentukan melalui SSH tanpa kata sandi. Jika ClusterControl tidak dapat terhubung ke host, kesalahan akan ditampilkan di sini yang mengarah ke akar penyebab
Setelah kami mengisi informasi yang diperlukan, klik 'Deploy' untuk memulai penerapan. ClusterControl akan menyebarkan cluster replikasi sesuai dengan topologi. Mulai dari ClusterControl v1. 4, penyebaran Replikasi MySQL baru akan dikonfigurasi dengan skema replikasi semi-sinkron untuk mengurangi kemungkinan kehilangan data. Detail tentang skema ini dijelaskan dalam bab ini, Apa itu Replikasi MySQL
Anda dapat memantau kemajuan penerapan dari Aktivitas [menu atas] di bawah tab Pekerjaan. Pilih "Buat Cluster" dan klik dialog "Detail Pekerjaan Penuh" ketika Anda mengklik ikon panah berputar di menu atas
ClusterControl melakukan tugas-tugas berikut
- Memverifikasi konektivitas SSH
- Instal Server MySQL yang ditentukan
- Membuat datadir dan menginstal tabel sistem
- Membuat/memberikan pengguna mysql untuk MySQL Server
- Memberikan pengguna CMON dari server ClusterControl
- Mengonfigurasi peran replikasi untuk MySQL [master/slave]
- Memverifikasi penerapan
- Mendaftarkan node dengan server ClusterControl
Cluster Replikasi MySQL sekarang digunakan
4. 4. Penskalaan
Menggunakan replikasi untuk scale-out bekerja paling baik di lingkungan di mana Anda memiliki jumlah pembacaan yang tinggi dan jumlah penulisan/pembaruan yang rendah. Aplikasi web cenderung lebih intensif baca daripada intensif tulis. Permintaan baca dapat diseimbangkan bebannya di lebih banyak budak
Untuk menskalakan dengan menambahkan lebih banyak salinan baca, buka ClusterControl > pilih cluster database > Actions > Add Node > Create dan tambahkan DB Node baru dan masukkan informasi yang relevan untuk slave
ClusterControl mendukung penambahan rantai replikasi di bawah salah satu budak yang berjalan berkat implementasi GTID. Keuntungan besar dari replikasi chaining adalah tidak akan menambah overhead ke server master. Anda dapat memutuskan apakah budak memiliki prioritas lebih rendah sehingga dapat berada di bawah budak tertentu. Dalam contoh ini, kita akan menambahkan server baru sebagai budak [10. 0. 0. 205] mereplikasi dari salah satu budak yang tersedia [10. 0. 0. 202]. Ada juga opsi untuk menyertakan node sebagai bagian dari set penyeimbangan beban atau Anda dapat mengonfigurasinya sebagai slave yang tertunda. Anda juga dapat menggunakan salah satu cadangan untuk menyediakan budak baru ini alih-alih menyalin data langsung dari masternya
Klik 'Tambah Node'. Pantau progresnya di ClusterControl > Aktivitas > Pekerjaan > pilih pekerjaan ‘Menambahkan Budak Replikasi’ > Detail Pekerjaan Lengkap dan Anda akan melihat sesuatu seperti di bawah ini
ClusterControl melakukan tugas-tugas berikut saat membuat budak baru
- Memverifikasi konektivitas SSH
- Instal versi utama Server MySQL yang sama dengan master dari repositori
- Membuat datadir dan menginstal tabel sistem
- Membuat/memberikan pengguna mysql untuk MySQL Server
- Memberikan pengguna CMON dari server ClusterControl
- Tahapan data pada budak dari master yang dipilih
- Mengonfigurasi peran replikasi untuk budak MySQL dengan GTID
- Memulai replikasi
- Memverifikasi penerapan
- Mendaftarkan node di bawah "cluster ID" yang sesuai di server ClusterControl
- Memperbarui set penyeimbang pada penyeimbang beban
Kita dapat melihat dari status bahwa replikasi antara 10. 0. 0. 202 dan slave2 dimulai dan status penyebaran dikembalikan "selesai OK". Pada titik ini, slave3 mereplikasi dari slave2 dan arsitektur kita sekarang terlihat seperti ini
Di bagian akhir, Anda akan melihat ringkasan replikasi dari halaman Ikhtisar
Anda juga dapat mengonfirmasi topologi di Tampilan Topologi
Kami sekarang telah meningkatkan pengaturan Replikasi MySQL kami
5. Menghubungkan Aplikasi ke Pengaturan Replikasi
Sekarang, kita harus sudah menyiapkan replikasi MySQL. Hal berikutnya adalah mengimpor database yang sudah ada atau membuat database baru untuk aplikasi baru. Saat mendesain atau menerapkan aplikasi Anda, perlu diingat bahwa semua operasi tulis [pernyataan/permintaan yang mengubah status database] harus dijalankan HANYA di server master. Contoh operasi tulis adalah pernyataan yang berisi berikut ini
- DDL – BUAT, ALTER, DROP, TRUNCATE, RENAME
- DML – MASUKKAN, HAPUS, PERBARUI, GANTI
- DCL – GRANT, REVOKE
Operasi baca dapat dijalankan di salah satu server dalam penyiapan replikasi. Oleh karena itu, budak harus dimulai dalam mode hanya-baca. Aplikasi tidak akan dapat memodifikasi data secara langsung pada budak, tetapi aliran replikasi masih dapat memperbarui data di server hanya-baca
Dengan kata sederhana, aplikasi Anda harus dapat mengirim tulisan ke server master dan membaca ke server budak. Jika aplikasi Anda tidak dapat melakukan ini, Anda dapat menggunakan opsi lain seperti konektor aplikasi atau penyeimbang muatan yang mendukung perutean kueri dengan pembagian baca-tulis untuk meminimalkan perubahan di sisi aplikasi
5. 1. Konektor Aplikasi
Jika aplikasi Anda berjalan di PHP, Anda dapat menggunakan driver asli MySQL [mysqlnd] untuk melakukan pemisahan baca/tulis tanpa perubahan besar di sisi aplikasi. Pengguna Java dapat menggunakan ConnectorJ untuk melakukan pemisahan baca/tulis dengan beberapa perubahan kecil di sisi pengkodean. Karena konektor itu sendiri yang melakukan perutean, latensi jaringan ekstra yang terlibat dalam solusi berbasis proxy dapat dihindari
Salah satu kelemahan utama konektor aplikasi adalah Anda harus memeliharanya di setiap server aplikasi. Misalnya, jika seorang budak dipromosikan sebagai master baru, konfigurasi baru harus diperbarui di setiap server aplikasi. Disarankan memiliki tingkat lain yang mengelola ketersediaan basis data. Di sinilah reverse proxy alias load balancer berguna
Kami telah membahas beberapa contoh tentang pemisahan baca-tulis di posting blog berikut
- Pemisahan Baca-Tulis dengan PHP mysqlnd, Replikasi MySQL, dan HAProxy
- Pemisahan Baca-Tulis dengan ConnectorJ, Replikasi MySQL, dan HAproxy
5. 2. Konektor Sadar Kain
Oracle merilis MySQL Fabric, kerangka kerja yang dapat diperluas untuk mengelola peternakan Server MySQL. Pada saat penulisan, ini mendukung dua kategori fitur utama – Ketersediaan Tinggi dan penskalaan menggunakan sharding data. Untuk Ketersediaan Tinggi, Fabric MySQL mengelola hubungan replikasi, mendeteksi kegagalan master dan secara otomatis mempromosikan salah satu budak menjadi master baru. Sedangkan untuk sharding, admin dapat menentukan bagaimana data dipartisi antar shard – mis. g. , kolom tabel mana yang akan digunakan sebagai kunci beling, dan cara memetakan kunci ke beling yang benar [HASH atau RANGE]. Ini semua transparan untuk aplikasi
Konektor MySQL digunakan oleh kode aplikasi untuk mengakses database, mengubah instruksi dari bahasa pemrograman tertentu ke protokol kabel MySQL, yang digunakan untuk berkomunikasi dengan proses Server MySQL. Konektor 'Fabric-aware' menyimpan cache informasi perutean yang telah diterimanya dari proses mysqlfabric dan kemudian menggunakan informasi tersebut untuk mengirim transaksi atau kueri ke Server MySQL yang benar. Saat ini tiga konektor MySQL Fabric-aware yang didukung adalah untuk PHP, Python, dan Java
5. 3. Reverse Proxy/Load Balancer
Dimungkinkan untuk menggunakan penyeimbang beban dalam berbagai cara. Anda dapat menerapkannya di host aplikasi, Anda dapat menerapkannya di host terpisah, Anda dapat menerapkannya di server database. Yang terakhir ini tidak direkomendasikan karena penggunaan CPU tambahan yang diperlukan oleh penyeimbang beban – bukanlah ide yang baik untuk menggabungkan layanan intensif CPU apa pun di server basis data
Apakah akan menyusun penyeimbang beban dengan aplikasi atau menggunakan host terpisah tergantung pada bagaimana Anda ingin menggunakan penyeimbang beban. Beberapa di antaranya, seperti ProxySQL atau MaxScale, mendukung caching kueri. Jika Anda ingin memanfaatkan fitur ini, mungkin lebih baik menempatkannya dengan host aplikasi. Harap diingat bahwa koneksi lokal melalui soket Unix akan selalu memiliki latensi yang lebih rendah daripada koneksi ke proxy melalui TCP. Anda akan mendapat manfaat lebih banyak dari caching jika latensi lebih rendah. Di sisi lain, memanfaatkan host yang terpisah menghilangkan potensi pertikaian sumber daya pada host aplikasi ketika server web dan proxy akan bersaing untuk CPU. Juga lebih mudah untuk mengelola sejumlah kecil node proxy berkinerja daripada puluhannya, digabungkan dengan server aplikasi
Dengan memiliki reverse proxy sebagai perantara, sisi aplikasi tidak perlu melakukan pemeriksaan kesehatan untuk konsistensi slave, kelambatan replikasi, atau ketersediaan master/slave karena tugas-tugas ini telah ditangani oleh reverse proxy. Aplikasi hanya perlu mengirim kueri ke server penyeimbang beban, dan kueri tersebut kemudian dialihkan ke backend yang benar
Dengan menambahkan reverse-proxy ke dalam gambar, arsitektur kita akan terlihat seperti ini
Pada saat penulisan, ada beberapa proxy balik yang mendukung pemisahan baca-tulis e. g MaxScale, ProxySQL dan MySQL Router. ClusterControl v1. 7. 1 mendukung penerapan MaxScale, ProxySQL, dan HAproxy untuk replikasi master-slave langsung dari UI
5. 3. 1. MariaDB MaxScale
MariaDB MaxScale adalah proxy database yang memungkinkan penerusan pernyataan database ke satu atau beberapa server database MySQL/MariaDB. MaxScale 2 terbaru. 3 dilisensikan di bawah MariaDB BSL yang bebas digunakan hingga dua server basis data
MaxScale mendukung arsitektur modular. Konsep yang mendasari modul memungkinkan untuk memperluas layanan proxy MaxScale. Versi saat ini mengimplementasikan pemisahan Baca Tulis dan Penyeimbangan Beban. MaxAdmin adalah antarmuka baris perintah yang tersedia dengan MaxScale yang memungkinkan pemeriksaan kondisi ekstensif, manajemen pengguna, status, dan kontrol operasi MaxScale. ClusterControl memberi Anda akses langsung ke perintah MaxAdmin. Anda dapat mencapainya dengan membuka tab 'Nodes' dan kemudian mengklik node MaxScale Anda
Untuk men-deploy instance MaxScale, cukup buka Kelola > Load Balancer > Instal MaxScale dan tentukan informasi yang diperlukan. Pilih instance server untuk dimasukkan ke dalam set load balancing dan Anda siap melakukannya. Setelah diterapkan, Anda cukup mengirim koneksi MySQL ke host penyeimbang muatan di port 4008 untuk pendengar pemisah baca/tulis atau port 4006 untuk pendengar round-robin
Kami telah membahasnya secara mendetail di postingan blog ini. Untuk contoh penerapan dan detail lebih lanjut, lihat postingan blog kami, Cara Menerapkan dan Mengelola MaxScale menggunakan ClusterControl
5. 3. 2. ProxySQL
ProxySQL adalah proxy MySQL performa tinggi baru dengan lisensi GPL sumber terbuka. Itu dirilis sebagai tersedia secara umum [GA] untuk penggunaan produksi menjelang akhir 2015. Ini menerima lalu lintas masuk dari klien MySQL dan meneruskannya ke backend server MySQL. Ini mendukung berbagai topologi MySQL, dengan kemampuan seperti perutean kueri [mis. g, read/write split], sharding, query rewrite, query mirroring, connection pooling dan banyak lagi
ProxySQL untuk Replikasi MySQL dirancang di sekitar konsep grup host - kumpulan node berbeda yang entah bagaimana terkait. Gagasan di baliknya adalah bahwa, dalam beberapa kondisi [hanya dua grup host, satu untuk master dan satu untuk semua budak, read_only digunakan untuk membedakan antara master dan slave] ProxySQL memungkinkan untuk mulai memantau flag read_only pada host tersebut. Melalui ini, dapat mengikuti perubahan topologi dan secara otomatis memperkenalkan perubahan dalam definisi server untuk mencerminkan topologi. ClusterControl menggunakan flag 'read_only' untuk menandai master [read_only=0] dan slave [read_only=1]. Jika Anda mempromosikan budak sebagai master baru secara manual, dan mengubah flag read_only sesuai, ProxySQL dapat mendeteksi perubahan tersebut dan memindahkan host 'master' lama ke grup host 'pembaca' sementara master baru akan dipindahkan ke grup host 'penulis'
Untuk men-deploy instance ProxySQL, cukup buka Manage > Load Balancer > Install ProxySQL dan tentukan informasi yang diperlukan. Pilih instance server yang akan disertakan ke set load balancing dan tentukan lag replikasi maksimum untuk masing-masing instance. Secara default, ClusterControl akan mengonfigurasi pembagi baca/tulis default untuk cluster Replikasi MySQL. Kueri pemilihan dasar apa pun akan dialihkan ke grup host 20 [kumpulan baca] sementara semua kueri lainnya akan dialihkan ke grup host 10 [master]
Setelah diterapkan, Anda cukup mengirim koneksi MySQL ke host penyeimbang beban di port 6033. Screenshot berikut menunjukkan hostgroup pembaca [Hostgroup 20] dengan beberapa statistik yang diambil oleh ProxySQL
Kami mendorong Anda untuk membaca lebih lanjut tentang sumber daya berikut untuk mendapatkan pemahaman yang lebih baik tentang ProxySQL
- MySQL Load Balancing dengan ProxySQL – Gambaran Umum
- Menggunakan ClusterControl untuk Menyebarkan dan Mengonfigurasi ProxySQL di atas Replikasi MySQL
- Tip dan Trik – Cara Shard MySQL dengan ProxySQL di ClusterControl
5. 3. 3. HAProxy [Replikasi Master-Budak]
HAProxy sebagai penyeimbang beban MySQL bekerja mirip dengan penerusan TCP, yang beroperasi di lapisan transport model TCP/IP. Itu tidak memahami kueri MySQL [yang beroperasi di lapisan yang lebih tinggi] yang didistribusikan ke server MySQL backend. Menyiapkan HAProxy untuk Replikasi MySQL memerlukan dua pendengar HAProxy yang berbeda e. g, port 3307 untuk menulis ke master dan port 3308 untuk membaca ke semua budak yang tersedia [termasuk master]
Aplikasi kemudian harus diinstruksikan untuk mengirim baca/tulis ke pendengar masing-masing
- Bangun/Modifikasi aplikasi Anda agar memiliki kemampuan untuk mengirim baca dan tulis ke masing-masing pendengar
- Gunakan konektor aplikasi yang mendukung pemisahan baca/tulis bawaan. Jika Anda menggunakan Java, Anda dapat menggunakan Connecter/J. Untuk PHP, Anda bisa menggunakan php-mysqlnd untuk master-slave. Ini akan meminimalkan perubahan di sisi aplikasi
Untuk membuat instance HAProxy untuk replikasi master-slave, buka Kelola > Load Balancer > Instal HAproxy dan pastikan bahwa centang “Instal untuk pemisahan baca/tulis” diaktifkan – ini harus terjadi secara default untuk penyiapan replikasi. Tangkapan layar berikut menunjukkan statistik instance HAproxy yang diterapkan oleh ClusterControl untuk Replikasi MySQL
Kami telah membahas HAproxy secara mendetail di halaman tutorial kami, Load Balancing MySQL dengan HAproxy
6. Failover dengan ClusterControl
Agar penyiapan replikasi Anda tetap stabil dan berjalan, sistem harus tahan terhadap kegagalan. Kegagalan disebabkan oleh bug perangkat lunak, masalah konfigurasi, atau masalah perangkat keras, dan dapat terjadi kapan saja. Jika server mati, ClusterControl akan membunyikan alarm tentang penyiapan yang terdegradasi dan Anda akan diberi tahu melalui email atau pager. Failover [mempromosikan budak ke master] dapat dilakukan melalui ClusterControl secara otomatis atau manual. Biasanya budak yang memiliki data terbaru. Untuk automatic failover, admin dimungkinkan untuk blacklist server yang tidak boleh dipromosikan sebagai master, atau memiliki whitelist server yang dapat dipromosikan
Bagaimana Anda memutuskan budak mana yang paling mutakhir? . GTID membuatnya lebih mudah, meskipun Anda dapat mengalami masalah seperti transaksi yang salah. Failover replikasi dibahas secara mendetail di “Menjadi DBA MySQL” – Operasi Umum – Perubahan Topologi Replikasi
6. 1. Failover Master Otomatis
Untuk memiliki penyiapan Replikasi MySQL yang tangguh sepenuhnya dengan failover master otomatis, Anda disarankan untuk menggunakan proxy terbalik di depan instans database. Ini akan menyederhanakan perutean kueri dari aplikasi ke master yang benar setelah perubahan topologi, sehingga mengurangi risiko transaksi yang salah dan meminimalkan waktu henti basis data. Silakan merujuk ke bagian Reverse proxy/Load balancer untuk detailnya
Secara default, pemulihan otomatis ClusterControl diaktifkan. Failover akan dilakukan oleh ClusterControl ketika terjadi kegagalan pada master. Itu dilakukan dalam hitungan detik berdasarkan aliran berikut
- Jika ClusterControl tidak dapat tersambung ke server master, ClusterControl akan menandai kegagalan master sebagai offline
- Alarm akan dibunyikan untuk menunjukkan kegagalan replikasi dan semua node yang tersedia dalam mode read-only
- ClusterControl akan memilih kandidat master berdasarkan replication_failover_whitelist, replication_failover_blacklist, atau slave terbaru
- ClusterControl akan memeriksa transaksi yang salah pada kandidat master. Jika ada transaksi yang salah, proses failover akan dihentikan dan alarm akan dibunyikan untuk menunjukkan kegagalan dalam prosedur failover
- ClusterControl kemudian akan melakukan master failover dengan menghentikan semua budak dan melakukan pernyataan CHANGE MASTER ke master baru
- Jika failover berhasil [semua budak dimulai], ClusterControl menandai master baru sebagai dapat ditulisi [set read_only = 0] dan alarm dihapus
- Reverse proxy kemudian akan memperbarui set penyeimbangan muatan yang sesuai
Kecuali dinonaktifkan secara eksplisit [replication_check_external_bf_failover=0] ClusterControl akan mencoba menyambungkan ke budak dan instance ProxySQL [jika tersedia dalam pengaturan] untuk memverifikasi apakah node tersebut dapat mengakses master yang gagal. Jika beberapa node dapat melakukannya, failover tidak akan terjadi. Kemungkinan besar, ada partisi jaringan dan entah bagaimana ClusterControl tidak dapat terhubung langsung ke master. Tetapi karena master dapat dilihat oleh slave dan/atau load balancer, maka master tetap berjalan
6. 1. 1. Daftar Putih dan Daftar Hitam
Untuk mengantisipasi budak berikutnya dipromosikan sebagai master baru selama failover, ada dua variabel yang dapat Anda atur dalam file konfigurasi CMON untuk cluster ini
- replication_failover_whitelist – Daftar IP atau nama host budak [dipisahkan koma] yang harus digunakan sebagai kandidat master potensial. Jika variabel ini disetel, hanya host tersebut yang akan dipertimbangkan
- replication_failover_blacklist – Daftar host [dipisahkan koma] yang tidak akan pernah dianggap sebagai kandidat master. Anda dapat menggunakannya untuk membuat daftar budak yang digunakan untuk pencadangan atau kueri analitik. Jika perangkat keras bervariasi di antara budak, Anda mungkin ingin meletakkan di sini budak yang menggunakan perangkat keras lebih lambat
Dalam kasus kami, kami ingin memiliki backup-master [10. 0. 0. 202] sebagai master berikutnya setiap kali failover terjadi. Jadi, di dalam file konfigurasi CMON [dengan asumsi cluster_id = 1], /etc/cmon. d/cmon_1. cnf, kami menambahkan baris berikut
replication_failover_whitelist=10.0.0.201,10.0.0.202Perhatikan bahwa failover dilakukan HANYA sekali. Jika upaya failover gagal, maka tidak ada lagi upaya yang akan dilakukan hingga pengontrol dimulai ulang. Anda dapat memaksa ClusterControl untuk mencoba lagi dengan pendekatan yang lebih agresif dengan menentukan replication_stop_on_error=0 di dalam file konfigurasi CMON [namun, ada kemungkinan replikasi budak telah rusak]. Atau lakukan failover master manual seperti yang dijelaskan di bagian selanjutnya
6. 2. Kegagalan Manual Master
Penulisan dilakukan di server master saja. Jika master gagal, replikasi akan berhenti. Failover harus dilakukan dengan mempromosikan salah satu budak terbaru ke master untuk memulihkan penyiapan replikasi kami. Aplikasi yang melakukan pembaruan kemudian harus menyambung kembali ke master yang baru dipromosikan dan kemudian terus beroperasi
Jika master sedang down, kita perlu mempromosikan salah satu budak [backup-master] untuk menjadi master. Untuk melakukannya, buka ClusterControl > Nodes > pilih backup-master node > Promote Slave
Anda akan diminta dengan yang berikut ini
Secara efektif, budak yang dipilih telah menjadi master baru dan akan memproses pembaruan saat master lama mati
Ketika master lama muncul lagi, itu akan dimulai sebagai read-only dan kemudian disinkronkan ulang dengan master baru [backup-master] sebagai budak. Tindakan ini diatur secara otomatis oleh ClusterControl. Tangkapan layar berikut menunjukkan master lama [10. 0. 0. 201] telah menjadi budak bagi master cadangan [10. 0. 0. 202] dalam replikasi
Tuan tua [10. 0. 0. 201] mungkin perlu melakukan beberapa pengejaran setelah layanan budak dimulai dan setelah diperbarui dengan master baru [10. 0. 0. 202], itu akan tetap sebagai budak
6. 3. Kegagalan Seorang Budak
Jika sebuah slave gagal, aplikasi yang terhubung ke slave dapat terhubung ke slave lain dan terus beroperasi. ClusterControl akan menampilkan status saat ini dari slave yang gagal di halaman Overview
Saat budak muncul lagi, ClusterControl akan secara otomatis melanjutkan replikasi dengan master dan membuat budak tersedia untuk aplikasi. Bergantung pada berapa lama budak tertinggal, atau apakah ClusterControl tidak dapat melanjutkan replikasi karena kesalahan replikasi, Anda dapat menyinkronkan ulang transaksi yang hilang secara manual. Atau Anda dapat menggunakan fitur 'Rebuild Replication Slave' untuk membangun kembali budak tersebut. Dalam hal ini, ClusterControl akan menghapus data lama pada budak, membuang data master dari master yang dipilih dan menyediakan budak dengannya, sebelum akhirnya menghubungkannya kembali dengan master
Pada titik ini, setup replikasi telah dikembalikan ke topologi aslinya
6. 4. Skrip Pra dan Pasca-Kegagalan
ClusterControl menyediakan beberapa pengait yang dapat digunakan untuk menyambungkan skrip eksternal. Di bawah ini Anda akan menemukan daftarnya dengan beberapa penjelasan
- Replication_onfail_failover_script – skrip ini dijalankan segera setelah ditemukan bahwa failover diperlukan. Jika skrip mengembalikan bukan nol, itu akan memaksa kegagalan untuk dibatalkan. Jika skrip ditentukan tetapi tidak ditemukan, failover akan dibatalkan. Empat argumen diberikan ke skrip. arg1='semua server' arg2='oldmaster' arg3='calon', arg4='slaves of oldmaster' dan lulus seperti ini. 'nama skrip arg1 arg2 arg3 arg4'. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_pre_failover_script – skrip ini dieksekusi sebelum failover terjadi, tetapi setelah kandidat terpilih dan dimungkinkan untuk melanjutkan proses failover. Jika skrip mengembalikan bukan nol, itu akan memaksa kegagalan untuk dibatalkan. Jika skrip ditentukan tetapi tidak ditemukan, failover akan dibatalkan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_post_failover_script – skrip ini dijalankan setelah failover terjadi. Jika skrip mengembalikan nol, Peringatan akan ditulis di log pekerjaan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_post_unsuccessful_failover_script – Skrip ini dijalankan setelah upaya failover gagal. Jika skrip mengembalikan nol, Peringatan akan ditulis di log pekerjaan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_failed_reslave_failover_script – skrip ini dijalankan setelah master baru dipromosikan dan jika reslaving budak ke master baru gagal. Jika skrip mengembalikan nol, Peringatan akan ditulis di log pekerjaan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_pre_switchover_script – skrip ini dijalankan sebelum peralihan terjadi. Jika skrip mengembalikan bukan nol, itu akan memaksa pengalihan gagal. Jika skrip ditentukan tetapi tidak ditemukan, peralihan akan dibatalkan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
- Replication_post_switchover_script – skrip ini dijalankan setelah peralihan terjadi. Jika skrip mengembalikan nol, Peringatan akan ditulis di log pekerjaan. Skrip harus dapat diakses di pengontrol dan dapat dieksekusi
Seperti yang Anda lihat, hook mencakup sebagian besar kasus di mana Anda mungkin ingin melakukan beberapa tindakan – sebelum dan sesudah pergantian, sebelum dan sesudah failover, ketika reslave gagal atau ketika failover gagal. Semua skrip dipanggil dengan empat argumen [yang mungkin atau mungkin tidak ditangani dalam skrip, skrip tidak diharuskan menggunakan semuanya]. semua server, nama host [atau IP – seperti yang didefinisikan dalam ClusterControl] dari master lama, nama host [atau IP – seperti yang didefinisikan dalam ClusterControl] dari kandidat master dan yang keempat, semua replika dari master lama. Pilihan tersebut harus memungkinkan untuk menangani sebagian besar kasus
Semua hook tersebut harus didefinisikan dalam file konfigurasi untuk cluster tertentu [/etc/cmon. d/cmon_X. cnf di mana X adalah id cluster]. Contohnya mungkin terlihat seperti ini
replication_pre_failover_script=/usr/bin/stonith.py
replication_post_failover_script=/usr/bin/vipmove.shTentu saja, skrip yang dipanggil harus dapat dieksekusi, jika tidak, cmon tidak akan dapat mengeksekusinya
6. 4. 1. Kapan Hook Bisa Berguna?
Mari kita lihat beberapa contoh kasus yang mungkin merupakan ide bagus untuk mengimplementasikan skrip eksternal. Kami tidak akan membahas detail apa pun karena terlalu dekat hubungannya dengan lingkungan tertentu. Ini akan lebih merupakan daftar saran yang mungkin berguna untuk diterapkan. STONITH script
Shoot The Other Node In The Head [STONITH] is a process of making sure that the old master, which is dead, will stay dead [and yes. we don’t like zombies roaming about in our infrastructure]. The last thing you probably want is to have an unresponsive old master which then gets back online and, as a result, you end up with two writable masters. Ada tindakan pencegahan yang dapat Anda ambil untuk memastikan master lama tidak akan digunakan meskipun muncul lagi, dan lebih aman untuk tetap offline. Cara bagaimana memastikannya akan berbeda dari lingkungan ke lingkungan. Therefore, most likely, there will be no built-in support for STONITH in the failover tool. Depending on the environment, you may want to execute CLI command which will stop [and even remove] a VM on which the old master is running. If you have an on-prem setup, you may have more control over the hardware. It might be possible to utilize some sort of remote management [integrated Lights-out or some other remote access to the server]. You may have also access to manageable power sockets and turn off the power in one of them to make sure server will never start again without human intervention
6. 4. 1. 1. Service DiscoveryWe already mentioned a bit about service discovery. There are numerous ways one can store information about a replication topology and detect which host is a master. Definitely, one of the more popular options is to use etc. d or Consul to store data about current topology. With it, an application or proxy can rely in this data to send the traffic to the correct node. ClusterControl [just like most of the tools which do support failover handling] does not have a direct integration with either etc. d atau Konsul. The task to update the topology data is on the user. She can use hooks like replication_post_failover_script or replication_post_switchover_script to invoke some of the scripts and do the required changes. Another pretty common solution is to use DNS to direct traffic to correct instances. If you will keep the Time-To-Live of a DNS record low, you should be able to define a domain, which will point to your master [i. e. menulis. gugus1. contoh. com]. Ini memerlukan perubahan pada catatan DNS dan, sekali lagi, pengait seperti replication_post_failover_script atau replication_post_switchover_script dapat sangat membantu untuk melakukan modifikasi yang diperlukan setelah kegagalan terjadi
6. 4. 1. 2. Konfigurasi Ulang ProksiSetiap server proxy yang digunakan harus mengirimkan lalu lintas ke instance yang benar. Bergantung pada proxy itu sendiri, bagaimana deteksi master dilakukan dapat berupa [sebagian] hardcode atau terserah pengguna untuk menentukan apa pun yang dia suka. Mekanisme failover ClusterControl dirancang dengan cara yang terintegrasi dengan baik dengan proxy yang digunakan dan dikonfigurasi. Masih mungkin terjadi bahwa ada proksi di tempat, yang tidak dipasang oleh ClusterControl dan mereka memerlukan beberapa tindakan manual untuk dilakukan saat failover dijalankan. Proksi semacam itu juga dapat diintegrasikan dengan proses failover ClusterControl melalui skrip eksternal dan pengait seperti replication_post_failover_script atau replication_post_switchover_script
6. 4. 1. 3. Pencatatan TambahanMungkin saja Anda ingin mengumpulkan data dari proses failover untuk keperluan debugging. ClusterControl memiliki cetakan ekstensif untuk memastikan bahwa proses dapat diikuti dan mencari tahu apa yang terjadi dan mengapa. Mungkin saja Anda ingin mengumpulkan beberapa informasi khusus tambahan. Pada dasarnya semua pengait dapat digunakan di sini – Anda dapat mengumpulkan status awal, sebelum failover, Anda dapat melacak status lingkungan di semua tahap failover
7. Operasi – Mengelola Pengaturan Replikasi MySQL Anda
Cara Anda memilih untuk menerapkan penyiapan replikasi juga memengaruhi cara Anda mengelolanya. Di bagian ini, kita akan mengasumsikan satu master dengan banyak budak, seperti yang diterapkan di bagian 4 tutorial ini. Kami akan melihat bagaimana kami dapat mengelola berbagai tugas operasional menggunakan ClusterControl
7. 1. Tampilkan Status Replikasi
Anda dapat menemukan ringkasan status Replikasi MySQL langsung dari bilah ringkasan di daftar cluster database. Status klaster Replikasi dapat AKTIF, GAGAL atau TERTURUN
Anda dapat menemukan detail lebih lanjut tentang status master, status slave, dan statistik host langsung dari halaman Ikhtisar Cluster
7. 2. Mulai/Hentikan Replikasi
ClusterControl mendukung memulai atau menghentikan budak dari UI-nya. Ini mirip dengan melakukan 'STOP SLAVE' dan 'START SLAVE' melalui baris perintah
Jika utas SQL atau IO dihentikan, ClusterControl akan mencantumkan opsi tambahan untuk memulai/menghentikan utas
7. 3. Promosikan Budak
Mempromosikan budak menjadi master mungkin diperlukan jika e. g. server master turun, atau jika Anda ingin melakukan pemeliharaan pada host master. Dengan asumsi Anda telah mengonfigurasi replikasi berbasis GTID, Anda dapat mempromosikan budak menjadi master dengan mudah menggunakan ClusterControl. Jika master saat ini berfungsi dengan benar, pastikan Anda menghentikan kueri aplikasi sebelum mempromosikan budak lain. Hal ini untuk menghindari kehilangan data. Koneksi pada master yang sedang berjalan akan dimatikan oleh ClusterControl setelah masa tenggang 10 detik
7. 4. Membangun kembali Budak Replikasi
Jika budak rusak, atau tidak sinkron dengan master karena alasan tertentu, Anda mungkin ingin membangunnya kembali. Dengan ClusterControl, Anda dapat membangun kembali budak replikasi menggunakan data dari master. Itu menggunakan Percona Xtrabackup untuk mengatur data replikasi pada budak. Perhatikan bahwa fitur ini akan menghapus datadir MySQL dari slave
Sebelum melanjutkan proses pembangunan kembali dari ClusterControl, Anda harus memilih master yang tersedia. Proses slave akan dimulai secara otomatis setelah pembangunan kembali selesai
Proses staging akan dilakukan oleh Percona Xtrabackup karena kemampuan hot-backup pada mesin penyimpanan InnoDB. Jika Anda memiliki tabel MyISAM, FLUSH TABLES akan terjadi di akhir proses pencadangan dan selama waktu ini, master yang dipilih akan hanya-baca sebentar
7. 5. Cadangan
Kami telah membuat blog sebelumnya tentang strategi pencadangan untuk MySQL. ClusterControl mendukung mysqldump dan xtrabackup [penuh dan inkremental] untuk melakukan pencadangan. Pencadangan dapat dilakukan atau dijadwalkan pada node database mana pun [master atau slave] dan disimpan secara lokal atau disimpan secara terpusat pada node ClusterControl. Saat menyimpan cadangan di node ClusterControl, cadangan pertama kali dibuat di node database target dan kemudian dialirkan menggunakan netcat ke node pengontrol. Anda juga dapat memilih untuk mencadangkan basis data individual atau semua basis data. Kemajuan pencadangan tersedia di bawahnya dan Anda akan mendapatkan pemberitahuan tentang status pencadangan setiap kali dibuat
Untuk membuat cadangan, cukup buka Pencadangan > Buat Cadangan dan tentukan detail yang diperlukan
Untuk menjadwalkan pencadangan, klik "Jadwalkan Pencadangan" dan konfigurasikan penjadwalan yang sesuai
Cadangan yang dibuat oleh ClusterControl dapat dipulihkan di salah satu node database
7. 6. Memulihkan
ClusterControl memiliki kemampuan untuk memulihkan cadangan [mysqldump dan xtrabackup] yang dibuat oleh ClusterControl atau secara eksternal melalui beberapa alat lain. Untuk pencadangan eksternal, file cadangan harus ada di node ClusterControl dan hanya xbstream, xbstream. gz dan tar. ekstensi gz didukung
Semua cadangan inkremental secara otomatis dikelompokkan bersama di bawah cadangan penuh terakhir dan dapat diperluas dengan drop-down. Setiap cadangan yang dibuat akan memiliki tombol "Pulihkan" dan "Log".
Untuk memulihkan cadangan, cukup klik tombol "Pulihkan" untuk cadangan tersebut. Anda kemudian akan melihat wizard Pemulihan berikut dan beberapa opsi pasca-pemulihan
Jika pencadangan dilakukan menggunakan Percona Xtrabackup, replikasi harus dihentikan. Langkah-langkah berikut akan dilakukan
- Hentikan semua node dalam penyiapan replikasi
- Salin file cadangan ke server yang dipilih
- Pulihkan cadangan
- Setelah tugas pemulihan selesai, mulai node yang dipulihkan di ClusterControl > Nodes > pilih node yang dipulihkan > Mulai Node
- Setelah dimulai, promosikan node sebagai master baru [jika bukan master] di ClusterControl > Nodes > pilih node yang dipulihkan > Promosikan Slave
- Pada setiap budak, buat ulang budak replikasi dengan membuka ClusterControl > Nodes > node budak > Budak Replikasi Tahap
ClusterControl juga dapat digunakan untuk melakukan Point in Time Recovery – Anda dapat memutuskan tentang suatu titik waktu [dengan perincian satu detik] atau Anda dapat menentukan file log biner yang tepat dan posisi hingga cadangan mana yang harus dipulihkan
Bagian penting dari cadangan adalah pemulihan. Masalah utamanya adalah Anda tidak dapat mengetahui apakah pencadangan akan berfungsi kecuali Anda benar-benar berusaha memulihkannya. Setiap cadangan adalah cadangan Schrödinger – mungkin berfungsi atau tidak dan Anda tidak dapat mengetahui statusnya kecuali upaya pemulihan dilakukan. Itu sebabnya pengujian cadangan harus dimiliki. ClusterControl memberi Anda cara mudah untuk melakukannya. Saat menjadwalkan pencadangan, Anda dapat memutuskan apakah akan menjalankan uji pemulihan atau tidak
Ketika Anda memutuskan untuk melakukannya, Anda akan diberikan serangkaian opsi lain
Yang harus Anda tentukan adalah nama host atau IP host tempat Anda ingin ClusterControl mencoba memulihkannya. Anda dapat meminta ClusterControl untuk mengatur node dan menginstal MySQL. Anda juga dapat mematikan server setelah setiap tes pemulihan atau mempertahankannya dan menggunakannya kembali di masa mendatang. Pencadangan dapat dipulihkan segera setelah pencadangan selesai atau dijadwalkan untuk dimulai setelah penundaan tertentu
Kasus serupa terjadi ketika Anda mencoba memulihkan salah satu cadangan
You can either restore it on the cluster or you can run the backup restore on a standalone host. Here, in addition to the backup testing and verification, one of use cases is to reduce data loss when restoring partially deleted data. Let’s assume you have a large data set and you do not take a logical backups with mysqldump due to the time required to create such backup. Let’s assume that a small table or a subset of rows have been deleted or mistakenly updated. If you will restore the whole dataset, you will lose all modifications that happened afterwards. What you can do instead is to use this option to restore a backup set on a separate node, keep it up and running and then extract [using SELECT INTO OUTFILE or by any other means] only the data you want and then load it on the master server
7. 7. Software Upgrade
You can perform a database software upgrade via ClusterControl > Manage > Upgrades > Upgrade. Upgrades are online and are performed on one node at a time. One node will be stopped, then the software is updated through package manager and finally the node is started again. If a node fails to upgrade, the upgrade process is aborted. Upgrades should only be performed when there is as little traffic as possible on the database hosts
You can monitor the MySQL upgrade progress from ClusterControl > Activity > Jobs, as shown in the following screenshot
ClusterControl performs upgrade of MySQL Replication setup by upgrading all slaves, one at a time. Once all slaves have been upgraded, verify the new version is correct from the Cluster Overview page. Then, promote an upgraded slave [using ‘Promote Slave’] to become the new master. Finally, upgrade the old master by repeating the same upgrade step
7. 8. Configuration Changes
System variables are found in my. cnf. Some of the variables are dynamic and can be set at runtime, others not. ClusterControl provides an interface to update MySQL configuration parameters on all DB instances at once. Select DB instance[s], configuration group and parameter and ClusterControl will perform the necessary changes via SET GLOBAL [if possible] and also make it persistent in my. cnf
If a restart is required, ClusterControl will acknowledge that in the Config Change Log dialog
More information in this blog post, Updating your MySQL Configuration
7. 9. Schema Changes
Traditionally, a schema change in MySQL was a blocking operation – a table had to be locked for the duration of the ALTER. In MySQL replication, some ALTERs may lock writes on the master and create replication lag. The reason is MySQL replication is single-threaded and if the SQL thread is executing an ALTER statement, it won’t execute anything else. It is also important to understand that the slave is able to start replicating the schema change only after it has completed on the master. This results in a significant amount of time needed to complete changes on the slave. time needed for a change on the master plus time needed for a change on the slave
Luckily, there are ways to perform this operation online
- Rolling schema update – take one of the slaves out of rotation, execute ALTERs, bring it back, rinse and repeat until all slaves have been updated. Once that’s done, promote one of the slaves to master, run ALTER on the old master, bring it back as a slave
- Online schema changes tools
- pt-online-schema-change by Percona
- Online Schema Change by Facebook
- gh-ost by GitHub
Each method has its own pros and cons. More details in this blog post, Become a MySQL DBA blog series – Common operations – Schema Changes
7. 10. Topology Changes
Replication topology changes and failover processes are common operations, albeit complex. Changes are usually needed to help scale out, to distribute your database across multiple regions or data centers, or to perform software/hardware maintenance operations. The initial setup of a replication topology is simple, but as soon as you start changing it, things can quickly get complex
Bergantung pada apakah Anda menjalankan replikasi berbasis GTID atau standar dengan binlog, langkah-langkah failover berbeda dan memerlukan perhatian khusus. We have discussed this in detail in this webinar on Replication Topology Changes for MySQL and MariaDB as well as this blog post – DBA Operations – Replication Topology Changes
8. Issues and Troubleshooting
Because it is simple to setup, MySQL Replication is probably the most widely used mechanism to provide high availability. Sayangnya, itu juga agak rapuh
- Failover is not automatic and has to be performed by somebody who is skilled
- Slaves can easily end up with different data to the master, due to hardware problems, software bugs or the use of non-deterministic functions. Diverging datasets on master and slave servers causes replication to stop
- A crashing master can cause corruption of the binary log. When it is restarted, the slave servers would not be able to continue from the last binary log position
- GTID-based failover is exposed to errant transaction. We describe this further down in this tutorial, as well as in this blog
- Slave lag can be a nightmare when your application reads out-of-date data from a slave
- It is possible to set up two-way replication between two mysql servers. However, ring topologies are not recommended. Replikasi MySQL saat ini tidak mendukung protokol penguncian apa pun antara master dan slave untuk menjamin atomisitas pembaruan terdistribusi di dua server yang berbeda
8. 1. Status Replikasi
Status replikasi hanya dapat diperiksa dari budak replikasi dengan menggunakan pernyataan berikut
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.55.111
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 911532980
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 911533144
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 911532980
Relay_Log_Space: 911533311
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: a2bac331-a899-11e5-98f0-000c29901dfb
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: a2bac331-a899-11e5-98f0-000c29901dfb:10-1937
Executed_Gtid_Set: a2bac331-a899-11e5-98f0-000c29901dfb:1-1937Variabel status berikut adalah indikator utama bahwa replikasi berfungsi seperti yang diharapkan
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Master_Server_Id: 1Di atas menunjukkan IO dan utas SQL budak sedang berjalan, mereplikasi dari server Master [server-id = 1] tanpa jeda replikasi [di mana Seconds_Behind_Master adalah 0]. Selain status budak yang disebutkan di atas, Anda juga dapat menggunakan pernyataan berikut
- PILIH @@global. gtid_executed – Menampilkan transaksi yang diterapkan
- PILIH @@gtid_purged – Acara yang diterapkan tetapi sudah dihapus dari log biner
8. 2. Keterlambatan Replikasi
Lag replikasi adalah jumlah detik budak berada di belakang master. Jika itu terjadi, aplikasi Anda mungkin membaca data lama dari slave. Ini agak menimbulkan kekurangan di sisi aplikasi saat mengambil data dari budak yang tertinggal. Misalnya, Anda dapat mengonfigurasi aplikasi untuk mengambil data saat Seconds_Behing_Master hanya sama dengan 0 pada budak itu. Jika tidak, aplikasi kembali ke master untuk mengambil data. ProxySQL juga dapat dikonfigurasi untuk melacak lag budak
Anda dapat memutuskan bahwa server tertentu tidak akan mendapatkan lalu lintas saat jeda replikasi melebihi "Lag Replikasi Maks" yang ditentukan untuknya. Setelah kelambatan kembali di bawah ambang batas, ProxySQL akan mulai mengirimkan lalu lintas ke backend itu lagi
Replikasi MySQL bekerja dengan dua utas, IO_THREAD & SQL_THREAD. Untuk IO_THREAD, budak
- terhubung ke master,
- membaca peristiwa log biner dari master saat mereka masuk,
- menyalinnya ke file log lokal yang disebut log relai
Sementara SQL_THREAD, budak
- membaca peristiwa dari log relai, disimpan secara lokal di budak replikasi [file yang ditulis oleh utas IO]
- menerapkannya secepat mungkin
Setiap kali kelambatan replikasi terjadi, penting untuk menentukan apakah penundaan pada budak IO_THREAD atau budak SQL_THREAD. Biasanya, utas I/O tidak akan menyebabkan penundaan replikasi yang besar karena hanya membaca log biner dari master. Namun, itu tergantung pada konektivitas jaringan dan latensi antar server. Thread I/O budak bisa lambat karena penggunaan bandwidth yang tinggi. Biasanya, ketika slave IO_THREAD mampu membaca log biner dengan cukup cepat, ia akan menyalin dan menumpuk log relai pada slave – yang merupakan salah satu indikasi bahwa slave IO_THREAD bukanlah penyebab kelambatan slave.
Ketika SQL_THREAD budak adalah sumber penundaan replikasi, mungkin karena kueri yang berasal dari aliran replikasi membutuhkan waktu terlalu lama untuk dijalankan pada budak. Ini kadang-kadang karena perangkat keras yang berbeda antara master/slave, indeks skema atau beban kerja yang berbeda. Selain itu, beban kerja OLTP budak terkadang menyebabkan penundaan replikasi karena penguncian. Perhatikan bahwa replikasi adalah utas tunggal sebelum MySQL 5. 6, yang akan menjadi alasan lain untuk keterlambatan SQL_THREAD budak
8. 3. Melayang Data
Meskipun tujuan utama replikasi adalah untuk mendapatkan salinan data yang tepat di seluruh pengaturan replikasi, penyimpangan data masih dapat terjadi antara master MySQL dan replikanya. Hal ini dapat terjadi jika terdapat rollback transaksi pada mesin penyimpanan non-transaksional, pernyataan non-deterministik dengan replikasi berbasis pernyataan, bug perangkat lunak, atau kesalahan manusia/aplikasi. Konsistensi slave juga perlu diperiksa setelah peristiwa kegagalan master, karena pergeseran data mungkin terjadi setelah master baru dipromosikan
Anda dapat menggunakan pt-table-checksum Percona Toolkit untuk melakukan pemeriksaan konsistensi replikasi online dengan menjalankan kueri checksum pada master, yang menghasilkan hasil berbeda pada replika yang tidak konsisten dengan master. Kemudian, Anda dapat menerapkan transaksi yang hilang secara manual atau menggunakan pt-table-sync untuk menyinkronkan ulang budak
Menggunakan replikasi berbasis baris [dengan menyetel binlog_format=ROW] juga merupakan taruhan yang aman untuk mengurangi risiko penyimpangan data. Dengan replikasi berbasis baris, master menulis peristiwa ke log biner yang menunjukkan bagaimana setiap baris tabel diubah. Replikasi master ke slave bekerja dengan menyalin peristiwa yang mewakili perubahan baris ke slave
8. 4. Transaksi Salah
Transaksi yang salah adalah transaksi yang dijalankan langsung pada budak dalam replikasi berbasis GTID. Jadi, mereka hanya ada pada budak tertentu. Ini bisa menjadi hasil dari kesalahan e. g, aplikasi menulis ke budak bukan menulis ke master atau ini bisa dengan desain e. g, Anda memerlukan tabel tambahan untuk laporan. Itu dapat menyebabkan kerusakan data atau kesalahan replikasi jika seorang budak dengan transaksi yang salah dipromosikan ke master baru. Masalah utama dengan transaksi yang salah adalah bahwa ketika gagal, budak dapat melakukan transaksi 'datang entah dari mana' yang dapat secara diam-diam merusak data Anda atau merusak replikasi
Jika Anda menemukan transaksi yang salah di satu server, ada dua cara untuk mengatasi transaksi yang salah
- Entah melakukan transaksi kosong dengan GTID yang salah di semua server lain;
- Atau, hapus GTID yang sesuai pada budak yang melanggar
Intinya adalah, sebelum budak baru dipromosikan menjadi master, perlu untuk memeriksa transaksi yang salah. Kami telah membahas topik ini secara mendetail dalam postingan blog ini, Replikasi MySQL dan failover berbasis GTID – Pendalaman Mendalam tentang Transaksi yang Salah
8. 5. Budak Rusak
Budak yang rusak terjadi ketika log relai rusak. Log relai adalah file log peristiwa log biner yang berasal dari master melalui replikasi utas IO. Jika terjadi korupsi, replikasi akan berhenti pada budak. Ada beberapa alasan yang dapat menyebabkan masalah ini, bisa jadi jaringan [terutama jika mereplikasi melalui jaringan jarak jauh yang tidak dapat diandalkan], bug MySQL pada master atau slave, masalah perangkat keras, dan beberapa lainnya
Pertama, verifikasi apakah korupsi terjadi pada master atau slave. Indikator yang baik adalah jika budak lain mereplikasi tanpa kesalahan, kemungkinan besar hanya log relai pada budak tertentu yang rusak. Untuk memperbaikinya, cukup arahkan ulang replikasi pada budak ke Relay_Master_Log_FIle. Exec_Master_Log_Pos