g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

MySQL çoğaltma en iyi uygulaması

Makale daha uzun, lütfen yavaşça tadını çıkarın

Makale özeti

Genel bakışı kopyala 1.1. Çoğaltmanın temel kavramları 1.2. Ortak çoğaltma yapısı 1.3. Master-slave çoğaltma ilkesi 1.4. Master-slave çoğaltma modu

En iyi uygulamaları kopyalayın 2.1. Çift ana çoğaltma dağıtımı 2.2. Dağıtım ve basamaklı çoğaltma dağıtımı 2.3. Kademeli yapının dağıtımı ve ayarlanması 2.4. Yaygın hata işlemeyi kopyalayın

Filtre uygulamasını kopyala 3.1. Kopyalama Parametrelerine Giriş 3.2. Filtreleme için en iyi uygulamaları kopyalayın 3.3. Kopyalama durumu ve gecikme izleme

Yarı eşzamanlı çoğaltma 4.1. Yarı eşzamanlı çoğaltma ilkesi 4.2. Yarı eşzamanlı çoğaltma için en iyi uygulamalar

1. Genel bakışı kopyala

MySQL'in yerleşik çoğaltma işlevi, büyük, yüksek performanslı uygulamalar oluşturmak için temel oluşturur. MySQL verilerini birden fazla sisteme dağıtın Bu dağıtım mekanizması, belirli bir MySQL ana bilgisayarının verilerini diğer ana bilgisayarlara (slave'ler) kopyalayıp yeniden çalıştırarak gerçekleştirilir. Çoğaltma işlemi sırasında, bir sunucu ana sunucu olarak davranır ve diğer bir veya daha fazla sunucu ikincil sunucu olarak çalışır. Ana sunucu, güncellemeleri bir ikili günlük dosyasına yazar ve günlük döngülerini izlemek için dosyanın bir dizinini tutar. Bu günlükler, ikincil sunucuya gönderilen güncellemeleri kaydedebilir. Bir ikincil sunucu ana sunucuya bağlandığında, ana sunucuya ikincil sunucu tarafından günlükte okunan son başarılı güncellemenin yerini bildirir. Bağımlı sunucu, o zamandan beri gerçekleşen tüm güncellemeleri alır, ardından ana sunucunun yeni güncellemeyi bildirmesini engeller ve bekler.

1.1. Çoğaltmanın temel kavramları

Çoğaltma yaptığınızda, çoğaltılmış tablolardaki tüm güncellemelerin birincil sunucuda gerçekleştirilmesi gerektiğini lütfen unutmayın. Aksi takdirde, ana sunucudaki tablolara yapılan kullanıcı güncellemeleri ile ikincil sunucudaki tablolara yapılan güncellemeler arasında çakışmaları önlemek için dikkatli olmalısınız.

Çoğaltmanın temel kavramları

Replikasyon tek yönlüdür, sadece Master'dan Slave'e
Bir dizi çoğaltma yapısında birden fazla Slave olabilir, ancak Master genellikle yalnızca birini önerir
Mster tarafı verileri yazar, bir olay oluşturur ve bunu ikili günlüğe kaydeder, Dump iş parçacığı işlemi olayı okur ve slave'e iter ve son olarak slave uygulanır.

Çoğaltma ile çözülen sorunlar

Ana kütüphanenin okuma basıncını azaltmak için ikincil kütüphaneyi kullanın (okuma ve yazma ayrımı)
Ana hatayı devralmak için bağımlı kitaplığı kullanın (yüksek kullanılabilirlik)
İşletme üzerindeki etkiyi azaltmak için veritabanı yedeklemesini ve diğer bakım çalışmalarını kullanın (işletim ve bakım yönetimi)
Sorunsuz bir şekilde geçiş yapmak ve yükseltmek için yardımcı kitaplığı kullanın (sürekli yükseltme)
Veri analizi ve istatistikler (BI ve diğer veri aboneliği) kütüphaneden kullanılabilir
Uzaktan felaket kurtarma (veri artıklığı felaket kurtarma) yapmak için bağımlı veritabanını kullanın

1.2. Ortak çoğaltma yapısı

1.3. Master-slave çoğaltma ilkesi

Master-slave kopyalama prensibi

Master, ikili günlüğü kaydeder. Her işlem güncelleme verisi tamamlanmadan önce, ana makine bu değişiklikleri ikinci günlüğe kaydeder. MySQL, işlemdeki ifadeler dönüşümlü olarak çalıştırılsa bile işlemi ikili günlüğe seri olarak yazar. Olay ikili günlüğe yazıldıktan sonra, ana birim depolama motoruna işlemi gerçekleştirmesi için bildirimde bulunur.
Slave, bir çalışan iş parçacığı başlatır: IO_thread. IO_thread, ana bilgisayarda normal bir bağlantı açar ve ardından binlog döküm işlemini başlatır. Binlog döküm süreci, ana birimin ikili günlüğünden olayları okumaktan ve bunları IO_thread'e itmekten sorumludur.Master ile devam etmişse, uyuyacak ve yöneticinin yeni olaylar oluşturmasını bekleyecektir. G / Ç iş parçacığı bu olayları röle günlüğüne (Relay_log) yazar.
SQL_thread, röle günlüğünden olayları okur ve ana verideki verilerle tutarlı hale getirmek için ikincil verileri güncellemek için olayları yeniden oynatır. İş parçacığı G / Ç iş parçacığı ile tutarlı olduğu sürece, röle günlüğü genellikle işletim sistemi önbelleğinde bulunur, bu nedenle röle günlüğünün ek yükü küçüktür.

Lütfen düşünün: 1. Bu çoğaltma yapısı eşzamanlı mı yoksa eşzamansız mı? 2. Çoğaltma yapısındaki hangi bağlantı performans darboğazlarına eğilimlidir?

SQL Thread uygulama süreci (SATIR biçimi)

Mevcut olaya dahil olan tablonun birincil anahtarı olup olmadığını kontrol edin ve varsa verileri birincil anahtara göre güncelleyin
Geçerli olaya dahil olan tablonun ikincil bir dizini olup olmadığını kontrol edin. Varsa, ikincil dizine göre birincil anahtarı bulun ve verileri birincil anahtara göre güncelleyin.
Geçerli olaya dahil olan tabloda birincil anahtar veya ikincil dizin yoktur. SQL_thread uygulamasının bu seferki davranışı tam bir tablo taramasıdır

