Bagaimana replikasi diimplementasikan di mysql?

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

  • 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

Bagaimana replikasi diimplementasikan di mysql?

Bagaimana replikasi diimplementasikan di mysql?

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)

Bagaimana replikasi diimplementasikan di mysql?

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)

Bagaimana replikasi diimplementasikan di mysql?

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)

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

$ ssh-keygen -t rsa
$ ssh-copy-id 10.0.0.200 # clustercontrol
$ ssh-copy-id 10.0.0.201 # master
$ ssh-copy-id 10.0.0.202 # backup-master
$ ssh-copy-id 10.0.0.203 # slave1
$ ssh-copy-id 10.0.0.204 # slave2

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di 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

Bagaimana replikasi diimplementasikan di mysql?

  • 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

Bagaimana replikasi diimplementasikan di mysql?

ClusterControl melakukan tugas-tugas berikut

  1. Memverifikasi konektivitas SSH
  2. Instal Server MySQL yang ditentukan
  3. Membuat datadir dan menginstal tabel sistem
  4. Membuat/memberikan pengguna mysql untuk MySQL Server
  5. Memberikan pengguna CMON dari server ClusterControl
  6. Mengonfigurasi peran replikasi untuk MySQL (master/slave)
  7. Memverifikasi penerapan
  8. 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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

ClusterControl melakukan tugas-tugas berikut saat membuat budak baru

  1. Memverifikasi konektivitas SSH
  2. Instal versi utama Server MySQL yang sama dengan master dari repositori
  3. Membuat datadir dan menginstal tabel sistem
  4. Membuat/memberikan pengguna mysql untuk MySQL Server
  5. Memberikan pengguna CMON dari server ClusterControl
  6. Tahapan data pada budak dari master yang dipilih
  7. Mengonfigurasi peran replikasi untuk budak MySQL dengan GTID
  8. Memulai replikasi
  9. Memverifikasi penerapan
  10. Mendaftarkan node di bawah "cluster ID" yang sesuai di server ClusterControl
  11. 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

Bagaimana replikasi diimplementasikan di mysql?

Di bagian akhir, Anda akan melihat ringkasan replikasi dari halaman Ikhtisar

Bagaimana replikasi diimplementasikan di mysql?

Anda juga dapat mengonfirmasi topologi di Tampilan Topologi

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di 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

  1. Jika ClusterControl tidak dapat tersambung ke server master, ClusterControl akan menandai kegagalan master sebagai offline
  2. Alarm akan dibunyikan untuk menunjukkan kegagalan replikasi dan semua node yang tersedia dalam mode read-only
  3. ClusterControl akan memilih kandidat master berdasarkan replication_failover_whitelist, replication_failover_blacklist, atau slave terbaru
  4. 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
  5. ClusterControl kemudian akan melakukan master failover dengan menghentikan semua budak dan melakukan pernyataan CHANGE MASTER ke master baru
  6. Jika failover berhasil (semua budak dimulai), ClusterControl menandai master baru sebagai dapat ditulisi (set read_only = 0) dan alarm dihapus
  7. 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

Bagaimana replikasi diimplementasikan di mysql?

Anda akan diminta dengan yang berikut ini

Bagaimana replikasi diimplementasikan di mysql?

Secara efektif, budak yang dipilih telah menjadi master baru dan akan memproses pembaruan saat master lama mati

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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.sh

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 Layanan

Kami 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 Proksi

Setiap 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 Tambahan

Mungkin 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

Bagaimana replikasi diimplementasikan di mysql?

Anda dapat menemukan detail lebih lanjut tentang status master, status slave, dan statistik host langsung dari halaman Ikhtisar Cluster

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

Sebelum melanjutkan proses pembangunan kembali dari ClusterControl, Anda harus memilih master yang tersedia. Proses slave akan dimulai secara otomatis setelah pembangunan kembali selesai

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

Bagaimana replikasi diimplementasikan di mysql?

Untuk menjadwalkan pencadangan, klik "Jadwalkan Pencadangan" dan konfigurasikan penjadwalan yang sesuai

Bagaimana replikasi diimplementasikan di mysql?

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".

Bagaimana replikasi diimplementasikan di mysql?

Untuk memulihkan cadangan, cukup klik tombol "Pulihkan" untuk cadangan tersebut. Anda kemudian akan melihat wizard Pemulihan berikut dan beberapa opsi pasca-pemulihan

Bagaimana replikasi diimplementasikan di mysql?

Jika pencadangan dilakukan menggunakan Percona Xtrabackup, replikasi harus dihentikan. Langkah-langkah berikut akan dilakukan

  1. Hentikan semua node dalam penyiapan replikasi
  2. Salin file cadangan ke server yang dipilih
  3. Pulihkan cadangan
  4. Setelah tugas pemulihan selesai, mulai node yang dipulihkan di ClusterControl > Nodes > pilih node yang dipulihkan > Mulai Node
  5. Setelah dimulai, promosikan node sebagai master baru (jika bukan master) di ClusterControl > Nodes > pilih node yang dipulihkan > Promosikan Slave
  6. 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

Bagaimana replikasi diimplementasikan di mysql?

When you decide to do so, you will be presented with another set of options

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

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

Bagaimana replikasi diimplementasikan di mysql?

If a restart is required, ClusterControl will acknowledge that in the Config Change Log dialog

Bagaimana replikasi diimplementasikan di mysql?

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-1937

The 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: 1

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

  • 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

Bagaimana replikasi diimplementasikan di mysql?

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

  1. terhubung ke master,
  2. membaca peristiwa log biner dari master saat mereka masuk,
  3. menyalinnya ke file log lokal yang disebut log relai

Sementara SQL_THREAD, budak

  1. membaca peristiwa dari log relai, disimpan secara lokal di budak replikasi (file yang ditulis oleh utas IO)
  2. 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

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