MySQL Çoğaltması Yüksek Gecikmeli Bir Bağlantıdan Etkileniyor mu?

Farklı veri merkezlerinde bulunan bir vanilya master ve slave MySQL kurulumumuz ve master ile aynı veri merkezindeki başka bir slave var.

Veri merkezi arasındaki bant genişliği oldukça yüksektir (yaptığımız ağ kıyaslamalarında 15MB / saniyeye ulaşabiliriz), ancak gecikme vardır, 28ms civarındadır. Hiçbir şekilde yüksek değildir, ancak aynı veri merkezindeki ikinci-altı gecikmeden çok daha yüksektir.

Bazen, yerel köle güncel kalırken, kaldırma köle ile ciddi gecikmeler (2000 saniye ve daha fazla) yaşarız. Gecikmiş uzak slave'e bakıldığında, SQL iş parçacığı genellikle IO iş parçacığının geçiş günlüğünü güncellemesini beklerken zaman harcar. Master aynı anda "net bekliyor" veya benzeri bir şey gösterir.

Yani bu ağ anlamına geliyor, ancak bunun gerçekleştiği anda hala ücretsiz bant genişliğimiz var.

Sorum şu : Veri merkezleri arasındaki gecikme, çoğaltma performansını etkileyebilir mi? Slave io iş parçacığı yalnızca ana veri gönderimi durdurana kadar olayları akışa mı aktarıyor yoksa ana yolla bir şekilde olaylar arasında mı havuzlanıyor?

Sorunuzun doğrudan yanıtı Evet, ancak çalıştırdığınız MySQL sürümüne bağlıdır. MySQL 5.5'ten önce çoğaltma aşağıdaki gibi çalışır:

• Ana SQL yürütür
• Master, SQL Olayını İkili Günlüklerine Kaydeder
• Slave SQL İkili Günlüklerden SQL Olayını Okuyor
• Slave, SQL Olayını G / Ç İş Parçacığıyla Röle Günlüklerinde Saklar
• Slave SQL İş parçacığı üzerinden geçiş günlüğünden sonraki SQL olayı okur
• Slave SQL'i Yürütür
• Slave, SQL Etkinliğinin Tam Yürütülmesinin Ana Verisini Kabul Etti

MySQL 5.5'ten itibaren, Yarı Senkronize Çoğaltma kullanılarak , artık çoğaltma aşağıdaki gibi çalışacaktır:

• Ana SQL yürütür
• Master, SQL Olayını İkili Günlüklerine Kaydeder
• Slave SQL İkili Günlüklerden SQL Olayını Okuyor
• Slave, SQL Etkinliğinin Alınışının Ana Bilgisini Kabul Ediyor
• Slave, SQL Olayını G / Ç İş Parçacığıyla Röle Günlüklerinde Saklar
• Slave SQL İş parçacığı üzerinden geçiş günlüğünden sonraki SQL olayı okur
• Slave SQL'i Yürütür
• Slave, SQL Etkinliğinin Tam Yürütülmesinin Ana Verisini Kabul Etti

Bu yeni paradigma, bir Köle'nin Üstadı ile daha yakın senkronize olmasına izin verecektir.

Bununla birlikte, ağ içindeki gecikme MySQL Semisync Replication'yi eski stil eşzamansız çoğaltmaya geri döndürdüğü noktaya engelleyebilir. Neden ? Herhangi bir köle işlemi kabul etmeden bir zaman aşımı oluşursa, master eşzamansız çoğaltmaya geri döner. En az bir yarı senkronize bağımlı yakalandığında, master yarı senkronize çoğaltmaya geri döner.

GÜNCELLEME 2011-08-08 14:22 EDT

MySQL 5.5 Yarı Zamanlı Çoğaltma yapılandırması basittir

Adım 1) Bu dört (4) satırı /etc/my.cnf dosyasına ekleyin

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
#rpl_semi_sync_master_enabled
#rpl_semi_sync_master_timeout=5000
#rpl_semi_sync_slave_enabled

Adım 2) MySQL'i yeniden başlatın

service mysql restart

Adım 3) Bu komutları MySQL istemcisinde çalıştırın

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave  SONAME 'semisync_slave.so';

Adım 4) plugin-dir seçeneğinden sonra üç rpm_semi_sync seçeneğini kaldırın

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_slave_enabled

Adım 5) MySQL'i yeniden başlatın

service mysql restart

Hepsi tamam !!! Şimdi her zamanki gibi MySQL Replication'ı kurmanız yeterli.

Rolando'un bir çoğaltmanın gerçekleştirdiği işlem sırasını nasıl tanımladığını gerçekten seviyorum. Ancak, başka bir bileşen - istemci eklersek daha açık olacağını düşünüyorum.

İstemci ile eşzamansız çoğaltma için işlem sırası aşağıdaki gibi olabilir:

1. İstemci ana işlemleri SQL sorgularını (örneğin, ekleme) kullanarak gönderir

2. Master işlemi yürütür. Başarılı olması durumunda kayıt diskte saklanır, ancak işlem henüz gerçekleştirilmez.

3. Ana, ekleme olayını ana ikili günlüğe kaydeder Ana, ikili günlükte depolayamazsa, işlem geri alınır.

4. Müşteri, master'dan yanıt alır (başarı veya geri alma).

5. İşlemin başarılı olması durumunda, master'daki döküm iş parçacığı olayı ikili günlükten okur ve ikincil G / Ç iş parçacığına gönderir.

6. Slave G / Ç iş parçacığı olayı alır ve olayı aktarma günlük dosyasının sonuna yazar.

