Cara menggunakan delete relay bin mysql

Saya berkenalan dengan replikasi server MySQL relatif baru-baru ini, dan ketika saya melakukan berbagai eksperimen dengan penyiapan, saya menuliskan apa yang saya lakukan. Ketika bahannya banyak, muncul ide untuk menulis artikel ini. Saya telah mencoba mengumpulkan tip dan solusi untuk beberapa pertanyaan paling mendasar yang saya temui. Saya akan memberikan tautan ke dokumentasi dan sumber lain di sepanjang jalan. Saya tidak bisa mengklaim sebagai lengkap, tapi semoga artikel ini bermanfaat.

Pengenalan kecil

Replikasi [dari bahasa Latin replico - saya ulangi] adalah replikasi perubahan data dari server database utama pada satu atau lebih server yang bergantung. Server utama akan dipanggil menguasai, dan tergantung - replika.
Perubahan data yang terjadi pada master diulangi pada replika [tetapi tidak sebaliknya]. Oleh karena itu, permintaan untuk mengubah data [INSERT, UPDATE, DELETE, dll.] Dijalankan hanya pada master, dan permintaan untuk membaca data [dengan kata lain, PILIH] dapat dijalankan baik pada replika maupun pada master. Proses replikasi pada salah satu replika tidak memengaruhi pengoperasian replika lainnya, dan secara praktis tidak memengaruhi pekerjaan master.
Replikasi dilakukan menggunakan log biner yang dikelola di master. Mereka menyimpan semua kueri yang mengarah [atau berpotensi mengarah] ke perubahan dalam database [kueri tidak disimpan secara eksplisit, jadi jika Anda ingin melihatnya, Anda harus menggunakan utilitas mysqlbinlog]. Binlog ditransfer ke replika [binlog yang diunduh dari master disebut "relay binlog"] dan kueri yang disimpan dijalankan mulai dari posisi tertentu. Penting untuk dipahami bahwa replikasi tidak mentransfer data yang diubah itu sendiri, tetapi hanya permintaan yang menyebabkan perubahan.
Selama replikasi, konten database digandakan di beberapa server. Mengapa menggunakan duplikasi? Ada beberapa alasan:

• kinerja dan skalabilitas... Satu server mungkin tidak dapat mengatasi beban yang disebabkan oleh operasi baca dan tulis simultan pada database. Manfaat membuat replika akan lebih besar jika semakin banyak pembacaan per tulis di sistem Anda.
• toleransi kesalahan... Jika terjadi kegagalan replika, semua permintaan baca dapat ditransfer dengan aman ke master. Jika master gagal, permintaan tulis dapat ditransfer ke replika [setelah master dipulihkan, ia dapat mengambil alih peran replika].
• cadangan data... Replika dapat diperlambat untuk menjalankan mysqldump, tetapi master tidak bisa.
• komputasi malas... Kueri SQL yang berat dan lambat dapat dijalankan pada replika terpisah tanpa takut mengganggu operasi normal seluruh sistem.

Selain itu, ada beberapa kemungkinan menarik lainnya. Karena bukan datanya sendiri yang ditransfer ke replika, tetapi kueri yang menyebabkan perubahannya, kita dapat menggunakan struktur tabel yang berbeda pada master dan replika. Secara khusus, jenis tabel [mesin] atau kumpulan indeks mungkin berbeda. Misalnya, untuk melakukan pencarian teks lengkap, kita dapat menggunakan tipe tabel MyISAM pada replika, meskipun wizard akan menggunakan InnoDB.

Penyiapan replikasi

Katakanlah kita memiliki database MySQL yang berfungsi sudah diisi dengan data dan berjalan. Dan untuk salah satu alasan yang dijelaskan di atas, kami akan mengaktifkan replikasi server kami. Data awal kami:

• Alamat IP master adalah 192.168.1.101, replikanya adalah 192.168.1.102.
• MySQL terinstal dan dikonfigurasi
• anda perlu mengkonfigurasi testdb replikasi database
• kita bisa menghentikan sementara wizard untuk sementara
• kami, tentu saja, memiliki root pada kedua mesin

Pengaturan WizardPastikan untuk menunjukkan ID server unik, jalur untuk log biner dan nama database untuk replikasi di bagian:
server-id \u003d 1
log-bin \u003d / var / lib / mysql / mysql-bin
replicate-do-db \u003d testdb
Pastikan Anda memiliki cukup ruang disk untuk log biner.

