Dalam arsitektur ketersediaan tinggi MySQL, replikasi basis data utama adalah jenis yang sangat umum.
Saat database utama turun, Anda dapat meningkatkan database slave sebagai database utama baru untuk memastikan ketersediaan layanan. Pada saat yang sama, QPS dari seluruh kluster dapat ditingkatkan dengan memperluas perpustakaan slave.
Di bawah arsitektur replikasi master-slave, MySQL menggunakan binlog untuk mencapai konsistensi data master-slave.
Seperti yang ditunjukkan pada gambar di atas, replikasi master-slave MySQL terutama memiliki langkah-langkah berikut
1. Master mencatat perubahan pada log biner
2. Slave io_thread meminta binlog perpustakaan utama dan menulis log binlog yang dihasilkan ke log relai
3. Peristiwa sql_thread ulang slave di log relai
Selain menjadi tautan untuk replikasi master-slave MySQL, binlog juga melayani tujuan lain. Seperti apa:
1. Gunakan alat mysqlbinlog untuk mengurai file binlog untuk melakukan pemulihan database titik waktu.
2. Kilas balik database berdasarkan peristiwa binlog (MariaDB dapat langsung menggunakan mysqlbinlog untuk kilas balik)
3. Alat pengubah tabel online sumber terbuka Github gh-ost juga diimplementasikan melalui binlog
4. Anda juga dapat berlangganan & mengkonsumsi secara bertahap dengan mengurai binlog
Binlog sangat berguna, tetapi tidak dapat dihindari bahwa Anda akan menghadapi beberapa masalah dalam proses operasi dan pemeliharaan sehari-hari. Berikut adalah beberapa kesalahan terkait binlog.
Salah satu pertanyaan yang sering diajukan
fenomena
mysqlbinlog5.5 mengurai mysql5.7 binlog file muncul
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Analisis penyebab
MySQL 5.6 dan versi file binlog lainnya yang lebih tinggi telah menambahkan peristiwa binlog baru, seperti peristiwa GTID.
mysqlbinlog di mysql5.5 tidak mengenali peristiwa binlog tersebut.
Solusi
Gunakan mysqlbinlog versi yang lebih tinggi untuk menyelesaikan binlog yang dihasilkan oleh versi mysql yang lebih rendah
Pertanyaan yang sering diajukan dua
fenomena
Server mysql yang sehat menunjukkan status slave muncul
Last_SQL_Error:Kegagalan membaca log relai: Tidak dapat mengurai entri peristiwa log relai.
Alasannya yang mungkin adalah: log biner master rusak (Anda dapat memeriksanya dengan menjalankan 'mysqlbinlog' pada log biner),
log relai budak rusak (Anda dapat memeriksanya dengan menjalankan 'mysqlbinlog' pada log relai),
masalah jaringan, atau bug dalam kode MySQL master atau budak.
Jika Anda ingin memeriksa log biner master atau log relai budak,
Anda akan dapat mengetahui nama mereka dengan mengeluarkan 'TUNJUKKAN STATUS BUDAK' pada budak ini.
Analisis penyebab
Entri dalam log relai tidak dapat dibaca karena kesalahan binlog di perpustakaan master, kesalahan log relai di pustaka slave, atau masalah dan bug jaringan. Ini biasanya disebabkan oleh kegagalan jaringan atau tekanan berlebihan pada perpustakaan slave, mengakibatkan format relay-log yang salah.
Solusi
Setelah menemukan titik waktu sinkronisasi saat ini dan mengatur ulang sinkronisasi master-slave, log relai baru akan dihasilkan dan sinkronisasi master-slave akan dipulihkan.
Dari output "tampilkan status budak\G", temukan informasi berikut:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos master yang dibaca oleh perpustakaan slave: 950583017 // Titik posisi posisi yang telah dieksekusi pada slave
Hentikan slave dan atur sinkronisasi lagi mulai dari file binlog yang telah dibaca slave dan posisi yang telah dieksekusi.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos master yang dibaca oleh perpustakaan slave: 950583017 // Titik posisi posisi yang telah dieksekusi pada slave
Pertanyaan yang sering diajukan ketiga
fenomena
Pulihkan tampilkan status budak setelah kesalahan downtime:
Last_SQL_Error: Kesalahan menginisialisasi posisi log relai: Kesalahan I/O saat membaca header dari log biner
Last_SQL_Error: Kesalahan menginisialisasi posisi log relai: Binlog memiliki angka ajaib yang buruk; Ini bukan file log biner yang dapat digunakan oleh versi MySQL ini
Analisis penyebab
Waktu henti, seperti kegagalan daya, pembakaran motherboard, dll., atau shutdown ilegal, yang mengakibatkan kerusakan file relay-bin
Solusi
Pertanyaan kedua yang sama.
relay_log_recovery = 1 juga dapat diatur.
Ketika slave turun dari perpustakaan, jika log relai rusak dan bagian dari log relai tidak diproses, log relai secara otomatis ditinggalkan, dan log diambil kembali dari master, menyelesaikan pemulihan log relai.
Pertanyaan yang sering diajukan empat
fenomena
Muncul saat mengubah master ke setelah reboot dari mesin pustaka turun
Kesalahan (Kode 1201): Tidak dapat menginisialisasi struktur info master; lebih banyak pesan kesalahan dapat ditemukan di log kesalahan MySQL
atau
KESALAHAN 1872 (HY000): Slave gagal menginisialisasi struktur info log relai dari repositori
Analisis penyebab
Waktu henti, seperti kegagalan daya, motherboard terbakar, dll., atau shutdown ilegal, menyebabkan kerusakan pada file master.info atau realy-log.info
Solusi
budak> atur ulang budak semua, ubah master menjadi
Tindakan pencegahan
Setelan profil
relay_log_info_repository=tabel
master_info_repository=tabel
Mesin penyimpanan MySQL 5.6.5 mysql.slave_master_info dan mysql.slave_relay_log_info diatur ke MyISAM secara default, dan Anda perlu mengubahnya ke mesin penyimpanan InnoDB
UBAH TABEL mysql.slave_master_info MESIN=InnoDB;
UBAH TABEL mysql.slave_relay_log_info MESIN=InnoDB;
mysql.slave_master_info tabel akan diperbarui setelah sync_master_info acara.
mysql.slave_relay_log_info tabel akan diperbarui dengan setiap komitmen transaksi.
Pertanyaan yang sering diajukan 5
fenomena
Master slave awalnya binlog_format sebuah pernyataan, setelah mengubah database utama binlog_format ke baris, tampilkan status slave muncul dari perpustakaan:
Last_Error: Kesalahan saat menjalankan peristiwa baris: 'Tidak dapat mengeksekusi pernyataan: tidak mungkin untuk menulis ke log biner karena pernyataan dalam format baris dan BINLOG_FORMAT = PERNYATAAN.'
Analisis penyebab
Ketika binlog_format database utama adalah baris, dan perpustakaan slave binlog_format adalah pernyataan, kesalahan di atas akan muncul.
Tetapi perpustakaan utama binlog_format adalah pernyataan, dan perpustakaan budak binlog_format baris;
Atau jika database utama binlog_format adalah baris, kesalahan tidak akan dilaporkan jika binlog_format database dicampur.
Jika utas SQL Anda memang dikonfigurasi dengan
binlog_format=STATEMENT, setelah menerima peristiwa ROW, itu akan berhenti. Itu
alasannya adalah bahwa itu tidak akan dapat mencatat peristiwa ROW itu dalam format STATEMENT (terkadang kita menyebutnya sebagai injeksi ROW, yang merupakan
BINLOG atau peristiwa ROW yang dijalankan oleh utas SQL budak)
Referensi alasan terperinci:https://bugs.mysql.com/bug.php?id=69095
Solusi
BUDAK> BUDAK;
BUDAK> SET GLOBAL binlog_format=CAMPURAN;
BUDAK> MULAI BUDAK;
Pertanyaan yang sering diajukan nomor 6
fenomena
Kesalahan saat menyinkronkan mysql5.6 ke mysql5.5
Last_IO_Error: Mendapat kesalahan fatal 1236 dari master saat membaca data dari log biner: 'Slave tidak dapat menangani peristiwa replikasi dengan checksum yang dikonfigurasi master untuk mencatat; Peristiwa pertama 'mysql-bin.000001' pada pukul 4, peristiwa terakhir dibaca dari 'mysql-bin.000001' pada 120, byte terakhir dibaca dari 'mysql-bin.000001' pada 120.'
Analisis penyebab
Untuk memecahkan masalah bahwa pernyataan SQL yang berjalan di server utama tidak konsisten dengan pernyataan SQL yang berjalan di server (disebut peristiwa rusak) karena kesalahan transmisi perangkat lunak dan perangkat keras atau jaringan, MySQL 5.6 menambahkan fungsi Checksum Peristiwa Replikasi. Ketika sebuah peristiwa ditulis ke log biner, checksum juga ditulis ke log biner, dan kemudian setelah peristiwa ditransmisikan ke budak melalui jaringan, itu diverifikasi pada budak dan ditulis ke log relai budak. Karena peristiwa dan checksum dicatat di setiap langkah, kita dapat dengan cepat mengetahui apa masalahnya.
Dalam mysql5.6.5 dan versi yang lebih baru binlog_checksum nilai defaultnya adalah crc32,
Nilai default binlog_checksum versi sebelumnya adalah tidak ada
larutan
Slave> atur global binlog_checksum=none
Pertanyaan yang sering diajukan 7
fenomena
Setelah disk penuh, bersihkan file binlog dan file mysql-bin.index secara manual
Tampilkan log biner kosong, tetapi tampilkan status master normal.
mysql> menampilkan log biner; Set kosong (0,00 detik)mysql> tampilkan status master;
+------------------+-----------+--------------+------------------+
| Berkas | Posisi | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| MySQL-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analisis penyebab
Setelah memeriksa file mysql-bin.index, saya menemukan baris kosong pertama.
Dalam kode sumber mysql rpl_master.cc:show_binlogs() Anda akan menemukan kode berikut:
/* The file ends with EOF or empty line */
sementara ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Baris kosong dianggap sebagai akhir dokumen
(Referensi.)https://yq.aliyun.com/articles/213657Artikel)
Tindakan pencegahan
Jangan menghapus binlog secara manual, jangan mengedit file mysql-bin.index secara manual, kecuali Anda tahu apa yang Anda lakukan, jika tidak, Anda mungkin meletakkan ranjau untuk diri Anda sendiri!
ringkasan
DBA perlu memperhatikan peningkatan binlog di setiap versi baru MySQL (seperti fitur gtid yang ditambahkan di versi 5.6, Enhanced Multi-threaded Slaves di versi 5.7), dan memahami arti dari setiap parameter secara rinci, sehingga mereka dapat mengetahui apa artinya ketika mereka mengalami kesalahan dan memecahkan masalah dengan mudah.
|
Diposting pada 25/09/2018 10.31.40
|
|
|
|