7. Olay geçiş günlüğüne girdikten sonra, bağımlı SQL iş parçacığı
   değişiklikleri bağımlı sistemdeki veritabanına uygulamak için olayı yürütür .

Bu senaryoda master slave ile ilgilenmez ve istemci sadece "SIRA DURUMU GÖSTER" komutunu manuel olarak çalıştırarak slave'de bir şeylerin yanlış olduğunu bilir.

Yarı senkronize bir çoğaltma durumunda işlem sırası aşağıdaki gibi olabilir:

1. İstemci ana işlemleri SQL sorgusunu (örneğin, ekleme) kullanarak gönderir.

2. Master işlemi yürütür. Başarılı olması durumunda kayıt diskte saklanır, ancak işlem yapılmaz.

3. Ana, ekleme olayını ana ikili günlüğe kaydeder Ana, ikili günlükte saklayamazsa, işlem geri alınır ve istemci yalnızca geri alma durumunda yanıt alır.

4. Master üzerindeki işlemin başarılı olmasından dolayı, master'daki döküm iş parçacığı olayı ikili günlükten okur ve ikincil G / Ç iş parçacığına gönderir.

5. Slave G / Ç iş parçacığı olayı alır ve olayı aktarma günlük dosyasının sonuna yazar.

6. Slave, olayı röle günlük dosyasına kaydetme konusunda Master'ı onaylar.

7. Master ekleme işlemini gerçekleştirir.

8. Müşteri, master'dan yanıt alır (başarı).

9. Olay geçiş günlüğüne girdiğinde, bağımlı SQL iş parçacığı
   olayı yürütür . Master ve müşteri yürütmenin başarılı olup olmadığını bilmiyor.

Yarı senkronize çoğaltma, köle veya ağ öldüğünde ve efendi ilerlemeye devam ettiğinde önemli bir durumu çözdü. Sonra master ölür ve eski düğümü, sadece o düğümü düzelttiğiniz için yeni master olarak yeniden başlatmak istersiniz.

Bu düğümü yeni master olarak başlattınız, eski master'ı düzelttiniz ve şimdi köle olarak kullanmak istiyorsunuz. Bu düğüm hala verilere sahiptir, ancak yeni slave yeni master'ın başladığı yerden başlarsa yinelenen kayıtlar olacaktır.

Bekleme süresi sonsuzsa, ana ikili günlük konumu, bağımlıdaki tüm sorguların başarılı olduğu varsayılarak daima bağımlı röle günlük konumu ile senkronize olacaktır. Bu varsayım ne kadar gerçekçi?

Bence çok gerçekçi. Slave sorgu hatasının en sık karşılaşılan durumlarından biri "yinelenen kayıt" tır. Efendi yoksa kopya kayıt köleye nereden geldi? Çoğalmaya başlamak için köleye verilen yanlış pozisyondan geldi. Başlangıç ​​çoğaltma konumu, daha önce çoğaltılan kaydı içerir. Yarı senkron çoğaltma durumunda bu durum gerçekleşmez.

Jacob Nikom

Niteleyici : MySQL kullanıcısı değilim, bu yüzden çoğunlukla bu sadece internetteki araştırmam.

Bildiğim gibi, MySQL çoğaltmasının en büyük sınırlaması tek iş parçacıklı olmasıdır. Bu nedenle, iş parçacığı şirket içi slave'e veri göndermekle meşgulken, uzak slave'e veri gönderemez. Bu burada .

Başına burada :

Yapmanız gereken tek şey işlem sürenizi kısaltmaktır. Bu, çoğaltma iş parçacığının veritabanında neler olup bittiğini yakalama fırsatı bulmasını sağlar. İşlemlerinizin mümkün olduğunca kısa olmasını istiyorsunuz.

Bunu yapmanın bir yolu sorgu kesmektir; WHERE yan tümcelerini kullanarak UPDATE veya DELETE tarafından değiştirilen satırları sınırlayın. Bunu bir döngünün içine yapıştırırsanız, her seferinde işlemi başlatarak ve gerçekleştirerek listeyi tekrarlayabilirsiniz. (GÜNCELLEME / ilk üçte, ikinci üçte kendi işlemde sonra nihai üçte her SİL.) Şahsen ederim şiddetle sen işlemler arasında değişen tablodaki verilerin olasılığına kendinizi aç çünkü bunu önermeyiz. Ancak, başka kimsenin masaya bulaşmadığından eminseniz (ve asla olmayacaksa) bu performansı iyileştirme olasılığı vardır .

Başka bir olasılık, uzun süren bu işlemleri çoğaltmamak, aksine bunları hem ana sunucuda (yerel köle çoğaltır) çalıştırın hem de uzak köle üzerinde ayrı ayrı çalıştırmaktır. Bu, çoğaltma iş parçacığını serbest bırakır, böylece 30'dan fazla dakika işaretine düşmez.

Başına burada :

Son bir olasılık, TCP arabelleklerinizin boyutunu ayarlamak olacaktır. Amaç, master ve slave arasında yaptığınız iletişim sayısını azaltmaktır. Bu, gecikmeyi azaltmaya yardımcı olabilir.

Şahsen, eğer her şey başarısız olursa bunu denerdim. Sorunun bir ağ gecikmesinden ziyade tek iş parçacıklı çoğaltma sisteminden kaynaklandığından şüpheleniyorum. Ağlar normalde 30 dakikalık işaretten çok önce zaman aşımına uğrar. (30 dakika?!)

JHammerb'in Lezzetli yer imleri , kontrol etmek isteyebileceğiniz mysql çoğaltması için birkaç bağlantıya sahiptir.

Umarım bu yardımcı olur.