1.4. Master-slave çoğaltma modu

MySQL, 5.6'dan önce geleneksel bir replikasyon yöntemiydi. Tek fark, kaydedilen ikili günlük formatının farklı olması, ancak 5.6'dan sonra yepyeni bir replikasyon modu, yani GTID modu ortaya çıktı, bir bakalım. (Bir master ve slave yapılandırın, ikili günlük formatını tek tek açıklayın)

Çoğaltma modunda, geleneksel çoğaltma herhangi bir günlük biçimine dayanabilir, ancak yeni GTID modunda çoğaltma yalnızca aşağıdaki şekilde gösterildiği gibi satır biçimine dayalı olabilir: (günlük biçimi nedir? Aslında, olayın ikili günlüğe yazıldığı biçimdir)

Geleneksel model a) Bildirim biçimi (SBR) b) satır biçimi (RBR) c) karışık format (MIX)
GTID modu a) satır biçimi

ikili günlük biçimi

ifade biçimi (SBR) İlgili parametreler: binlog_format = 'ifade' avantaj: a) Binlog'a yazılan dosyanın içeriği küçüktür b) Günlük, kullanıcı tarafından yürütülen ve istatistik ve denetim için uygun olan SQL'i içerir. c) Önceki binlog daha iyi uyumluluğa sahiptir d) binlog'un okunması ve onarılması kolaydır Dezavantajları: a) mysql functions uuid (); user (); sysdate () kullanıcı tanımlı fonksiyonlar gibi veri tutarsızlığına neden olacak güvenlik riskleri vardır ...
satır biçimi (RBR) İlgili parametreler: binlog_format = 'satır' avantaj: a) İfadeden daha güvenli bir kopyalama biçimi b) Bazı senaryolarda çoğaltma hızı daha hızlıdır (SQL karmaşıktır, tablonun birincil anahtarı vardır) c) mysql özel fonksiyonları kopyalanabilir d) Daha az kilit Dezavantajları: a) İkili günlük nispeten büyüktür (satır biçimi kayıt sonuç kümesi) b) Tek bir SQL değişim tablosundaki çok fazla satır, çok sayıda binlog oluşturacaktır c) Kullanıcının yürüttüğü sql binlog'dan görülemez d) DDL ifadesi kayıtları aynı zamanda ifade format kayıtlarıdır limit: a) MySQL günlük formatını satır olarak ayarlarsa, izolasyon seviyesi sadece: READ-COMMITTED olabilir
karışık format (MIX) İlgili parametreler: binlog_format = 'karışık' karakteristik: a) Satır ve ifade formatlarının karışık kullanımı: DDL kayıtları için, ifade formatı kullanılacak; tablodaki satır işlem kayıtları için, özel koşullar tetiklendiğinde varsayılan ifade formatı satır formatına dönüştürülecektir; b) Innodb tabloları kullanıyorsanız, READ COMMITTED veya READ UNCOMMITED günlük seviyesini kullanan işlem seviyesi sadece satır formatını zorlayabilir. c) Ancak satır biçimi kullanılırken, DDL ifadeleri yine de ifade biçiminde kaydedilecektir. Anahtarlama koşulları: Karma mod, aşağıdaki durumlar otomatik olarak binlog modunu SBR modundan RBR moduna geçirir a) Bir DML ifadesi bir NDB tablosunu güncellediğinde b) İşlev, uuid () içerdiğinde c) auto_increment alanlarını içeren 2 veya daha fazla tablo güncellendiğinde d) Herhangi bir gecikmeli ifade ekleme e) Kullanıcı tanımlı işlevleri kullanırken (Kullanıcı Tanımlı İşlev-udf) f) Görünümde RBR'nin gerekli olması gerektiğinde, örneğin görünümü oluşturmak için uuid () işlevi kullanıldığında

Geleneksel kopyalama modu

İlgili parametreler log_bin = on binlog_format = Hiç
Açıklama Varsayılan olarak, iki parametre yapılandırıldığı sürece, replikasyon yapısında geleneksel replikasyondur ve geleneksel replikasyon tüm log formatlarıyla uyumludur.
En İyi Uygulamalar Farklı binlog formatlarının geleneksel kopyalamayı ve ayrıştırmasını gösterin a) Geleneksel çoğaltmayı dağıtın b) İfadeyi, satırları, karışık günlük formatlarını ve çıktı bilgilerinin yorumlanmasını analiz edin

GTID çoğaltma modu

Geleneksel çoğaltma modunda, ana-bağımlı anahtarından sonra ilgili bin günlük dosyasını ve konumunu bulmanız ve bu bilgiye dayalı olarak yeni ana veritabanına işaret etmeniz gerekir.Çalışma ve bakım veya DBA'larda çok deneyimli olmayanlar için sık sık hatalar meydana gelir. Ana kitaplık eşitleme hatasına neden olur. GTID'nin ortaya çıkışı bu sorunu büyük ölçüde çözdü.

İlgili parametreler log_bin = on binlog_format = 'satır' gtid_mode = on zorunlu-gtid-tutarlılık = açık log-slave-güncellemeleri = 1
gtid'e genel bakış 1.mysql-5.6.2 desteği, mysql5.6.10'dan sonra mükemmel. 2. Bir işlem, benzersiz bir kimliğe karşılık gelir 3. Bir gtid, bir sunucuda yalnızca bir kez yürütülecektir 4.gtid, geleneksel klasik kopyalama yönteminin yerini almak için kullanılır
Gtid bileşimi server_uuid: sıra numarası ,Gibi: 404fba33-a7d3-11e5-93e2-a0369f7c3c3c: 1-536246774