Tambahkan pengguna replikasi, di bawah hak siapa replikasi akan dilakukan. Hak istimewa "budak replikasi" sudah cukup:
[email dilindungi]\u003e GRANT replikasi budak ON "testdb". * TO "replication" @ "192.168.1.102" DIIDENTIFIKASI OLEH "password";

Mulai ulang MySQL agar perubahan konfigurasi diterapkan:
[email dilindungi]# layanan mysqld restart

Jika semuanya berjalan dengan baik, perintah "tampilkan status master" akan menunjukkan sesuatu seperti berikut:
[email dilindungi]\u003e TAMPILKAN STATUS MASTER \\ G
File: mysql-bin.000003
Posisi: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Nilai posisi harus meningkat seiring dengan perubahan yang dilakukan pada database di master.

Pengaturan replikaTentukan ID server, nama database untuk replikasi dan jalur ke binlog relai di bagian konfigurasi, lalu mulai ulang MySQL:
server-id \u003d 2
relai-log \u003d / var / lib / mysql / mysql-relai-bin
relai-log-index \u003d /var/lib/mysql/mysql-relay-bin.index
replicate-do-db \u003d testdb

[email dilindungi]# layanan mysqld restart

Kami mentransfer dataDi sini kita harus mengunci database untuk menulis. Untuk melakukan ini, Anda dapat menghentikan pekerjaan aplikasi, atau menggunakan pengaturan flag read_only di wizard [catatan: flag ini tidak berpengaruh pada pengguna dengan hak istimewa SUPER]. Jika kita memiliki tabel MyISAM, mari lakukan juga "flush tables":
[email dilindungi]\u003e TABEL FLUSH DENGAN KUNCI BACA;
[email dilindungi]\u003e SETEL GLOBAL read_only \u003d ON;

Mari kita lihat status master dengan perintah "tampilkan status master" dan ingat nilai File dan Posisi [setelah berhasil memblokir master, nilai tersebut tidak boleh berubah]:
File: mysql-bin.000003
Posisi: 98

Kami membuat dump database, dan setelah operasi selesai, kami membuka kunci master:
[email dilindungi]\u003e SETEL GLOBAL read_only \u003d OFF;

Kami mentransfer dump ke replika dan memulihkan data darinya.
Terakhir, mulai replikasi dengan perintah "ubah master menjadi" dan "mulai budak" dan lihat apakah semuanya berjalan dengan baik:
[email dilindungi]\u003e GANTI MASTER KE MASTER_HOST \u003d "192.168.1.101", MASTER_USER \u003d "replikasi", MASTER_PASSWORD \u003d "kata sandi", MASTER_LOG_FILE \u003d "mysql-bin.000003", MASTER_LOG_POS \u003d 98;
[email dilindungi]\u003e mulai budak;
Kami mengambil nilai MASTER_LOG_FILE dan MASTER_LOG_POS dari master.

Mari kita lihat bagaimana proses replikasi dengan perintah "tampilkan status budak":
[email dilindungi]\u003e TAMPILKAN STATUS BUDAK \\ G
Slave_IO_State: Menunggu master mengirim acara
Master_Host: 192.168.1.101
Master_User: replikasi
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Ya
Slave_SQL_Running: Ya
Replicate_Do_DB: testdb, testdb
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: 98
Relay_Log_Space: 235
Kondisi_Kondisi: Tidak Ada
Hingga_file_log:
Sampai_Log_Pos: 0
Master_SSL_Allowed: Tidak
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Saya telah menyoroti arti yang paling menarik sekarang. Jika replikasi berhasil dimulai, nilainya harus kurang lebih sama seperti dalam daftar [lihat deskripsi perintah "tampilkan status budak" dalam dokumentasi]. Nilai Seconds_Behind_Master dapat berupa bilangan bulat apa pun.
Jika replikasi berjalan dengan baik, replika akan mengikuti master [nomor log di Master_Log_File dan posisi Exec_Master_Log_Pos akan bertambah]. Waktu replika tertinggal di belakang master [Seconds_Behind_Master], idealnya, harus nol. Jika replika tidak berkurang atau bertambah, mungkin beban pada replika terlalu tinggi - replika tidak punya waktu untuk mengulangi perubahan yang terjadi pada master.
Jika Slave_IO_State kosong dan Seconds_Behind_Master adalah NULL, replikasi belum dimulai. Periksa log MySQL untuk mencari tahu penyebabnya, perbaiki, dan mulai ulang replikasi:
[email dilindungi]\u003e mulai budak;

