MySQL yüksek erişilebilirlik mimarislerinde, birincil veritabanı çoğaltması çok yaygın bir türdür.
Birincil veritabanı çöktüğünde, hizmet erişilebilirliğini sağlamak için bir köle veritabanını yeni birincil veritabanı olarak yükseltebilirsiniz. Aynı zamanda, tüm kümenin QPS'si köle kütüphanesini genişleterek geliştirilebilir.
Master-slave replikasyon mimarisi altında, MySQL binlog kullanarak master-slave veri tutarlılığını sağlar.
Yukarıdaki şekilde gösterildiği gibi, MySQL master-slave replikasyonu esas olarak aşağıdaki adımlardan oluşur
1. Ana Kayıt Kayıtları ikili günlükteki değişiklikleri kaydeder
2. Slave io_thread ana kütüphanenin binlogunu talep eder ve ortaya çıkan binlog logunu röle günlüğüne yazar
3. Köle sql_thread röle günlüğündeki olayları tekrar yap
MySQL master-slave replikasyonu için bir bağlantı olmasının yanı sıra, binlog başka amaçlara da hizmet eder. Mesela ne:
1. Mysqlbinlog aracını kullanarak binlog dosyasını ayrıştırarak noktada veritabanı kurtarma gerçekleştirin.
2. Binlog olaylarına dayalı veritabanının geri dönüşü (MariaDB doğrudan mysqlbinlog'u flashback için kullanabilir)
3. Github'un açık kaynaklı çevrimiçi tablo değiştirme aracı gh-ost da binlog üzerinden uygulanıyor
4. Ayrıca binlogları ayrıştırarak kademeli olarak abone olabilir ve tüketebilirsiniz
Binlog çok faydalıdır, ancak günlük işletme ve bakım sürecinde bazı sorunlarla karşılaşmanız kaçınılmazdır. İşte binlog ile ilgili bazı hatalar.
Sıkça sorulan sorulardan biri
Fenomen
mysqlbinlog5.5, mysql5.7 binlog dosyasını ayrıştırıyor
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.
Neden analizi
MySQL 5.6 ve diğer üst düzey binlog dosyaları sürümleri, GTID olayları gibi yeni binlog olayları eklemiştir.
MySQL5.5'teki mysqlbinlog bu tür binlog olaylarını tanımıyor.
Çözüm
Mysqlbinlog'un alt sürümü tarafından oluşturulan binlogu çözmek için daha yüksek sürümünü kullanın
Sıkça Sorulan İkinci Soru
Fenomen
Sağlıklı bir mysql sunucusu köle durumunu gösteriyor
Last_SQL_Error:Relay log okuma hatası: Röle log olay girişini ayrıştıramadı.
Olası nedenler şunlardır: ana bilgisayarın ikili logu bozulmuş (bunu ikili logda 'mysqlbinlog' çalıştırarak kontrol edebilirsiniz),
Slave'nin röle logu bozulmuş (bunu röle günlüğünde 'mysqlbinlog' çalıştırarak kontrol edebilirsiniz),
bir ağ sorunu ya da ana veya kölelerin MySQL kodunda bir hata olabilir.
Eğer master'ın ikili logunu veya kölenin röle günlüğünü kontrol etmek isterseniz,
Bu köle üzerinde 'KÖLE STATÜSÜ' işareti vererek isimlerini öğrenebilirsiniz.
Neden analizi
Röle günlüğündeki kayıtlar, ana kütüphanedeki binlog hataları, slave kütüphanedeki röle logu hataları veya ağ sorunları ve hataları nedeniyle okunamaz. Genellikle ağ arızası veya slave kütüphanesi üzerindeki aşırı baskı nedeniyle yanlış bir röle-log formatına yol açar.
Çözüm
Mevcut senkronizasyon zaman noktası bulunduktan ve master-slave senkronizasyonu sıfırlandıktan sonra, yeni bir röle logu oluşturulur ve master-slave senkronizasyonu yeniden sağlanır.
"Show slave status\G" çıktısından aşağıdaki bilgileri bulabilirsiniz:
Relay_Master_Log_File: mysql-bin.002540 // Slave kütüphanesi tarafından okunan master'in binlogExec_Master_Log_Pos: 950583017 // Slave üzerinde yürütülmüş pozisyon konum noktası
Slave'i durdurun ve senkronizasyonu, slave'nin okuduğu binlog dosyasından ve çalıştırılan konumdan başlayarak tekrar ayarlayın.
Relay_Master_Log_File: mysql-bin.002540 // Slave kütüphanesi tarafından okunan master'in binlogExec_Master_Log_Pos: 950583017 // Slave üzerinde yürütülmüş pozisyon konum noktası
Sıkça Sorulan Üç Soru
Fenomen
Durdurma hatası sonrası köle durumunu göster durumunu geri getir:
Last_SQL_Error: Röle log pozisyonunu başlatma hatası: I/Q hatası başlığı ikili logdan okuma hatası
Last_SQL_Error: Röle log pozisyonunu başlatma hatası: Binlog'un sihirli sayısı kötü; Bu MySQL sürümü tarafından kullanılabilecek ikili bir log dosyası değil
Neden analizi
Elektrik kesintisi, anakart yanması gibi kesintiler veya yasa dışı kapatma gibi durumlar röle kutusu dosyasının bozulmasına neden olur
Çözüm
Aynı soru ikinci.
relay_log_recovery = 1 de ayarlanabilir.
Slave kütüphaneden düştüğünde, röle günlüğü bozulursa ve aktarma günlüğünün bir kısmı işlemezse, röle günlüğü otomatik olarak terk edilir ve günlüğü ana bilgisayardan geri alınır, böylece röle günlüğünün kurtarılması tamamlanır.
Sıkça Sorulan Dört Soru
Fenomen
Master değiştirildiğinde kütüphane makinesinden yeniden başlatma işlemi devreye girdiğinde ortaya çıkıyor
Hata (Kod 1201): Ana bilgi yapısı başlatılamadı; daha fazla hata mesajı MySQL hata günlüğünde bulunabilir
veya
ERROR 1872 (HY000): Slave, depodan röle log bilgi yapısını başlatmayı başaramadı
Neden analizi
Elektrik kesintisi, anakart yanması gibi kesintiler veya yasa dışı kapatma gibi durumlarda master.info veya realy-log.info dosyalarına zarar verilmesi
Çözüm
köle> köleyi sıfırla, master değiştir
Önleyici önlemler
Profil ayarları
relay_log_info_repository=tablo
master_info_repository=tablo
MySQL 5.6.5 mysql.slave_master_info ve mysql.slave_relay_log_info depolama motoru varsayılan olarak MyISAM olarak ayarlanmış ve bunu InnoDB'nin depolama motoruna çevirmeniz gerekir
DEĞIŞTIR TABLO mysql.slave_master_info ENGINE=InnoDB;
DEĞIŞTIR TABLO mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tablo sync_master_info etkinliklerden sonra güncellenecektir.
mysql.slave_relay_log_info tablo her işlem taahhüdüyle güncellenecektir.
Sıkça Sorulan Soru 5
Fenomen
Ana köle, ana veritabanı binlog_format satıra çevrildikten sonra ana binlog_format bir ifade olarak bir ifade , kütüphaneden köle durumu gösteri görünür:
Last_Error: Satır etkinliği çalıştırılan hata hatası : 'Statement çalıştırılamaz: ifade satır formatında olduğu için ikili log'a yazmak imkansızdır ve BINLOG_FORMAT = STATEMENT.'
Neden analizi
Ana veritabanı binlog_format sıra ve köle kütüphane binlog_format ifadesi olduğunda, yukarıdaki hata ortaya çıkar.
Ama ana kütüphane binlog_format ifade, köle kütüphanesi ise binlog_format sıra;
Ya da ana veritabanı binlog_format satırsa, veritabanı binlog_format karıştırılsa hata bildirilmez.
Eğer SQL iş parçacığınız gerçekten şu şekilde yapılandırılmışsa
binlog_format=STATEMENT bir ROW olayı aldığında durur. The
nedeni, o ROW olayını STATEMENTformat'ta kaydedememesi (bazen buna ROW enjeksiyonu olarak adlandırılır, bu ya
BINLOG ifadesi veya slave'nin SQL iş parçacığı tarafından yürütülen bir ROW olayı)
Detaylı sebep referansı:https://bugs.mysql.com/bug.php?id=69095
Çözüm
KÖLE> KÖLE DUR;
KÖLE> KÜME KÜRESEL binlog_format=KARIŞTIRILDI;
KÖLE> BAŞLA KÖLE;
Sıkça Sorulan Soru 6
Fenomen
mysql5.6'yı mysql5.5'e senkronize ederken hata
Last_IO_Error: İkili logdan veri okurken master'dan ölümcül hata 1236 aldım: 'Slave, o master'in loglamak için yapılandırıldığı kontrol toplamı ile replikasyon olaylarını işleyemiyor; İlk etkinlik 'MySQL-bin.000001' 4'te, son etkinlik 'MySQL-bin.000001'den 120'de, son bayt ise 'MySQL-bin.000001'den 120'de okundu.
Neden analizi
Ana sunucuda çalışan SQL ifadelerinin sunucuda çalışan SQL ifadeleriyle (etkinlik bozulması olarak adlandırılır) yazılım ve donanım veya ağ iletim hataları nedeniyle tutarsız olması sorununu çözmek için MySQL 5.6 Replikasyon Olay Kontrol Toplamı fonksiyonunu ekler. Bir olay ikili loga yazıldığında, kontrol toplamı da ikili loga yazılır ve olay ağ üzerinden köleye iletildikten sonra, kölede doğrulanır ve kölenin röle günlüğüne yazılır. Her adımda olaylar ve kontrol toplamları kaydedildiği için, sorunun ne olduğunu hızlıca çözebiliriz.
mysql5.6.5 ve daha sonraki sürümlerde binlog_checksum varsayılan değer crc32 ise,
Önceki sürümde varsayılan değer binlog_checksum hiç yoktu
çözüm
Köle> kümeler küresel binlog_checksum=yok
Sıkça Sorulan Soru 7
Fenomen
Disk dolduktan sonra, binlog dosyasını ve mysql-bin.index dosyasını manuel olarak temizleyin
Show binary log'ları boş, ama show master statüsü normal.
mysql> ikili logları gösterir; Boş set (0.00 saniye)mysql> ana statüsünü göster;
+------------------+-----------+--------------+------------------+
| Dosya | Pozisyon | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Neden analizi
mysql-bin.index dosyasını kontrol ettikten sonra ilk boş satırı buldum.
Mysql kaynak kodunda rpl_master.cc:show_binlogs() aşağıdaki kodu bulacaksınız:
/* The file ends with EOF or empty line */
while ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Boş satırlar belgenin sonu olarak kabul edilir
(Referans.)https://yq.aliyun.com/articles/213657Makale)
Önleyici önlemler
Binlog'u manuel olarak silmeyin, mysql-bin.index dosyasını manuel olarak düzenlemeyin, ne yaptığınızı biliyorsanız, aksi takdirde kendiniz için mayın koymuş olabilirsiniz!
özet
DBA'lar, her yeni MySQL sürümünde binlog'daki iyileştirmelere dikkat etmelidir (örneğin sürüm 5.6'da eklenen gtid özelliği, 5.7 sürümünde Enhanced Multi-threaded Slaves) ve her parametrin anlamını ayrıntılı olarak anlamalıdır; böylece hatalarla karşılaştıklarında ne anlama geldiklerini anlayıp sorunları kolayca çözebilirler.
|
Yayınlandı 25.09.2018 10:31:40
|
|
|
|