Her sıra numarası bir işlemi temsil eder, tabii ki işlem bir veya daha fazla DML içerebilir server_uuid şundan gelir: datadir Katalog auto.cnf Dosyanın resmi olarak değiştirilmesi tavsiye edilmez, ancak MySQL örneği başladıktan sonra silinebilir.MySQL örneği başlatıldıktan sonra otomatik olarak oluşturulur (Master's DB, kendiniz için heyecan bulmayın)

Gtid'in avantajları 1. Dağıtılmış çoğaltma senaryosunda, master çalışmadığında ve slave'ler arasında bir gecikme olduğunda slave'ler arasında veri kaybı olabilir. 2. Basamaklı çoğaltma senaryosunda, dağıtım kölesi çalışmadığında, sonraki köle veri kaybetmeden herhangi bir düğüme sorunsuz bir şekilde değişir
gtid sınırlamaları 1. İşlemsel olmayan motorlar desteklenmez (kitaplıktan hata, bağımlı birimi durdur; bağımlı birimi başlat; yok say) 2. Tablo oluştur ... select deyimi desteklenmiyor (ana kitaplık doğrudan bir hata bildiriyor) 3. Bir işlem motorunun ve işlem olmayan bir motorun tablolarını aynı anda güncellemek için bir SQL desteklemez 4. Bir çoğaltma grubunda, gtid'i açmak veya gtid'i kapatmak gerekir 5. gtid'i açmak yeniden başlatmayı gerektirir 6. gtid'i açtıktan sonra, orijinal geleneksel kopyalama yöntemi kullanılmaz 7. Geçici tablo oluşturma ve geçici tablo ifadelerini bırakma desteği yok 8. sql_slave_skip_counter desteklenmiyor
En İyi Uygulamalar GTID'nin iki replikasyon dağıtım yöntemini gösterin: a) Yeni GTID ortamında ana-bağımlı çoğaltma dağıtımı b) GTID ortamında master-slave replikasyon dağıtımı çalıştırıldı

2. En iyi uygulamaları çoğaltın

İkili ustanın kusurları

Çift ana senaryoda, tek taraflı yazılmalıdır (her iki taraf da verileri aynı anda değiştirdiğinde, veriler tutarsız olacaktır)
İki işletme çift yönetici kullansa bile, her iki işletmenin de aynı veritabanına aynı anda erişmesi gerekir (kopyalama çakışmaları önlendiğinde sorun çözülemez)
Efsaneye göre, eski zamanlarda birisi her durumu ayarlamayı önerdi auto_increment_offset ile auto_increment_increment Parametre, çakışma yazma sorununu ortadan kaldırır, ancak çok fazla dizi israfına neden olur.

Dual master'ın gerçekleştirilmesi

Önce basit bir ana-bağımlı çoğaltma yapısını uygulayın
Master1'de yürütülen olaydan nasıl kaçınılır ve yanıttan sonra da master2'de binlog'a nasıl yazılır. Şu anda, master1'in döküm iş parçacığı da binlog olayını IO Thtread'e itecektir. Bu sorunu çözmenin yolu: Sunucu kimliği
Master2'deki tüm veri değişiklikleri master1 tarafından üretildiğinden, master2'ye veri yazılmadığı sürece, ofseti istediğiniz zaman alın
Nihayet master2'de ana durumu göster çıkagelmek Binlog Dosyası Hem de Binlog Konumu değişiklik

sorun: 1. Çift taraflı yazma sırasında dağınık veri sorunu GTID ortamında çözülebilir mi? 2. Dairesel çoğaltma yapısında, ana birim yürüttüğü olayları tekrar edecek mi? 3. Master1 neden master2'deki herhangi bir şeyi doğrudan değiştirebilir? Binlog Dosyası Hem de Binlog Konumu

Çift Master için En İyi Uygulamalar

Gerekli parametreler

log_bin röle günlüğü binlog-biçimi server_id günlük-bağımlı-güncellemeleri gtid_mode # 5.7 Kopyalamadan sonra parametrelerden önce açılmalıdır zorla-gtid-tutarlılığı

usta11. Bir kopya hesabı oluşturun 2. Veritabanını yedekleyin ve yedeklemeyi master2 ana bilgisayarına aktarın

mysql > çoğaltma bağımlısı, çoğaltma istemcisi üzerinde *. * to'repl'192.168.5. @ '%', 'mycat' ile tanımlanır; mysql > flush ayrıcalıkları; # mysqldump -S /data1/db16000/my16000.sock -u root -p --single-transaction --master-data = 2 -A > /tmp/full_16000_dump.sql# scp /tmp/full_16000_dump.sql 192.168.5.192:/tmp

usta21. Veritabanını geri yükleyin ve konumu bulun 2. Slave'i dağıtın ve replikasyon durumunu kontrol edin 3. Mevcut binlog konumunu görüntüleyin

# mysql16000 < /tmp/full_16000_dump.sql# Master1 binlog dosyasını analiz edin, konum # head -50 /tmp/full_16000_dump.sql | grep CHANGEmysql of full_16000_dump.sql > master'ı master_host = '192.168.5.191', master_port = 16000, master_user = 'repl', master_password = 'mycat', master_log_file = '519116000-bin.000004', master_log_position = 356; mysql > köle başlat; mysql > köle durumunu göster \ Gmysql > ana durumu göster \ G

usta1 mater1, çift ana çoğaltma elde etmek için master2'nin kölesi görevi görür

mysql > master'ı master_host = '192.168.5.192', master_port = 16000, master_user = 'repl', master_password = 'mycat', master_log_file = '519216000-bin.000003', master_log_pos = 504; mysql > köle başlat; mysql > köle durumunu göster \ G;

2.2. Dağıtım ve basamaklı çoğaltma dağıtımı

Dağıtım kopya yapısı

Uygulama prensibi

Ana birim bir çoğaltma hesabı oluşturur, veritabanını yedekler ve yedekleme setini diğer bağımlı kitaplıklara aktarır
Slave1, slave2 veritabanını, binlog dosyası, konum veya gtid Veritabanını geri yükle
Slave1, slave2 ana kitaplığa geçiş yapın, dağıtımı tamamlayın

Basamaklı çoğaltma yapısı

Uygulama prensibi

Ana birim bir çoğaltma hesabı oluşturur, veritabanını yedekler ve yedekleme setini diğer bağımlı kitaplıklara aktarır
Slave1, slave2 veritabanını geri yükle
Veritabanı slave'ler arasında geri yüklendiğinde, slave1 mevcut binlog dosyası, konum bilgi
slave2, slave1'e dayanır binlog dosyası, konum Bilgi köle1'e değişir ve köle1'in kölesi olur
slave1, yedeklemedeki master'ı temel alır binlog dosyası, konum Ana1'e bilgi değişikliği, tam kademeli çoğaltma

2.3. Kademeli yapının dağıtımı ve ayarlanması

2.3.1. Yapı düzenleme senaryosu 1'i kopyala

Gerçekleşme fikri

Tüm slave'lerin aynı pozisyonda durmasına izin verin, slave1 kendi Binlog Dosya Pozisyonunu alır
Slave1'in konumuna bağlı olarak, slave2, slave1'e dönüşür ve slave1'in slave'i olur.
Şu anda, köle2 köle1'in kölesidir, ancak ana ve köle1'in kopyalanması kesintiye uğrar
Daha önce ana makine ile aynı konumda duran hatayı düzeltin, ana ile çoğaltma ilişkisini geri yükleyin

Problem: İki slave bırakma tablosunun zaman noktaları tutarsız, Master masayı düşürdüğünde, slave'lerin aynı pozisyonda olmadığı anlamına geliyor.

En İyi Uygulamalar

usta1 Ana kütüphane bir bayrak tablosu oluşturur

mysql > tablo t_slave_stop (id int) oluştur;

köle1 Bayrak tablosunu sil

tabloyu bırak t_slave_stop;

köle2 Slave'lerin aynı anda drop tablosu olmadığını belirtmek için, master'ın verileri yazması ve bayrak tablosunu silmesi en iyisidir.

tabloyu bırak t_slave_stop;

usta1 Ana bırakma tablosu maddesi, ikincil öğelerin aynı konumda olmasını tetikler

mysql > tabloyu bırak t_slave_stop;

köle1

mysql > ana durumu göster \ G;

salve2 Slave verilerine dayalı statik ikili günlük dosyası ile durum , Geçmişi değiştir

mysql > köleyi durdur; mysql > master'ı master_host = '10 .209.5.192 ', master_port = 16000, master_log_file =' 519216000-bin.000003 ', master_log_pos = 3638 olarak değiştirin; mysql > köle başlat; mysql > köle durumunu göster \ G

köle1 Ana ile çoğaltma ilişkisini onarın ve köle2, köle1'in verilerini çoğaltır, böylece köle2'nin ilgilenmesine gerek kalmaz

mysql > köleyi durdur; mysql > tablo t_slave_stop (id int) oluştur; mysql > köle başlat; mysql > köle durumunu göster \ G

2.3.2. Yapı düzenleme senaryosu 2'yi kopyala

Gerçekleşme fikri

Bağımlı1, ana birim ile çoğaltma ilişkisini durdurur Bağımlı2'nin ikincil1 ile gecikmesi varsa, gecikmiş verilerin yakalanmasını bekler.
Slave1 ve slave2 veri yansıtılır, bu nedenle slave2, slave1'i ifade eder köle durumunu göster Bilginin ustaya değiştirilmesi ( Relay_Master_Log_File , Exec_Master_Log_Pos )
Slave1, ana ile çoğaltma ilişkisini başlatır, yapısal ayarlamayı tamamlar

En İyi Uygulamalar

köle1 Slave çoğaltmayı durdurun ve slave2 çoğaltmasının gecikmiş verilerinin eşitlenmesini bekleyin

mysql > köleyi durdur; mysql > köle durumunu göster \ G;

köle2 Köle bazında1 köle durumunu göster \ G Sql Konu çalma binlog dosyası ile binlog konumu geçmişi değiştir

mysql > köleyi durdur; mysql > master'ı master_host = '10 .209.5.191 ', master_port = 16000, master_user =' repl ', master_password =' mycat ', master_log_file =' 519116000-bin.000005 ', master_log_pos = 2961 olarak değiştirin; mysql > köle başlat; mysql > köle durumunu göster \ G;

köle1 Ana ile çoğaltma ilişkisini geri yükleyin

mysql > köle başlat; mysql > köle durumunu göster \ G;

2.4. Yaygın hata işlemeyi kopyalayın

2.4.1. Konfigürasyon sınıfının hata yönetimi

2.4.1.1. IO_Thread ana kitaplığa erişemiyor

Last_IO_Errno: 2003 Last_IO_Error: master'replica@192.168.5.191: 16001'-retry-time: 60 yeniden deneme: 1'e bağlanma hatası

En yaygın replikasyon problemi, ana kütüphanenin ip, port, kullanıcı adı, şifre ve izinlerinin doğru olup olmadığını kontrol edin; ana kütüphanede bir güvenlik duvarı ve diğer temel bağlantılar olup olmadığı

2.4.1.2. Tutarsız ana ve bağımlı alan türleri

Last_SQL_Errno: 1677 Last_SQL_Error: table'test.t 'sütun 1, type'int'den type'bigint (20)' türüne dönüştürülemez

Ana ve bağımlı veritabanı alanlarını tutarlı olacak şekilde değiştirin
Kütüphaneden parametreler aracılığıyla kayıplı veri türü dönüştürme desteği slave_type_conversions Yapılandırma, bu parametrenin üç seçeneği vardır: a) ALL_LOSSY : Yalnızca kayıplı dönüşümü destekleyin, kayıplı nedir? Örneğin, bir değer ilk olarak bigint'te 9999999999999 olarak saklanmıştı, ancak şimdi int türüne dönüştürüldüğünde kesilecek ve bu da tutarsız verilere yol açacaktır. b) ALL_NON_LOSSY : Yalnızca kayıpsız dönüştürmeyi destekler ve yalnızca kayıpsız koşullarda dönüştürülebilir c) ALL_LOSSY, ALL_NON_LOSSY : Hem kayıplı hem de hesaplama dönüşümü desteklenmez Not: Yukarıda belirtilen durumlar yalnızca binlog_format = ROW olduğunda geçerlidir.