Melalui tindakan sederhana ini, kami mendapatkan replika, yang datanya identik dengan data di master.
Omong-omong, waktu kunci utama adalah waktu pembuangan. Jika ini membutuhkan waktu yang sangat lama, Anda dapat mencoba melakukan ini:

• blokir penulisan ke master dengan flag read_only, ingat posisinya dan hentikan MySQL.
• setelah itu, salin file database ke replika dan nyalakan master.
• mulai replikasi dengan cara biasa.

Ada beberapa cara untuk membuat replika tanpa menghentikan master sama sekali, tetapi cara tersebut tidak selalu berhasil.

Tambahkan replika

Misalkan kita sudah memiliki master yang berfungsi dan replika, dan kita perlu menambahkan master lain ke dalamnya. Ini bahkan lebih mudah daripada menambahkan replika pertama ke master. Dan yang jauh lebih menyenangkan adalah tidak perlu menghentikan sang guru untuk ini.
Pertama, mari kita siapkan MySQL di replika kedua dan pastikan kita telah memasukkan parameter yang diperlukan di konfigurasi:
server-id \u003d 3
replicate-do-db \u003d testdb

Sekarang mari kita hentikan replikasi pada replika pertama:
[email dilindungi]\u003e hentikan budak;

Replika akan terus berfungsi secara normal, tetapi datanya tidak lagi mutakhir. Mari kita lihat status dan ingat posisi master, yang dicapai replika sebelum menghentikan replikasi:
[email dilindungi]\u003e TAMPILKAN STATUS BUDAK \\ G

Kami akan membutuhkan nilai Master_Log_File dan Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Mari buat dump database dan lanjutkan replikasi pada replika pertama:
[email dilindungi]\u003e MULAI BUDAK;

Mari pulihkan data dari dump di replika kedua. Kemudian kami mengaktifkan replikasi:
[email dilindungi]\u003e GANTI MASTER KE MASTER_HOST \u003d "192.168.1.101", MASTER_USER \u003d "replikasi", MASTER_PASSWORD \u003d "kata sandi", MASTER_LOG_FILE \u003d "mysql-bin.000004", MASTER_LOG_POS \u003d 155;
[email dilindungi]\u003e MULAI BUDAK;

Nilai MASTER_LOG_FILE dan MASTER_LOG_POS masing-masing adalah nilai Master_Log_File dan Exec_Master_Log_Pos dari hasil perintah show slave status pada replika pertama.
Replikasi harus dimulai dari posisi replika pertama dihentikan [dan, karenanya, dump dibuat]. Jadi, kita akan memiliki dua replika dengan data yang identik.

Menggabungkan replika

Terkadang situasi seperti itu muncul: ada dua database pada master, salah satunya direplikasi pada satu replika, dan yang kedua direplikasi di replika lainnya. Bagaimana cara mengatur replikasi dua database pada kedua replika tanpa membuat dump pada master dan tanpa mematikannya? Cukup sederhana dengan menggunakan perintah "mulai budak sampai".
Jadi, kami memiliki master dengan database testdb1 dan testdb2, yang masing-masing direplikasi pada replika-1 dan replika-2. Mari konfigurasikan replikasi kedua database ke replika-1 tanpa menghentikan master.
Hentikan replikasi pada replika-2 dengan perintah dan ingat posisi master:
[email dilindungi]\u003e BERHENTI BUDAK;
[email dilindungi]\u003e TAMPILKAN STATUS BUDAK \\ G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Mari buat dump database testdb2 dan lanjutkan replikasi [saat ini, manipulasi dengan replika-2 sudah selesai]. Kembalikan dump ke replika-1.

Situasi di replika-1 adalah sebagai berikut: database testdb1 berada di posisi master yang sama dan terus mereplikasi, database testdb2 dipulihkan dari dump dari posisi yang berbeda. Kami menyinkronkannya.

Hentikan replikasi dan ingat posisi master:
[email dilindungi]\u003e BERHENTI BUDAK;
[email dilindungi]\u003e TAMPILKAN STATUS BUDAK \\ G
Exec_Master_Log_Pos: 501

Pastikan bahwa di konfigurasi pada replika-1, bagian tersebut berisi nama database kedua:
replicate-do-db \u003d testdb2

