Makine öğrenmez: yüksek kullanılabilirliğe sahip veritabanı UDB'sinin master-slave replikasyonunun gecikmesine yönelik çözüm
MySQL master-slave replikasyonunun gecikmesi, sektörde uzun süredir devam eden bir sorundur. Gecikmenin meydana gelmesi, yüksek gerçek zamanlı veriye sahip işletmeler için MySQL kullanımına elverişli olmayan ana ve bağımlı okuma ve yazma ayrımının değerini azaltacaktır.
UDB, UCloud tarafından başlatılan bir bulut veritabanı hizmetidir. Altı yıldır çevrimiçidir ve on binlerce UDB MySQL örneğini çalıştırmıştır. Ekip, yüksek kullanılabilirlik, yüksek performanslı, kullanışlı ve kullanımı kolay ürün özellikleri sağlamanın yanı sıra, kullanıcıların her gün ortalama 2-3 MySQL örnek ana-bağımlı çoğaltma gecikmesi sorununu çözmelerine yardımcı olur. Birçok uygulamadan, efendi-köle çoğaltma gecikmesinin çeşitli nedenlerini ve çözümlerini özetledik ve şimdi bunları burada paylaşıyoruz.
Gecikmenin önemi
Master-slave replikasyon mekanizması, UDB'nin dahili uygulamasında yaygın olarak kullanılmaktadır: UDB tarafından oluşturulan slave veritabanı ve master veritabanı, "master-slave replikasyonunun" veri replikasyonunu benimser; buna ek olarak, UDB "UDB MySQL Highly Available Instance" ın ana ürünü de 2 Veri çoğaltma, iki veritabanının karşılıklı olarak ana ve ikincil olduğu "ikili ana mod" da gerçekleştirilir İkili ana modun özü, ana-bağımlı çoğaltma mekanizmasıdır.
Master-slave replikasyonu arasında bir gecikme olması, master-slave verilerinin tutarlılığını etkileyecektir.
Yüksek kullanılabilirlikli çoğaltma senaryosunda, UDB yüksek kullanılabilirlikli olağanüstü durum kurtarma tasarımında, birincil ve yedek verilerin tutarsız olduğu bir senaryo varsa, yüksek kullanılabilirlikli olağanüstü durum kurtarma anahtarına varsayılan olarak izin verilmediğini dikkate alırız. Çünkü tutarsız birincil ve ikincil veriler durumunda, felaket kurtarma geçişi bu anda gerçekleşir ve veriler yeni birincil veritabanına yazılır, ardından iş açısından beklenmedik ve ciddi sonuçlar ortaya çıkacaktır.
Çoğaltma gecikmesi sorunu, yalnızca UDB'nin yüksek kullanılabilirliğinde istenmeyen sonuçlar doğurmaz, aynı zamanda salt okunur bağımlı kitaplık senaryosunda, bağımlı kitaplıkta bir çoğaltma gecikmesi varsa, iş üzerinde okuma gibi belirli bir etkiye de sahip olabilir. Yeni / değiştirilmiş veri bulamama gibi tutarsızlık fenomenlerini yazın.
Bu, ana-bağımlı çoğaltmanın gecikmesinin veritabanı işlemlerinde özel dikkat gerektirdiğini gösterir. Genel olarak bir DBA, kitaplıkta "KÖLE DURUMU GÖSTER" i yürütür ve mevcut veritabanı ile ana veritabanı arasındaki veri çoğaltma gecikmesini anlamak için "Seconds_Behind_Master" değerini gözlemler. Bu değer çok önemlidir, bu nedenle UDB'nin izleme arayüzünde bu değeri ayrı ayrı çıkardık ve işletim ve bakım personelinin doğrudan konsolda gözlemleyebilmesi için "Kitaplıktan Senkronizasyon Gecikmesi" izleme öğesini tasarladık.
Üretim ortamında gecikme probleminin analizi ve çözümü
En yaygın ana-bağımlı çoğaltma gecikmesi durumlarını birkaç kategoride özetliyoruz.Aşağıda fenomen açıklaması, neden analizi ve ilgili vakaların çözümünün bir özeti bulunmaktadır.
Durum 1: Ana kütüphane DML talepleri sık sık
Yoğun iş dönemlerinde, bazı kullanıcılar, özellikle veritabanının ana veritabanı için çok sayıda yazma isteği işlemi olduğunda, yani ekleme, silme, güncelleme vb. Gibi çok sayıda eşzamanlı işlem olduğunda, ana-bağımlı çoğaltma gecikmesi sorunu yaşayacaktır.
Semptom
Ana kütüphanenin yazma işleminin QPS değerini gözlemleyerek ana kütüphanenin yazma işleminin QPS değerinin aniden yükseldiğini görebiliriz.Master-slave replikasyon gecikmesinin artmasıyla ana kütüphanenin sık DML taleplerinden kaynaklandığı yargılanabilir.
Yukarıdaki şekilde gösterildiği gibi, QPS'nin 17:58 civarında aniden arttığı görülebilir.Konsoldaki yazma ile ilgili QPS'yi kontrol edin ve buna karşılık gelen bir artış var. QPS'nin ani artış zamanı, ilgili gecikme de aşağıdaki şekilde gösterildiği gibi kademeli olarak artmaktadır.
sebep analizi
Analizden sonra, bunun, kısa sürede çok sayıda binlog oluşturan ana kütüphanedeki çok sayıda yazma isteği işleminden kaynaklandığına inanıyoruz. Tüm bu işlemlerin bağımlı kitaplıkla senkronize edilmesi ve yürütülmesi gerekir, böylece ana-bağımlı veri çoğaltma gecikmesi oluşur.
Nedeni derin bir seviyeden incelendiğinde, ana veritabanı yazma verilerinin işin en yoğun olduğu dönemde eşzamanlı olarak yazılması ve ikincil veritabanı SQL Thread'in, röle günlüğü birikimine ve gecikmeye kolayca neden olabilecek tek iş parçacıklı bir oynatma binlog günlüğü olmasıdır.
Çözümler
5.7'nin altındaki MySQL sürümüyse, yazma isteklerini ölçek büyütme yoluyla ayırmak için parçalama yapabilir ve binlog'a yazma isteklerinin paralelliğini iyileştirebilirsiniz.
MySQL 5.7 veya üzeriyse, MySQL 5.7'de mantıksal saate (Group Commit) dayalı paralel çoğaltma kullanılır. MySQL 8.0'da, Yazma Setine dayalı paralel çoğaltma kullanılır. Bu çözümlerin her ikisi de binlog yeniden oynatma performansını artırabilir ve gecikmeyi azaltabilir.
Durum 2: Ana kütüphane büyük işleri yürütür
Büyük işlem, uzun süren bir işlemin gerçekleştirilmesini ifade eder. Büyük işlemler üreten yaygın ifadeler şunlardır:
- Çok yavaş veri içe aktarma deyimleri kullanın, örneğin: INSERT INTO tb, SELECT FROM
- tb, SELECT FROMtb, LOAD DATA INFILE, vb .;
- UPDATE ve DELETE deyimleri, büyük bir tablo için tam tablo UPDATE ve DELETE gerçekleştirmek için kullanılır.
Bu işlem kitaplıktan oynatma yürütme işlemini yürüttüğünde, ana-bağımlı çoğaltma gecikmesine neden olabilir.
Semptom
SHOW SLAVE STATUS sonuçlarından analiz ediyoruz, Exec_Master_Log_Pos alanının değişmediğini ve second_behinds_master'ın artmaya devam ettiğini ve Slave_SQL_Running_State alanının değerinin "Röle günlüğünden okuma olayı" olduğunu; aynı zamanda ana kütüphanenin mevcut yürütmesini görmek için ana kütüphane bin günlüğünü analiz edin Bazı büyük işlemler olduğunu fark ederseniz, temel olarak ana-bağımlı çoğaltma gecikmesinin büyük işlemin yürütülmesinden kaynaklandığını belirleyebilirsiniz.
sebep analizi
Binlog'da büyük bir işlem kaydedildikten ve slave kütüphanesine senkronize edildikten sonra, slave kütüphanesinin bu işlemi yürütmek için çalışması da uzun zaman alır.Bu süre zarfında bir master-slave replikasyon gecikmesi meydana gelecektir.
Örneğin, ana kitaplık büyük bir tabloyu güncellemek için 200 saniye harcarsa, ana ve yardımcı kitaplıkların konfigürasyonu benzer ise, ikincil kitaplığın da büyük tabloyu güncellemek için neredeyse aynı zamanı harcaması gerekir.Bu sırada, ikincil kitaplığın gecikmesi birikmeye başlar. olaylar güncellenemedi.
Çözümler
Bu durumun neden olduğu ana-bağımlı çoğaltma gecikmesi için, iyileştirme yöntemimiz: büyük işlem bildirimini birkaç küçük işleme bölmek, böylece zamanında gönderim gerçekleştirilebilir ve ana-bağımlı çoğaltma gecikmesi azaltılabilir.
Durum 3: Ana kütüphane, büyük tablolarda DDL deyimlerini yürütür
DDL'nin tam adı, bir alan eklemek veya tabloya bir dizin eklemek gibi tablonun yapısını değiştiren bazı ifadeleri ifade eden Veri Tanımlama Dili'dir. DDL, ana veritabanındaki büyük tablolarda DDL deyimlerini yürüttüğünde, ana-bağımlı çoğaltma gecikmeleri meydana gelebilir.
Semptom
Olağanüstü bir şekilde, bağımlı kitaplıktan SHOW SLAVE STATUS çıktısının yürütülmesi, Exec_Master_Log_Pos'un taşınmadığını kontrol edin ve ana kitaplık büyük işlemler yürütürse, büyük tablonun DDL'sinin yürütülüyor olması mümkündür. Bu, ana kütüphane binlog'unu analiz ederek ve ana kütüphane tarafından halihazırda yürütülen işlemlere bakarak doğrulanabilir.
DDL ifadelerinin yürütülmesi, daha iyi yargılamak için daha fazla ayrılabilir:
Yukarıdaki fenomen varsa, o zaman büyük olasılıkla ana kitaplık büyük tablo üzerinde DDL ifadeleri yürütür, ikincil kitaplıkla senkronize olur ve kitaplıktan oynatır ve bu da ana-bağımlı çoğaltma gecikmesine neden olur.
sebep analizi
DDL'nin neden olduğu master-slave replikasyonunun gecikmesinin nedeni büyük işlemlerinkine benzer, ayrıca kütüphaneden gelen DDL binlog'unun master-slave replikasyon gecikmesini yürütmek için yavaş olmasıdır.
Çözümler
Bu durumda, engelleyici DDL ifadelerini bulmak için SHOW PROCESSLIST veya sorgu information_schema.innodb_trx'i ve KILL ile ilgili sorguları bulmak için kullanırız, böylece DDL kitaplıktan normal olarak çalıştırılabilir.
DDL'nin kendisinin neden olduğu gecikme kaçınılmazdır. Aşağıdakileri dikkate almanız önerilir:
- İş zirvelerinden kaçının ve düşük yoğun dönemlerde yürütmeyi düzenlemeye çalışın;
- Sql_log_bin = 0 ayarlandıktan sonra, ana ve bağımlı kitaplıklarda DDL'yi manuel olarak çalıştırın (bu işlem bazı DDL işlemlerinde veri tutarsızlığına neden olur, lütfen kesinlikle test ettiğinizden emin olun), bulut veritabanı UDB kullanıyorsanız, UCloud UDB işlem ve bakım ekibiyle iletişime geçebilirsiniz. Yardımlı işlemleri gerçekleştirin.
Durum 4: Ana kitaplığın ve yardımcı kitaplığın yapılandırması tutarsız
Ana kitaplık ve yardımcı kitaplık farklı bilgi işlem kaynakları ve depolama kaynakları kullanırsa veya farklı çekirdek ayarlama parametreleri kullanırsa, ana ve ikincil kitaplık arasında tutarsızlığa neden olabilir.
Semptom
Ana kitaplık ve bağımlı kitaplığın performans izleme verilerini ayrıntılı olarak karşılaştıracağız.İzleme verilerinin çok farklı olduğunu tespit edersek, ana ve köle yapılandırmasını kontrol ederek net bir karar verebiliriz.
sebep analizi
Çeşitli donanım veya kaynak yapılandırma farklılıkları, ana ve ikincil öğenin performansında farklılıklara neden olabilir ve bu da ana-bağımlı çoğaltmanın gecikmesine neden olur:
- Donanım: Örneğin, ana kitaplığın örnek sunucusu SSD diskler kullanıyorsa ve ikincil kitaplığın örnek sunucusu sıradan SAS diskleri kullanıyorsa, ana kitaplık tarafından oluşturulan yazma işlemleri hemen ikincil kitaplıkta sindirilemez ve bu da ana-bağımlı çoğaltma gecikmesine neden olur;
- Yapılandırma: Örneğin, tutarsız RAID kartı yazma stratejileri, tutarsız işletim sistemi çekirdek parametresi ayarları ve tutarsız MySQL disk yerleştirme stratejilerinin tümü olası nedenlerdir.
Çözümler
DB makinesinin yapılandırmasını birleştirmeyi deneyin (donanım ve seçenek parametreleri dahil). Bazı OLAP hizmetleri için bile, bağımlı kitaplık örneğinin donanım yapılandırmasının ana kitaplığınkinden biraz daha yüksek olması gerekir.
Durum 5: Tabloda birincil anahtar veya uygun dizin eksik
Veritabanı tablosunda bir birincil anahtar veya uygun bir indeks yoksa, ana-bağımlı çoğaltmanın binlog_formatı 'satır' olarak ayarlanmışsa, ana-bağımlı çoğaltma gecikmesi oluşabilir.
Semptom
Veritabanını kontrol ettiğimizde şunları bulacağız:
- SHOW SLAVE STATUS çıkışını gözlemleyin ve Slave_SQL_Running_State'in röle günlüğünden olay okuduğunu bulun;
- İn_use = 1 her zaman var olan AÇIK TABLOLARI GÖSTER;
- SHOW SLAVE STATUS'un Exec_Master_Log_Pos alanının değişmeden kaldığını gözlemleyin;
- Mysqld işleminin CPU'su% 100'e yakın (okuma servisi olmadığında) ve IO basıncı çok iyi değil.
Bu fenomen meydana geldiğinde, bir tablonun birincil anahtar veya benzersiz bir dizinden yoksun olduğu düşünülebilir.
sebep analizi
Örneğin, ana-bağımlı çoğaltmanın binlog_formatı 'satır' olarak ayarlandığında, ana veritabanının 5 milyon tablodaki 200.000 satır veriyi güncellediği bir senaryo vardır. Binlog'un satır biçiminde, binlog'a 200.000 güncelleme işlemi kaydedilir, yani işlem başına bir kayıt güncellenir. Bu ifade, tam tablo taraması gibi kötü bir yürütme planına sahipse, her güncelleme ifadesi tam bir tablo taraması gerektirir. Şu anda, SQL İş Parçacığı yeniden yürütmesi özellikle yavaş olacak ve ciddi ana-bağımlı çoğaltma gecikmesine neden olacaktır.
Çözümler
Bu durumda, her tablonun açık bir kendi kendine artan birincil anahtara sahip olduğundan emin olmak için tablo yapısını kontrol edeceğiz ve kullanıcılara uygun indeksler oluşturmada yardımcı olacağız.
Durum 6: Kitaplığın kendisinden aşırı baskı
Bazen, bağımlı kitaplığın performans baskısı çok yüksek olduğunda, ana kitaplığın güncelleme hızı sürdürülemez ve bu da ana-bağımlı çoğaltma gecikmesine neden olur.
Semptom
Veritabanı örneğini gözlemlerken, CPU yükünün çok yüksek olduğunu ve IO kullanımının çok yüksek olduğunu göreceksiniz.Bu fenomenler SQL Thread uygulamasının çok yavaş olmasına neden olur. Bu şekilde, ana-bağımlı çoğaltma gecikmesinin, köle kitaplığının kendisinin aşırı baskısından kaynaklandığı yargılanabilir.
sebep analizi
Bazı UCloud kullanıcıları, veritabanının ana ve kölesi için okuma-yazma ayırma modunu kullanır ve çoğu okuma isteği, ikincil kitaplıkta yürütülür. İşletmenin çok sayıda okuma talebine sahip olduğu bir senaryoda, yardımcı kitaplık, ana kitaplıktan çok daha fazla performans baskısı oluşturacaktır. Hatta bazı kullanıcılar, bağımlı kitaplıktaki hesaplama kaynaklarını tüketen OLAP hizmetlerini çalıştırır, bu da ikincil kitaplıkta daha yüksek performans zorlukları ortaya çıkarır ve bu da ana-bağımlı çoğaltmanın gecikmesine neden olur.
Çözümler
Bu durumda, kullanıcılara daha fazla bağımlı kitaplık oluşturmalarını, okuma isteklerini ayırmalarını ve mevcut bağımlı kitaplık örnekleri üzerindeki baskıyı azaltmalarını önereceğiz. OLAP işi için, OLAP işi yapmak için bir bağımlı kitaplık özel olarak kurulabilir ve bu bağımlı kitaplık için uygun bir ana-bağımlı çoğaltma gecikmesine izin verilir.
sonuç olarak
Veri replikasyonu için MySQL'in master-slave replikasyon modunu kullanırken, master-slave replikasyonunun gecikmesi dikkate alınması gereken önemli bir faktördür. Verilerin tutarlılığını etkileyecek ve ardından veritabanının yüksek kullanılabilirliğinin olağanüstü durum tolerans anahtarını etkileyecektir.
Veritabanları arasında ana-bağımlı çoğaltma gecikmeleri olması durumunda, geçmiş deneyime dayanan ekibimiz, sorun gidermeye yardımcı olmak için aşağıdaki yöntemleri ve prosedürleri özetledi:
- Bağımlı kitaplığın mevcut durumunu KÖLE DURUMU GÖSTER ve İŞLEM LİSTESİNİ GÖSTER ile kontrol edin. (Bu arada, kütüphaneden yedekleme yaparken benzer nedenler de göz ardı edilebilir);
- Exec_Master_Log_Pos değişmeden kalırsa, büyük işlemleri, DDL'yi göz önünde bulundurun ve birincil anahtar yok, yalnızca binlog'u ve ana kitaplığa karşılık gelen konumu kontrol edin;
- Exec_Master_Log_Pos değişirse, gecikme kademeli olarak artacaktır.IO, CPU vb. Gibi ikincil kitaplık makinesinin yükünü göz önünde bulundurun ve ana kitaplık yazma işleminin ve ikincil kitaplığın kendisinin basıncının çok büyük olup olmadığını düşünün.
UDB'nin yüksek kullanılabilirliği, yüksek performansı, rahatlığı ve kullanım kolaylığı, kullanıcının işletim ve bakım yükünü büyük ölçüde azaltabilir. Kullanım sürecinde, UDB ekibi ayrıca kullanıcıların sorunların nedenlerini zamanında analiz etmesine ve gidermesine ve makul çözümler sağlamasına yardımcı olmak için yılların birikmiş işletim deneyimini kullanacaktır.
Bu makalenin kaynağı: UCloud teknolojisi (WeChat genel hesabı: ucloud_tech)
Orijinal bağlantı: https://mp.weixin.qq.com/s/aqEx4Gyb4jl1yky5ueXmPQ
-
- Harika 10 yıl! Guoyu Su Cup 6 ardışık şampiyonluk, Lin Dan + Fengyun, Dinghai Shenzhen ile birleşti!