2.4.1.3. MyISAM tablosu bozulması

Last_SQL_Errno: 1194 Last_SQL_Error: Error'Table'traincenter 'kilitlendi olarak işaretlendi ve sorguda onarılması gerekiyor. Varsayılan veritabanı:' basketballman '. Sorgu:' traincenter ayar noktalarını güncelle = '4', pointstime = '1361912066' burada uid = '1847482697' limit 1 '

Myisam masa traincenter hasarlı, sadece masayı doğrudan onarın. Innodb'nin MyIASM tablo veri güvenliğine göre avantajları: 1. Innodb çift yazma mekanizmasına sahiptir, hasarlı veya yarım yazma sayfaları onunla geri yüklenebilir 2. Innodb bir işlem motorudur, tüm işlemler işlemseldir ve myisam işlem dışıdır, yarı yazma vardır ancak işlem sonlandırılır.

2.4.1.4. Bağımlı kitaplık, ana kitaplığın bin-günlüğünü bulamıyor

Last_IO_Errno: 1236 Last_IO_Error: İkili günlükten veri okurken ana bilgisayardan önemli hata 1236 var: 'İkili günlük dizin dosyasında ilk günlük dosyası adı bulunamadı'

Ana kitaplıktaki binlog dosyası artık mevcut değil veya dizin dosyası dosyası değiştirilmiş; yaygın hata senaryoları: Hatanın nedeni, çoğaltma kesinti süresinin çok uzun olması ve kimsenin alarmla ilgilenmemesidir.Bu kesinti süresi, ana birimdeki binlog sona erme süresini aşıyor. Çoğaltmaya devam etmek için gereken binlog, sona erme tarihi nedeniyle silindiğinde, bu örneği yeniden oluşturmanın bir yolu yoktur.

