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 Show
Isi dari whitepaper
Download the whitepaper 1. IntroductionMySQL 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
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
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 ReplikasiSaat ini ada dua skema replikasi yang didukung oleh Replikasi MySQL
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 ReplicationMySQL 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
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 ReplicationMySQL 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 SebelumnyaIn 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 ProblemGTID (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 GTIDMariaDB 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
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
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 SlaveMySQL 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 SlaveCrash 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 GrupInnoDB, 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 MySQL3. 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
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 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 MySQLSekarang 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 SSHDi bawah "Pengaturan Umum & SSH", tentukan informasi yang diperlukan
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 MySQLPindah ke tab berikutnya, tentukan opsi instalasi dan konfigurasi Server MySQL
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 TopologiDi 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
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
Cluster Replikasi MySQL sekarang digunakan 4. 4. PenskalaanMenggunakan 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
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 ReplikasiSekarang, 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
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 AplikasiJika 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
5. 2. Konektor Sadar KainOracle 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 BalancerDimungkinkan 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 MaxScaleMariaDB 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. ProxySQLProxySQL 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
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
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 ClusterControlAgar 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 OtomatisUntuk 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
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 HitamUntuk mengantisipasi budak berikutnya dipromosikan sebagai master baru selama failover, ada dua variabel yang dapat Anda atur dalam file konfigurasi CMON untuk cluster ini
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 _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 MasterPenulisan 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 BudakJika 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-KegagalanClusterControl menyediakan beberapa pengait yang dapat digunakan untuk menyambungkan skrip eksternal. Di bawah ini Anda akan menemukan daftarnya dengan beberapa penjelasan
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
Tentu 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 AndaCara 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 ReplikasiAnda 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 ReplikasiClusterControl 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 BudakMempromosikan 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 ReplikasiIn 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. CadanganKami 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. MemulihkanClusterControl 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
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 UpgradeYou 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 ChangesSystem 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 ChangesTraditionally, 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
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 ChangesReplication 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 TroubleshootingBecause it is simple to setup, MySQL Replication is probably the most widely used mechanism to provide high availability. Unfortunately, it is also somewhat fragile
8. 1. Replication StatusThe replication status can only be checked from a replicating slave by using the following statement
The following status variables are the main indicator that replication works as expected
The 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
8. 2. Replication LagReplication 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
Sementara SQL_THREAD, budak
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 DriftingThough 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 TransactionErrant 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
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 SlaveCorrupted 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 How to implement replication in MySQL database?7 Steps To Achieve MySQL Master-Slave Replication . Setting Up The Master Create A New User For Slave Move Data From Master To Slave Configure Slave Server Import Data Dump Start Slave Server Test MySQL Master-Slave Replication How does replication works in MySQL?Replication enables data from one MySQL database server (known as a source) to be copied to one or more MySQL database servers (known as replicas) . Replication is asynchronous by default; replicas do not need to be connected permanently to receive updates from a source.
How to enable replication in MySQL?Step 1. Configure MySQL Database for Replication Step 2. Create 2 Separate Cloud Servers Step 3. Update All Software Packages to their Current Version Step 4. Install MySQL Step 5. Mulai MySQL Step 6. Set Up MySQL Server Root Password Step 7. Configure Firewall for Database Access How is database replication done?Database replication can be done in at least three different ways. Dalam replikasi snapshot, data di satu server hanya disalin ke server lain atau ke database lain di server yang sama. In merging replication, data from two or more databases is combined into a single database |