Tam bir yeniden senkronizasyondan sonra neden bir bağımlı sunucuda 'PRIMARY anahtarı için yinelenen giriş' aldığımı anlamama yardımcı olur musunuz?

Temelde 'mysqldump' neredeyse bütün gece koşuyordu ve daha sonra geri yükleme işlemi birkaç saat sürdü, bu yüzden köle başladığımda ustanın ~ 63874 saniye gerisindeydi.

Slave sunucu salt okunur (salt okunur) ve yeniden eşitleme işlemi sırasında herhangi bir yazma yoktu, bu yüzden neden yinelenen anahtarlar olduğunu anlamıyorum.

İkili kayıt formatı master üzerinde MIXED olarak ayarlanmıştır.

DB yedekleme için kullanılan komut:

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

Slave, master'dan (db -> db_backup) yalnızca bir veritabanını aşağıdaki seçeneklerle çoğaltır:

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

GÖRÜNÜM 1: Çoğaltma

Ben öyle düşünmüyorum

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

birbirine ait.

Diğer insanlar da bunu merak etti

• Jun 14, 2012: MySQL çoğaltması yapılandırıldı ancak çalışmıyor
• Jun 13, 2012: MySQL çoğaltma sırasında 'replicate-rewrite-db' ve 'replicate-do-db' arasındaki fark nedir?
• May 31, 2012: Mysql çoğaltma-yeniden yazma-db çalışmıyor

Sorun, sipariş çoğaltma kurallarının işlenmesinden kaynaklanıyor. Çoğaltma Kuralları ile ilgili MySQL Belgelerine göre :

Herhangi bir --replicate-rewrite-db seçeneği belirtilmişse, --replicate- * filtreleme kuralları test edilmeden önce uygulanır.

Replicate-rewrite-db ile ilgili MySQL Belgeleri bile şöyle diyor:

Veritabanı adı çevirisi --replicate- * kuralları test edilmeden önce yapılır.

Yeniden replicate-wild-do-tableyazma işleminden sonra uygulanır. Bu siparişin bir şekilde zaten verileri olan bir tabloya bir INSERT koyması şaşırtıcı değildir.

Muhtemelen veriler oraya nasıl geldi?

GÖRÜNÜM 2: mysqldump

Bunu yapmak mysqldump --single-transaction, verilerin zaman içindeki dökümlerini belirlemenin en iyi yolu gibi görünmektedir. Ne yazık ki, mysqldump --single-transactionAşil Topuğu var ALTER TABLE. Bir tablo, mysqldump'ın dökümü yapmaya çalıştığı işlemin bütünlüğünü bozabilecek ALTER TABLEbir DROP TABLEve gibi komutlara maruz kalırsa CREATE TABLE. aynı zamanda yıkıcı da olabilir.

Bununla ilgili daha fazla bilgiyi MySQL Performans Blogunun En iyi saklanan MySQLDump Sırrı'nda bulabilirsiniz . Aslında bu noktayı mysqldump'ın işleminin bütünlüğünü bozabilecek 12 komutu açıklayan geçmiş bir soruda ele aldım: MySQL backup InnoDB

UYARI

• Şahsen, ikili formatı STATEMENT olarak değiştirirdim
• MySQL yedekleme InnoDB dediğim gibi , mysqldumps yapmaya adanmış başka bir köle (herhangi bir çoğaltma filtreleri olmadan) olmalıdır.
• 63000+ saniye geride mi? Paralel tablo dökümü yapmayı düşünmelisiniz: Büyük bir veritabanının mysqldump'ını nasıl optimize edebilirim?

SONSÖZ

Yönlerden biri veya her ikisi de, yeniden yazma kuralları veya geçersiz kılınmış mysqldump'ın izolasyonu nedeniyle var olmaması gereken mysqldump sırasında bir satır kaymasına izin vermiş olabilir.

ÖNERİLER

Köle işleyecek tüm INSERT'leri görmek ve bu satırların Köle üzerinde zaten var olup olmadığını görmek için mysqldump başından beri tüm röle günlükleri bir mysqlbinlog dökümü yapmak istiyorum. Eğer yaparlarsa, muhtemelen iki şey yapabilirsiniz:

1: Yinelenen Anahtar hatalarının tümünü atla

Bunu Köle üzerindeki my.cnf dosyasına eklemeniz yeterli

[mysqld]
slave-skip-errors=1062
skip-slave-start

ve mysql'yi yeniden başlatın. O zaman koşSTART SLAVE;

tüm yinelenen anahtar hataları atlanır. Ne zaman Seconds_Behind_Master0'a alır, bu satırları ve yeniden başlatma mysql çıkarın.

2: Percona araçlarını indirin

İhtiyacınız olan araçlar

• pt-sofra sağlama
• pt-masa senkronize

Slave'deki farklılıkları bulmak için bunları kullanın ve ardından düzeltin

Doğrudan slave'e eklenen kodda ekleme sorgusu olup olmadığını kontrol edin. Sadece köleden okuyabiliriz. Yazma sorguları master'a yönlendirilmelidir.