2.4.1.5. Sunucu kimliği çakışması

Last_IO_Errno: 1593 Last_IO_Error: Önemli hata: Ana ve ikincil öğenin eşit MySQL sunucu kimliklerine sahip olması nedeniyle ikincil G / Ç iş parçacığı durur; bu kimlikler çoğaltmanın çalışması için farklı olmalıdır (veya - replicate-same-server-id seçeneği slave üzerinde kullanılmalıdır ancak bu her zaman mantıklı değildir; lütfen kullanmadan önce kılavuzu kontrol edin).

Ana-yardımcı yapılandırmanın sunucu kimliği aynıdır ve ana-bağımlı çoğaltma ortamında aynı sunucu kimliğine sahip binlog olayları filtrelenecektir. Belirli sunucu kimliğinin anlamı, çoğaltma ilkesi hakkında anlaşılabilir. Bu genellikle yapılandırma dosyasını kopyalarken sunucu kimliğini değiştirmeyi unutmaktan kaynaklanır.

2.4.1.6. MyIASM tablosu "işlemi" kayboldu

Last_Errno: 1053 Last_Error: Sorgu ana birimde kısmen tamamlandı (ana birimde hata: 1053) ve iptal edildi. Ana makinenizin bu noktada tutarsız olma ihtimali var. Ana makinenizin iyi olduğundan eminseniz, bu sorguyu ikincil birimde manuel olarak çalıştırın ve ardından slave'i SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; ile yeniden başlatın. Sorgu: 'içine ekle ...

Myisam işlemleri desteklemediğinden, bir sorgunun bir parçayı tamamladığı ve ardından başarısız olduğu bir durum olabilir. Çözüm, genellikle komut istemi mesajı ile verilen bir binlog olayını atlamaktır. Bununla birlikte, atlamayı onaylamadan önce, ilgili kaydın ana bilgisayarda gerçekten mevcut olup olmadığını kontrol etmek daha iyidir, çünkü hata mesajı ayrıca ana bilgisayarda yürütüldüğünü ve sonra sonlandırıldığını düşündüğü sorgu ifadesini de verecektir.

2.4.1.7. Günlük biçimi tek tip değil

Last_SQL_Errno: 1666 Last_SQL_Error: Satır olayı yürütülürken hata oluştu: 'İfade yürütülemiyor: İfade satır biçiminde ve BINLOG_FORMAT = STATEMENT olduğundan ikili günlüğe yazmak imkansız.'

ABC yapısının bir kopyası, B ve C'de ayarlanan binlog_format = ifadesi ve A'da A KARIŞIK, bu nedenle B, A'dan röle günlüğünü yeniden yapmaya çalıştığında ve ardından binlog'u kaydettiğinde (C'ye geçirildi), binlog_formatı ve röle günlüğünün binlog_formatı bulunur. Kendin belirle binlog_format Tutarsız.

2.4.1.8. Slave_load_tmpdir alanı yetersiz

Last_Errno: 28 Last_Error: Append_block olayında hata: '/ tmp / SQL_LOAD-32343798-72213798-1.data'ya yazma başarısız oldu

Ana kütüphane, yükleme veri dosyasını yürütür ve ikincil kitaplıkla senkronizasyondan sonra yükleme veri dosyasında depolanan dosya / tmp (parametre ile) slave_load_tmpdir Control) ve / tmp alanı yeterli değildir, bu nedenle bir hata bildirilir. Bu nedenle, kitaplıktan slave_load_tmpdir'i yeterli disk alanına sahip bir bölüme ayarlayın.

2.4.2. Veri uyuşmazlığı hata yönetimi

örneklem

mysql > CREATE TABLE "t_policy` (" id` int (11) NOT NULL AUTO_INCREMENT, "policy_name` VARCHAR (30) NOT NULL," size` VARCHAR (255) NOT NULL, "active` VARCHAR (1) NOT NULL," create_time` zaman damgası DEFAULT NULL, "update_time" zaman damgası DEFAULT CURRENT_TIMESTAMP UPDATE CURRENT_TIMESTAMP AÇIK, BİRİNCİL ANAHTAR ("kimlik"), ANAHTAR `IX_policy_name` (` politika_adı`) ) MOTOR = InnoDB VARSAYILAN KARAKTER = utf8; mysql > t_policy (politika_adı, boyut, aktif, güncelleme_süresi) değerlerine ('AAA', '1080x920', 1, şimdi ()), ('B', '1080x920', 2, şimdi ()), ('B', '1024x690', 2, şimdi ()), ('C', '1024x768', 3, şimdi ()); mysql > t_policy (politika_adı, boyut, aktif, güncelleme_süresi) değerlerine ('AAAA', '4K', 1, şimdi ()), ('AAA', '2K', 1, şimdi ()), ('AAA', '1K', 1, şimdi ()), ('AAAAA', 'Mavi Işık', 1, şimdi ());

2.4.2.1. Kitaplıktaki kaydı bulun yok

Last_Errno: 1032 Last_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son başarısızlık şuydu: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 31' işlemini gerçekleştiremedi , end_log_pos 9324. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın.

Verileri kitaplıktan silin veya güncelleyin; kayıt kitaplıkta bulunamaz. Şu anda, ana kitaplığın verileri ikincil kitaplıktan daha yenidir ve aynı veriler, çoğaltmayı açtıktan sonra SQL iş parçacığını geri yüklemek için kitaplıktan eklenebilir.
1032 hatasını simüle et

1. Kitaplıktan bir kaydı silin

mysql > t_policy'den sil, burada id = 8;