Mulai ulang MySQL agar perubahan konfigurasi diterapkan. Ngomong-ngomong, Anda bisa memulai ulang MySQL tanpa menghentikan replikasi - dari log kami akan mengetahui di posisi mana replikasi master berhenti.

Sekarang mari kita mereplikasi dari posisi di mana replika-2 dijeda ke posisi di mana kita baru saja menjeda replikasi:
[email dilindungi]\u003e GANTI MASTER KE MASTER_HOST \u003d "192.168.1.101", MASTER_USER \u003d "replikasi", MASTER_PASSWORD \u003d "kata sandi", MASTER_LOG_FILE \u003d "mysql-bin.000015", MASTER_LOG_POS \u003d 231;
[email dilindungi]\u003e mulai budak hingga MASTER_LOG_FILE \u003d "mysql-bin.000016", MASTER_LOG_POS \u003d 501;

Replikasi akan berakhir segera setelah replika mencapai posisi yang ditentukan di bagian hingga, setelah itu kedua database kami akan sesuai dengan posisi master yang sama [di mana kami menghentikan replikasi pada replika-1]. Mari kita pastikan ini:
[email dilindungi]\u003e TAMPILKAN STATUS BUDAK \\ G
[email dilindungi]\u003e MULAI BUDAK;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Tambahkan nama kedua database ke konfigurasi pada replika-1 di bagian:
replicate-do-db \u003d testdb1
replicate-do-db \u003d testdb2

Penting: setiap database harus dicantumkan di baris terpisah.
Mulai ulang MySQL dan lanjutkan dengan replikasi:
[email dilindungi]\u003e GANTI MASTER KE MASTER_HOST \u003d "192.168.1.101", MASTER_USER \u003d "replikasi", MASTER_PASSWORD \u003d "kata sandi", MASTER_LOG_FILE \u003d "mysql-bin.000016", MASTER_LOG_POS \u003d 501;
Setelah replika-1 mengejar master, konten database mereka akan sama. Anda bisa menggabungkan database pada replika-2 dengan cara yang sama, atau dengan membuat dump penuh replika-1.

Casting Master dan Replika

Mungkin perlu untuk mengganti replika ke mode master, misalnya, jika master gagal atau saat melakukan pekerjaan teknis padanya. Untuk mengaktifkan sakelar semacam itu, Anda perlu mengonfigurasi replika seperti master, atau membuatnya master pasif.

Mari aktifkan pemeliharaan log biner [selain relay-binlogs] di bagian config:
log-bin \u003d / var / lib / mysql / mysql-bin

Dan tambahkan pengguna untuk replikasi:
[email dilindungi]\u003e GRANT replikasi budak ON 'testdb'. * TO 'replication'@'192.168.1.101' DIIDENTIFIKASI OLEH "password";

Master pasif mereplikasi seperti replika biasa, tetapi selain itu, ia membuat logika biner - yaitu, kita dapat memulai replikasi darinya. Mari kita pastikan ini dengan perintah "show master status":
[email dilindungi]\u003e TAMPILKAN STATUS MASTER \\ G
Berkas: mysql-bin.000001
Posisi: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Sekarang, untuk membawa master pasif ke mode aktif, Anda harus menghentikan replikasi di atasnya dan mengaktifkan replikasi di master aktif sebelumnya. Agar pada saat perpindahan data tidak hilang, master aktif harus dikunci untuk menulis.
[email dilindungi]\u003e TABEL FLUSH DENGAN KUNCI BACA
[email dilindungi]\u003e SETEL GLOBAL read_only \u003d ON;
[email dilindungi]\u003e BERHENTI BUDAK;
[email dilindungi]\u003e TAMPILKAN STATUS MASTER;
File: mysql-bin.000001
Posisi: 61
[email dilindungi]\u003e GANTI MASTER KE MASTER_HOST \u003d "192.168.1.102", MASTER_USER \u003d "replikasi", MASTER_PASSWORD \u003d "kata sandi", MASTER_LOG_FILE \u003d "mysql-bin.000001", MASTER_LOG_POS \u003d 61;
[email dilindungi]\u003e mulai budak;
Itu saja, begitulah cara kami mengubah master aktif. Anda dapat melepas kunci dari master sebelumnya.

Kesimpulan

Kami menemukan sedikit tentang cara mengatur replikasi di MySQL dan melakukan beberapa operasi dasar. Sayangnya, pertanyaan penting berikut tetap berada di luar cakupan artikel: