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
- Introduction
- What is MySQL replication
- Topology for MySQL replication
- Deploying a MySQL replication setup
- Connecting applications to the replication setup
- Failover with ClusterControl
- Managing your Mysql replication setup
- Issues and troubleshooting
Download the whitepaper
1. Introduction
MySQL Replication is probably the most popular high availability solution for MySQL, and widely used by top web properties like Twitter and Facebook. Although easy to set up, ongoing maintenance like software upgrades, schema changes, topology changes, failover and recovery have always been tricky. At least until MySQL 5. 6
Fortunately, MySQL 5. 6 brought a number of significant enhancements to Replication, including Global Transaction IDs, event checksums, multi-threaded slaves and crash-safe slaves/masters. Replication got even better with MySQL 5. 7 and MySQL 8. 0
Related resources
- MySQL Replication Blueprint whitepaper
This tutorial covers basic information about MySQL Replication, with information about the features introduced in 5. 6, 5. 7 and 8. 0. At the end, you should be able to answer questions like
- How do I use GTID with replication?
- How do I recover my setup if my master fails?
- How do I upgrade the master and slave servers without 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
- Asynchronous replication
- Replikasi semi-sinkron
There is no restriction in mixing replication schemes in the same topology. Both have their pros and cons. At the time of writing, there is no fully-synchronous solution for MySQL replication
2. 1. 1. Asynchronous Replication
MySQL Replication by default is asynchronous. This is the oldest, most popular and widely deployed replication scheme. With asynchronous replication, the master writes events to its binary log and slaves request them when they are ready. There is no guarantee that any event will ever reach any slave. It’s a loosely coupled master-slave relationship, where
- Master does not wait for Slave
- Slave determines how much to read and from which point in the binary log
- Slave can be arbitrarily behind master in reading or applying changes
If the master crashes, transactions that it has committed might not have been transmitted to any slave. Consequently, failover from master to slave in this case may result in failover to a server that is missing transactions relative to the master
Asynchronous replication provides lower write latency, since a write is acknowledged locally by a master before being written to slaves. It is great for read scaling as adding more replicas does not impact replication latency. Good use cases for asynchronous replication include deployment of read replicas for read scaling, live backup copy for disaster recovery and analytics/reporting
2. 1. 2. Semi-Synchronous Replication
MySQL also supports semi-synchronous replication, where the master does not confirm transactions to the client until at least one slave has copied the change to its relay log, and flushed it to disk. To enable semi-synchronous replication, extra steps for plugin installation are required, and must be enabled on the designated MySQL master and slave
Semi-synchronous seems to be good and practical solution for many cases where high availability and no data-loss is important. But you should consider that semi-synchronous has a performance impact due to the additional round trip and does not provide strong guarantees against data loss. When a commit returns successfully, it is known that the data exists in at least two places (on the master and at least one slave). If the master commits but a crash occurs while the master is waiting for acknowledgment from a slave, it is possible that the transaction may not have reached any slave. This is not that big of an issue as the commit will not be returned to the application in this case. It is the application’s task to retry the transaction in the future. What is important to keep in mind is that, when the master failed and a slave has been promoted, the old master cannot join the replication chain. Under some circumstances this may lead to conflicts with data on the slaves (when master crashed after the slave received the binary log event but before master got the acknowledgement from the slave). Thus the only safe way is to discard the data on the old master and provision it from scratch using the data from the newly promoted master
A good use case for semi-synchronous replication is a backup master to reduce the impact of a master failure by minimizing the risk of data loss. We’ll explain this in detail under ‘Chapter 3 – Topology for MySQL Replication’
2. 2. Global Transaction Identifier (GTID)
Global Transaction Identifiers (GTID) was introduced in MySQL 5. 6. GTID is a unique identifier created and associated with each transaction committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. There is a one-to-one mapping between all transactions and all GTIDs. Note that MySQL and MariaDB have different GTID implementation, as we’ll explain further down
2. 2. 1. Replikasi di MySQL 5. 5 dan Sebelumnya
In MySQL 5. 5, resuming a broken replication setup required you to determine the last binary log file and position, which are distinct on nodes if binary logging is enabled. If the MySQL master fails, replication breaks and the slave will need to switch to another master. You will need to promote the most updated slave node to be a master, and manually determine a new binary log file and position of the last transaction executed by the slave. Another option is to dump the data from the new master node, restore it on slave and start replication with the new master node. These options are of course doable, but not very practical in production
2. 2. 2. How GTID Solves the Problem
GTID (Global Transaction Identifier) provides a better transactions mapping across nodes. In MySQL 5. 5. or before, Replication works in such a way that all nodes will generate different binlog files. Binlog events are the same and in the same order, but binlog file offsets may vary. With GTID, slaves can see a unique transaction coming in from several masters and this can easily be mapped into the slave execution list if it needs to restart or resume replication
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. Forget about binary logs, it’s now all in the 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 has a different implementation of Global Transaction ID (GTID), and is enabled by default starting from MariaDB 10. 0. 2. A MariaDB GTID consists of three separated values
- Domain ID – Replication domain. A replication domain is a server or group of servers that generate a single, strictly ordered replication stream
- Server ID – Server identifier number to enable master and slave servers to identify themselves uniquely
- Event Group ID – A sequence number for a collection of events that are always applied as a unit. Every binlog event group (eg. transaction, DDL, non-transactional statement) is annotated with its GTID
The figure below illustrates the differences between the two GTIDs
In MariaDB, there is no special configuration needed on the server to start using GTID. Some of MariaDB GTID advantages
- It is easy to identify which server or domain the event group is originating from
- You do not necessarily need to turn on binary logging on slaves
- It allows multi-source replication with distinct domain ID
- Enabling GTID features is dynamic, you don’t have to restart the MariaDB server
- The state of the slave is recorded in a crash-safe way
Despite the differences between these two, it is still possible to replicate from MySQL 5. 6 to MariaDB 10. 0 or vice versa. However, you will not be able to use the GTID features to automatically pick the correct binlog position when switching to a new master. Old-style MySQL replication will work
Further reading can be found at MariaDB GTID and MySQL GTID documentation page
2. 3. Multi-Threaded Slave
MySQL 5. 6 allows you to execute replicated events in parallel as long as data is split across several databases. This feature is named “Multi-Threaded Slave” (MTS) and it is easy to enable by setting slave_parallel_workers to a > 1 value. In MySQL 5. 7, it can now be used for any workload, including intra-schema, unlike 5. 6 where it could only be applied with one thread per schema. MySQL 8. 0 introduced write-sets, which allows for even better parallelization of applying binary log events
2. 4. Crash-Safe Slave
Crash safe means even if a slave mysqld/OS crash, you can recover the slave and continue replication without restoring MySQL databases onto the slave. To make crash safe slave work, you have to use InnoDB storage engine only, and in 5. 6 you need to set relay_log_info_repository=TABLE and 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 Hibrid)
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
Instal ClusterControl dengan mengikuti petunjuk di halaman Memulai. Jangan lupa untuk mengatur SSH tanpa kata sandi dari ClusterControl ke semua node (termasuk node ClusterControl itu sendiri). Kami akan menggunakan pengguna root untuk penyebaran. On ClusterControl node, run
Buka UI ClusterControl, buka 'Buat Database Node' dan buka tab 'MySQL Replication'. 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
- Jalur Kunci SSH – SSH Tanpa Kata Sandi memerlukan kunci SSH. 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. Jika Anda ingin mempertahankan pengaturan firewall, hapus centang pada "Nonaktifkan Firewall" namun pastikan port terkait MySQL dibuka sebelum penerapan dimulai, seperti yang ditunjukkan
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. Please refer to the Topology for MySQL Replication features for more details
- 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 – CREATE, 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
At the time of writing, there are several reverse proxies that support read-write splitting 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. This will minimize the changes on the application side
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.202_Perhatikan 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
If the master is down, we need to promote one of the slaves (backup-master) to become a 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. The script must be accessible on the controller and be executable
- 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. naskah STONITH
Shoot The Other Node In The Head (STONITH) adalah proses memastikan master lama yang sudah mati akan tetap mati (dan ya. kami tidak suka zombie berkeliaran di infrastruktur kami). Hal terakhir yang mungkin Anda inginkan adalah memiliki master lama yang tidak responsif yang kemudian kembali online dan, sebagai hasilnya, Anda memiliki dua master yang dapat ditulisi. 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. Oleh karena itu, kemungkinan besar, tidak akan ada dukungan bawaan untuk STONITH di alat failover. Bergantung pada lingkungan, Anda mungkin ingin menjalankan perintah CLI yang akan menghentikan (dan bahkan menghapus) VM tempat master lama berjalan. Jika Anda memiliki penyiapan di tempat, Anda mungkin memiliki kontrol lebih besar atas perangkat keras. Dimungkinkan untuk menggunakan semacam manajemen jarak jauh (Light-out terintegrasi atau akses jarak jauh lainnya ke server). Anda mungkin juga memiliki akses ke soket daya yang dapat dikelola dan mematikan daya di salah satunya untuk memastikan server tidak akan pernah memulai lagi tanpa campur tangan manusia
6. 4. 1. 1. Penemuan LayananKami telah menyebutkan sedikit tentang penemuan layanan. Ada banyak cara seseorang dapat menyimpan informasi tentang topologi replikasi dan mendeteksi host mana yang menjadi master. Jelas, salah satu opsi yang lebih populer adalah menggunakan dll. d or Consul to store data about current topology. Dengannya, aplikasi atau proxy dapat mengandalkan data ini untuk mengirimkan lalu lintas ke node yang benar. ClusterControl (seperti kebanyakan alat yang mendukung penanganan failover) tidak memiliki integrasi langsung dengan yang lainnya. d atau Konsul. Tugas untuk memperbarui data topologi ada pada pengguna. Dia dapat menggunakan pengait seperti replication_post_failover_script atau replication_post_switchover_script untuk menjalankan beberapa skrip dan melakukan perubahan yang diperlukan. Solusi lain yang cukup umum adalah menggunakan DNS untuk mengarahkan lalu lintas ke instance yang benar. Jika Anda akan menjaga Time-To-Live dari catatan DNS tetap rendah, Anda harus dapat menentukan domain, yang akan mengarah ke master Anda (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
In case a slave gets corrupted, or it does not sync with the master for some reason, you might want to rebuild it. 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
- On each slave, rebuild the replication slave by go to ClusterControl > Nodes > slave node > Stage Replication Slave
ClusterControl can also be used to perform a Point in Time Recovery – you can either decide about a point in time (with a granularity of one second) or you can specify exact binary log file and position up to which backup should be restored
A critical part of the backup is the restore. The main issue is that you cannot tell if the backup will work unless you actually attempt to restore it. Every backup is Schrödinger’s backup – it may work or not and you can’t tell its state unless the restore is attempted. That’s why testing of the backups is a must-have. ClusterControl provides you with an easy way of doing that. When scheduling a backup you can decide whether to run the restore test or not
When you decide to do so, you will be presented with another set of options
What you have to define is the hostname or IP of the host on which you want ClusterControl to attempt the recovery. You can ask ClusterControl to set the node up and install MySQL. You can also either shutdown the server after every restore test or just keep it up and reuse it in the future. Backup can be restored either immediately after the backup completed or scheduled to start after a certain delay
Similar case is when you attempt to restore one of the backups
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. Upgrade sedang online dan dilakukan pada satu node pada satu waktu. 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
Depending on whether you are running on GTID-based or standard replication with binlog, the failover steps are different and require close attention. 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. Unfortunately, it is also somewhat fragile
- 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
- Dimungkinkan untuk mengatur replikasi dua arah antara dua server mysql. However, ring topologies are not recommended. MySQL Replication currently does not support any locking protocol between master and slave to guarantee the atomicity of a distributed updated across two different servers
8. 1. Replication Status
The replication status can only be checked from a replicating slave by using the following statement
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-1937The following status variables are the main indicator that replication works as expected
Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0 Master_Server_Id: 1The above indicates the slave’s IO and SQL threads are running, replicating from the Master server (server-id=1) with no replication lag (where Seconds_Behind_Master is 0). Selain status budak yang disebutkan di atas, Anda juga dapat menggunakan pernyataan berikut
- SELECT @@global. gtid_executed – Shows applied transactions
- SELECT @@gtid_purged – Shows applied but purged from binary logs already
8. 2. Replication Lag
Replication lag is the number of seconds that the slave is behind the master. If it happens, your application might read old data from the slave. This somewhat introduces a deficiency on the application side when retrieving data from a lagging slave. For example, you might configure the application to retrieve data when Seconds_Behing_Master is only equal to 0 on that slave. 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. Normally, I/O thread would not cause a big replication delay as it is just reading the binary logs from the master. However, It depends on the network connectivity and latency between the servers. The slave I/O thread could be slow because of high bandwidth usage. Usually, when the slave IO_THREAD is able to read binary logs quickly enough, it copies and piles up the relay logs on the slave – which is one indication that the slave IO_THREAD is not the culprit of slave lag
When the slave SQL_THREAD is the source of replication delays, it is probably because the queries coming from the replication stream are taking too long to execute on the slave. This is sometimes due to different hardware between master/slave, different schema indexes or workload. Moreover, the slave OLTP workload sometimes causes replication delays because of locking. Take note that replication is single threaded prior to MySQL 5. 6, which would be another reason for delays on the slave’s SQL_THREAD
8. 3. Data Drifting
Though the main purpose of replication is to have exact copies of data across the replication setup, data drifting can still happen between a MySQL master and its replicas. This can happen if there is transaction rollback on a non-transactional storage engine, a non-deterministic statement with statement-based replication, software bugs or human/application mistakes. Konsistensi slave juga perlu diperiksa setelah peristiwa kegagalan master, karena pergeseran data mungkin terjadi setelah master baru dipromosikan
You can use Percona Toolkit’s pt-table-checksum to perform an online replication consistency check by executing checksum queries on the master, which produces different results on replicas that are inconsistent with the master. Then, you can apply the missing transactions manually or use pt-table-sync to resynchronize the slave
Using row-based replication (by setting binlog_format=ROW) is also a safe bet to reduce the risk of data drifting. With row-based replication, the master writes events to the binary log that indicate how individual table rows are changed. Replication of the master to the slave works by copying the events representing the row changes to the slave
8. 4. Errant Transaction
Errant transactions are transactions that are executed directly on a slave in GTID-based replication. Thus, they only exist on a specific slave. This could be the result of a mistake e. g, the application wrote to a slave instead of writing to the master or this could be by design e. g, you need additional tables for reports. It can cause data corruption or replication error if a slave with an errant transaction is promoted to the new master. The main issue with errant transactions is that when failing over, the slave may execute transactions ‘coming from nowhere’ that can silently corrupt your data or break replication
If you find an errant transaction on one server, there are two ways to overcome errant transaction
- Either commit an empty transaction with the GTID of the errant one on all other servers;
- Or, remove the corresponding GTID on the offending slave
The bottomline is, before a new slave is promoted to be a master, it is necessary to check for errant transactions. We have covered this topic in detail in this blog post, MySQL Replication and GTID-based failover – A Deep Dive into Errant Transactions
8. 5. Corrupted Slave
Corrupted slave happens when the relay logs are corrupted. A relay log is a log file of the binary log events coming from the master via replication IO thread. In case of corruption, replication would stop on the slave. There are multiple reasons that could lead to this problem, it could be network (especially if replicating over unreliable long distance networks), MySQL bugs on master or slave, hardware problems and few others
Firstly, verify if the corruption happens on master or slave. A good indicator is if the other slaves are replicating without error, it’s most likely that only the relay log on that particular slave is corrupted. To fix it, simply re-point the replication on the slave to Relay_Master_Log_FIle. Exec_Master_Log_Pos