2. Ana kütüphane silinmiş bir kaydı değiştirir

mysql > güncelleme t_policy boyut = 'Blu-ray v2' burada id = 8;

3. Kitaplıktan çoğaltma durumunu kontrol edin (çoğaltma bağlantısı kesildi)

mysql > köle durumunu göster \ G *************************** 1. satır ******************** ******* Slave_IO_State: Master'ın olay göndermesi bekleniyor Master_Host: 192.168.5.191 Master_User: repl Master_Port: 16000 Connect_Retry: 60 Master_Log_File: 519116000-bin.000005 Read_Master_Log_Pos: 9355 Relay_Log_File: 519216000-röle-bin.000005 Relay_Log_Pos: 6426 Relay_Master_Log_File: 519116000-bin.000005 Slave_IO_Running: Evet Slave_SQL_Running: Hayır Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1032 Last_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son başarısızlık şuydu: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 31' işlemini gerçekleştiremedi , end_log_pos 9324. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın. Skip_Counter: 0 Exec_Master_Log_Pos: 9023 Relay_Log_Space: 7179 Until_Condition: Yok Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Hayır Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: Hayır Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1032 Last_SQL_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son başarısızlık şudur: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 31' işlemini gerçekleştiremedi , end_log_pos 9324. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın. Replicate_Ignore_Server_Ids: Master_Server_Id: 519116000 Ana_UUID: 8117cf0f-96b9-11e7-b884-a0369f790658 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: 17091315:13:24 Master_SSL_Crl: Ana_SSL_Crlpath: Alınan_Gtid_Set: 8117cf0f-96b9-11e7-b884-a0369f790658: 2-31 Executed_Gtid_Set: 8117cf0f-96b9-11e7-b884-a0369f790658: 1-30,95ff34d2-96c0-11e7-850c-a0369f790bac: 1-147 Otomatik Konum: 0 Replicate_Rewrite_DB: Kanal ismi: Master_TLS_Version: Sette 1 satır (0,00 sn)

4. SQL iş parçacığı durdurmasına göre durum Ana kütüphanenin binlog'unu ayrıştırın

# mysqlbinlog -vv --base64-output = kod çözme-satırları 519116000-bin.000005 --start-position = 9023 > / tmp / binlog ... atlandı ... # 17091315:13:24 sunucu kimliği 519116000 end_log_pos 9324 CRC320x1a0f64c2 Güncelleme_rows: tablo kimliği 221 bayrakları: STMT_END_F ### UPDATE `mycat`.`t_policy` ### NEREDE ### @ 1 = 8 / * INT meta = 0 nullable = 0 is_null = 0 * / ### @ 2 = 'AAAAA' / * VARSTRING (90) meta = 90 nullable = 0 is_null = 0 * / ### @ 3 = 'Languang' / * VARSTRING (765) meta = 765 nullable = 0 is_null = 0 * / ### @ 4 = '1' / * VARSTRING (3) meta = 3 nullable = 0 is_null = 0 * / ### @ 5 = 1505286407 / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 0 * / ### @ 6 = 1505286487 / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 0 * / ### SET ### @ 1 = 8 / * INT meta = 0 nullable = 0 is_null = 0 * / ### @ 2 = 'AAAAA' / * VARSTRING (90) meta = 90 nullable = 0 is_null = 0 * / ### @ 3 = 'Blu-ray v2' / * VARSTRING (765) meta = 765 nullable = 0 is_null = 0 * / ### @ 4 = '1' / * VARSTRING (3) meta = 3 nullable = 0 is_null = 0 * / ### @ 5 = 1505286407 / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 0 * / ### @ 6 = 1505286804 / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 0 * / # 9324'te ... atla ...

5. Kitaplıktan kopyalamaya başlamak için veri oluşturun

mysql > t_policy değerlerine (8, 'AAAAA', 'dil', '1', from_unixtime (1505286407), from_unixtime (1505286487)); mysql > köle başlat; mysql > köle durumunu göster \ G

2.4.2.2. Bağımlı kitaplık birincil anahtar çakışması

Last_Errno: 1062 Last_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son başarısızlık şuydu: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 32' işlemini gerçekleştiremedi , end_log_pos 9619. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın.

Kitaplıktan veri eklerken bir benzersizlik çakışması oluşur. Şu anda, bağımlı veritabanı zaten aynı birincil anahtara sahip verilere sahiptir ve aynı birincil anahtar değerine sahip verileri eklerseniz, bir hata bildirilecektir. Ana kitaplığın değiştirilen satır verilerinin ikincil kitaplığa eklenecek verilerle tutarlı olup olmadığını kontrol edebilirsiniz. Tutarlılarsa, hatayı atlayın ve SQL iş parçacığını geri yükleyin. Tutarsızlarsa, ana kitaplık geçerli olacak, kitaplıktan satır kaydını silecek ve sonra kopyalamaya başlayacaktır. .
1062 hatasını simüle et

1. Kitaplıktan bir veri parçası yazın

mysql > t_policy değerlerine ekle (9, 'köle', '768x1024', 0, şimdi (), şimdi ());

2. Ana kütüphane bir veri parçası yazıyor

mysql > t_policy (politika_adı, boyut, aktif, güncelleme_süresi) değerlerine ('A +', '2K', 1, şimdi ()) ekleyin;

3. Kütüphaneden kopya durumunu görüntüleyin

mysql > köle durumunu göster \ G; *************************** 1. satır ******************** ******* Slave_IO_State: Master'ın olay göndermesi bekleniyor Master_Host: 10.209.5.191 Master_User: repl Master_Port: 16000 Connect_Retry: 60 Master_Log_File: 519116000-bin.000005 Read_Master_Log_Pos: 9650 Relay_Log_File: 519216000-röle-bin.000005 Relay_Log_Pos: 6758 Relay_Master_Log_File: 519116000-bin.000005 Slave_IO_Running: Evet Slave_SQL_Running: Hayır Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1062 Last_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son başarısızlık şuydu: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 32' işlemini gerçekleştiremedi , end_log_pos 9619. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın. Skip_Counter: 0 Exec_Master_Log_Pos: 9355 Relay_Log_Space: 7474 Until_Condition: Yok Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Hayır Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: Hayır Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1062 Last_SQL_Error: İşçilerde hata (lar) olduğu için koordinatör durdu. En son hata şuydu: İşçi 5, ana günlük 519116000-bin.000005'te '8117cf0f-96b9-11e7-b884-a0369f790658: 32' işlemini gerçekleştiremedi , end_log_pos 9619. Bu hata veya varsa diğerleri hakkında daha fazla ayrıntı için hata günlüğüne ve / veya performance_schema.replication_applier_status_by_worker tablosuna bakın. Replicate_Ignore_Server_Ids: Master_Server_Id: 519116000 Ana_UUID: 8117cf0f-96b9-11e7-b884-a0369f790658 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: 17091315:47:40 Master_SSL_Crl: Ana_SSL_Crlpath: Alınan_Gtid_Set: 8117cf0f-96b9-11e7-b884-a0369f790658: 2-32 Executed_Gtid_Set: 8117cf0f-96b9-11e7-b884-a0369f790658: 1-31,95ff34d2-96c0-11e7-850c-a0369f790bac: 1-149 Otomatik Konum: 0 Replicate_Rewrite_DB: Kanal ismi: Master_TLS_Version: Sette 1 satır (0,00 sn)

4. SQL iş parçacığı durdurmasına göre durum Ana kütüphanenin binlog'unu ayrıştırın

# mysqlbinlog -vv --base64-output = kod çözme-satırları 519116000-bin.000005 --start-position = 9355 > / tmp / binlog / *! 50530 SET @@ SESSION.PSEUDO_SLAVE_MODE = 1 * /; / *! 50003 SET @OLD_COMPLETION_TYPE = @@ COMPLETION_TYPE, COMPLETION_TYPE = 0 * /; DELIMITER / *! * /; # At 9355 # 17091315:47:40 sunucu kimliği 519116000 end_log_pos 9420 CRC320x8dac50fb GTID last_committed = 34 sıra_numarası = 35SET @@ SESSION.GTID_NEXT = '8117cf0f-96b9-11e7-bf884-a036 / *! * /; # at 9420 # 17091315:47:40 server id 519116000 end_log_pos 9501 CRC320x0cf2c142 Query thread_id = 317 exec_time = 0 error_code = 0SET TIMESTAMP = 1505288860 / *! * /; SET @@ session.pseudo_thread_id = 317 / *! * /; SET @@ session.foreign_key_checks = 1, @@ session.sql_auto_is_null = 0, @@ session.unique_checks = 1, @@ session.autocommit = 1 / *! * /; SET @@ session.sql_mode = 1436549152 / *! * /; SET @@ session.auto_increment_increment = 1, @@ session.auto_increment_offset = 1 / *! * /; / *! \ C utf8 * // *! * /; SET @@ session.character_set_client = 33, @@ session.collation_connection = 33, @@ session.collation_server = 33 / *! * /; SET @@ session.time_zone = 'SİSTEM' / *! * /; SET @@ session.lc_time_names = 0 / *! * /; SET @@ session.collation_database = VARSAYILAN / *! * /; BEGIN / *! * /; # At 9501 # 17091315:47:40 server id 519116000 end_log_pos 9566 CRC320x73be9b73 Table_map: "mycat`.`t_policy` 221 # numaralı 9566 # 17091315:47:40 server id 519116000 end_log_pos 9619 CRC320x454a0acf Write_rows: tablo kimliği 221 bayrakları: STMT_END_F ### INSERT INTO "mycat`.`t_policy` ### SET ### @ 1 = 9 / * INT meta = 0 nullable = 0 is_null = 0 * / # ## @ 2 = 'A +' / * VARSTRING (90) meta = 90 nullable = 0 is_null = 0 * / ### @ 3 = '2K' / * VARSTRING (765) meta = 765 nullable = 0 is_null = 0 * / ### @ 4 = '1' / * VARSTRING (3) meta = 3 nullable = 0 is_null = 0 * / ### @ 5 = NULL / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 1 * / ### @ 6 = 1505288860 / * TIMESTAMP (0) meta = 0 nullable = 1 is_null = 0 * / # 9619 ... At ...

5. Veri tutarlılığı sorununu kütüphaneden çözmenin iki yolu vardır: a) Temel verilere değiştirildi, durma pozisyonu İşletme, temel bir değişim ortamı sağlar b) değiştirildi durma pozisyonu İşlemden sonraki veriler, bunu yapmak işlemin atlanmasını gerektirir Geleneksel kopya atlama hatasını göstermek için, hatayı atlayarak sorunu çözeceğiz

5.1. Master-slave verilerini onarın

mysql > t_policy'den sil, burada id = 9; mysql > t_policy değerlerine ekle (9, 'A +', '2K', '1', NULL, from_unixtime (1505288860));

5.2. Kopyalama hatasını atla Yöntem: binlog konumunu ayrıştırın, hatayı kopyalayan geçerli işlemin GTID sıra numarasını görüntüleyin ve atlayın Uygulama ilkesi: Hatayı atlama amacına ulaşmak için GTID hatasının sıra numarası için bağımlı kitaplıkta boş bir işlem enjekte edin

mysql > köleyi durdur; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > gtid_next = '8117cf0f-96b9-11e7-b884-a0369f790658: 32'; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > başla; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > taahhüt; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > gtid_next = 'otomatik' olarak ayarlayın; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > köle başlat; Sorgu TAMAM, 0 satır etkilendi (0,00 sn) mysql > köle durumunu göster \ G;

2.4.3. Çoğaltma hatalarını ele almak için yüksek düzey yöntemler

2.4.3.1. Geleneksel atlama kopyası hatası

GTID modu MySQL 5.7'den önce zorla açılmadığında, geleneksel çoğaltma modunda atlama hatası aşağıdaki yöntemlerle yapılır:

mysql > köleyi durdur; mysql > set sql_slave_skip_counter = 1; # Mevcut binlog konumuna bağlı olarak bir hatanın atlanmasına izin verildiğini gösterir mysql > köle başlat;

2.4.3.2. Toplu atlama kopyalama hatası

Fiili çalışmada, bir kopyalama hatası oluştuğunda, bu tür birçok kopyalama hatası olacağını ve asla tek bir hata olmayacağını hayal edin Bu senaryoda kopyalama sorununu nasıl hızlı bir şekilde onarabiliriz? MySQL, kopyalama hata kodlarını atlayabilen bir parametre sağlar: slave_skip_errors a) Varsayılan, herhangi bir hatayı atlamamak anlamına gelir b) herşey Kopyalanan tüm hataları atladığını gösterir c) 1032.1062 Bu iki tür kopyalama hatasının atlandığını gösterir

Not: Bu parametre salt okunur bir parametredir, bu nedenle parametreyi veritabanında yapılandırmanız ve etkili olması için veritabanını yeniden başlatmanız gerekir! Dostça bir hatırlatma: Veriler bağlandıktan sonra, bu parametreyi kapatmayı unutmayın !!!

3. Filtre uygulamasını kopyalayın

3.1. Filtre uygulamasını kopyala

3.1. Kopyalama Parametrelerine Giriş

usta

günlük kutusu binlog Dosya adı öneki, tam bir yol olabilir, dinamik olarak değiştirilemez
sync_binlog sync_binlog = N, N SQL'den sonra, binlog bilgilerini yenileyin ve diske yazın. Parametre 0'a eşit olduğunda, her işlemden sonra MySQL, binlog bilgilerini dosya sistemi önbelleğine yazar. fdatasync () Düzenli olarak diske yenileyin Parametre 1'e eşit olduğunda, her işlemden sonra MySQL veritabanı işletim sistemini çağırır fsync () İşlev, binlog bilgilerini diske yazar. Parametre 1'den büyük olduğunda, N. işlemden sonra MySQL çağırır fdatasync () İşlev, binlog bilgilerini diske yazar. fdatasync ile fsync Fark
sunucu kimliği Benzersiz kimlik, aynı kümede tekrarlanamaz ve dinamik olarak değiştirilebilir
günlük-bin-indeksi Günlük-bin ile aynı olan dizin dosyası önek adı tam bir yol olabilir
binlog_format Günlük formatı: ifade, satır, karma dinamik olarak değiştirilebilir, satır önerilir
binlog_cache_size Yazılan arabelleğin boyutu (varsa binlog_cache_disk, binlog_cache_size'nin küçük olduğunu gösterir) dinamik olarak değiştirilebilir
max_binlog_size Tek bir binlogun boyutunu sınırlayın, varsayılan değer dinamik olarak değiştirilebilen 1G'dir. Binlog geçiş süresinin 30 dakika olması önerilir, aksi takdirde veri kurtarma çok yavaş olabilir
expire_logs_days Nbinlog,
log_bin_trust_function_creators binlog,.
gtid-mode=on GTID,ON,log-bin,log-slave-updates,enforce-gtid-consistency
enforce-gtid-consistency gtid-mode=ON,,binlog
gtid-next
gtid-purged
gtid-executed

slave

:
server-id ID,
log_slave_updates slavebinlogbinarylog,,.
relay_log_recovery slave,relaylog,,,masterbinlog,
skip-slave-start ,slave
slave-transaction-retries innodb,,1020
read-only ,super
slave_net_timeout slavemaster,,10,
slave_skip_errors ,(,)
slave-parallel-type DATABASE 5.7 LOGICAL_CLOCK
slave-parallel-workers
master_info_repository
relay_log_info_repository
:
log-slow-slave-statments ,,long_query_time
max_relay_log_size relay_log,
relag-log-info-file relay-log
relay-log-purge ,relaylog,(Mha,master,,relay-log)
relay_log_space_limit relaylog(relaylog,,SSD)
replicate-same-server-id server-idbinlogevent
slave_load_tmpdir loaddatainfile,slave,tmpdir

3.2.

;();

:,(do ignore) :,(do ignore)

: ,

3.2.1.

usta

binlog-do-db
binlog-ignore-db
binlog_format statment row

binlog-do-db=db1use db2; update db1.tab1 set col2=2 where id = 1;

SBR/RBR? SBR:SBR,(use db2;) RBR:RBR,updatedb1.tab1 ,

binlog-ignore-db=db1 use db2; update db1.tab1 set col2=2 where id = 1;

SBR/RBR? SBR:SBRdb1,db2, RBR:RBR update db1.tab1

slave

replicate-do-db slavedb
replicate-ignore-db slavedb
replicate-do-table slavetable
replicate-ignore-table slavetable
replicate-wild-do-table ,slavetable (replicate-wild-do-table=db1.t*)
replicate-wild-ignore-table ,slavetable (replicate-wild-ignore-table=db1.s*)
repicate-rewrite-db masterslaveA,rewrite,masterAslaveB(:master replicate-rewrite-db=a- > b)

3.3.

*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event #io/threadMaster Master_Host: 192.168.1.1 #master Master_User: replica # Master_Port: 3306 #master Connect_Retry: 60 # Master_Log_File: 113306-bin.032047 #IO threadMasterbin_log Read_Master_Log_Pos: 481887487 #IO threadMasterbin_log Relay_Log_File: 123306-relay-bin.052152 #SQL threadRaley_logmaster Relay_Log_Pos: 481651027 #SQL thread Relay_Master_Log_File: 113306-bin.032047 #SQL threadmaster Slave_IO_Running: Yes #IO thread Slave_SQL_Running: Yes #SQL thread 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 #SQL_SLAVE_SKIP_COUNTER Exec_Master_Log_Pos: 481650851 #SQL threadmaster Relay_Log_Space: 481886976 # Until_Condition: None #start slaveuntil Until_Log_File: #untilbinlog Until_Log_Pos: 0 #untilbinlog Master_SSL_Allowed: No #SSL 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 #IO thread Last_IO_Error: # Last_SQL_Errno: 0 #SQL thread Last_SQL_Error: # Replicate_Ignore_Server_Ids: Master_Server_Id: 113306 Master_UUID: a0f36bb1-fdbb-11e5-8413-a0369f7c3bb4 Master_Info_File: mysql.slave_master_info #slavemaster 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: IO thread Last_SQL_Error_Timestamp: SQL thread Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: a0f36bb1-fdbb-11e5-8413-a0369f7c3bb4:11766950523-17011135306 #masterGTID Executed_Gtid_Set: 0921d44c-5d33-11e5-ad43-ecf4bbdee514:1-5946125770, #GTIDa0f36bb1-fdbb-11e5-8413-a0369f7c3bb4:1-17011135306, a6d9cf92-83bc-11e6-ade4-a0369f7c3f80:1-24 Auto_Position: 1 #GTID

4.1.

MySQLmysql5.5mysqlbinlogbinlogmysql5.5mysql5.5commitbinlogbinlog

4.1.1.MySQL