Citymobil'de ana kalıcı veri depolama alanımız olarak MySQL veritabanını kullanıyoruz. Çeşitli hizmet ve amaçlara yönelik çeşitli veritabanı kümelerimiz var.

Master'ın sürekli kullanılabilirliği, tüm sistemin ve bireysel parçalarının performansının kritik bir göstergesidir. Bir ana arıza durumunda otomatik küme kurtarma, olay müdahale süresini ve sistem kesinti süresini büyük ölçüde azaltır. Bu makalede, MySQL kümesi için yüksek kullanılabilirlik (HA) tasarımına bakacağım. MySQL Orkestratörü ve sanal IP adresleri (VIP).

VIP tabanlı HA çözümü

Öncelikle veri depolama sistemimizin ne olduğunu kısaca anlatacağım.

Yazılabilir bir ana kopya ve birden fazla salt okunur kopyadan oluşan klasik bir çoğaltma şeması kullanıyoruz. Bir küme, başkaları için hem kopya hem de ana öğe olan bir düğüm olan bir ara ana öğe içerebilir. Müşteriler, eşit yük dağıtımına ve kolay ölçeklendirmeye olanak tanıyan HAProxy aracılığıyla kopyalara erişir. HAProxy'nin kullanımı tarihsel nedenlerden kaynaklanmaktadır ve şu anda ProxySQL'e geçiş sürecindeyiz.

Çoğaltma, yarı eşzamanlı modda gerçekleştirilir. GTID. Bu, bir işlemin başarılı sayılması için en az bir kopyanın günlüğe kaydedilmesi gerektiği anlamına gelir. Bu çoğaltma modu, ana düğüm arızası durumunda performans ve veri güvenliği arasında optimum dengeyi sağlar. Temel olarak tüm değişiklikler ana kopyadan kopyalara aktarılır. Row Based Replication (RBR), ancak bazı düğümler olabilir mixed binlog format.

Orkestratör, küme topolojisinin durumunu periyodik olarak günceller, alınan bilgileri analiz eder ve sorunlar ortaya çıkarsa otomatik bir kurtarma prosedürünü başlatabilir. Geliştirici, farklı şekillerde uygulanabileceği için prosedürün kendisinden sorumludur: VIP, DNS'ye dayalı olarak, hizmet keşif hizmetlerini kullanarak veya kendi kendine yazılan mekanizmaları kullanarak.

Başarısız olması durumunda ana öğeyi geri yüklemenin basit bir yolu, değişken VIP adresleri kullanmaktır.

İlerlemeden önce bu çözüm hakkında bilmeniz gerekenler:

• VIP, belirli bir fiziksel ağ arayüzüyle ilişkili olmayan bir IP adresidir. Bir düğüm arızalanırsa veya planlı bakım sırasında VIP'yi minimum kesinti süresiyle başka bir kaynağa geçirebiliriz.
• Sanal IP adresini serbest bırakmak ve vermek ucuz ve hızlı bir işlemdir.
• VIP ile çalışmak için sunucuya SSH aracılığıyla erişmeniz veya özel yardımcı programları kullanmanız gerekir, örneğin: keepalived.

Sihirbazımızla ilgili olası sorunlara bakalım ve otomatik kurtarma mekanizmasının nasıl çalışması gerektiğini hayal edelim.

Ana sunucuya olan ağ bağlantısı kesildi veya donanım düzeyinde bir sorun ortaya çıktı ve sunucu kullanılamıyor

1. Orkestratör küme topolojisini günceller, her kopya ana sunucunun kullanılamadığını bildirir. Orkestratör, yeni yöneticinin rolüne uygun bir kopya seçme sürecini başlatır ve kurtarmaya başlar.
2. VIP'yi eski ustadan kaldırmaya çalışıyoruz - başarılı olamıyoruz.
3. Çoğaltma, ana rolüne geçer. Topoloji yeniden oluşturuluyor.
4. VIP ile yeni bir ağ arayüzü ekleme. VIP'yi kaldırmak mümkün olmadığından arka planda periyodik olarak istek göndermeye başlıyoruz karşılıksız ARP. Bu tür istek/yanıt, bağlı anahtarlardaki IP ve MAC adresi eşleştirme tablosunu güncellemenize olanak tanır ve böylece VIP'mizin taşındığını size bildirir. Bu olasılığı en aza indirir split brain eski ustayı iade ederken.
5. Tüm yeni bağlantılar hemen yeni ana bilgisayara yönlendirilir. Eski bağlantılar başarısız oluyor ve uygulama düzeyinde veritabanına tekrarlanan çağrılar yapılıyor.

Sunucu normal modda çalışıyor, DBMS düzeyinde bir arıza oluştu

Algoritma önceki duruma benzer: topolojinin güncellenmesi ve kurtarma işleminin başlatılması. Sunucu mevcut olduğundan, eski ana makinedeki VIP'yi başarıyla serbest bırakıyoruz, yenisine aktarıyoruz ve birkaç ARP isteği gönderiyoruz. Eski yöneticinin olası geri dönüşü, yeniden oluşturulan kümeyi ve uygulamanın çalışmasını etkilememelidir.

Diğer sorunlar

Kopyaların veya ara ana kopyaların arızalanması yol açmaz otomatik eylemlere sahiptir ve manuel müdahale gerektirir.

Bir sanal ağ arayüzü her zaman geçici olarak eklenir, yani sunucu yeniden başlatıldıktan sonra VIP otomatik olarak atanmaz. Her veritabanı örneği varsayılan olarak salt okunur modda başlar, orkestratör otomatik olarak yeni ana öğeyi yazmaya geçirir ve yüklemeyi dener read only eski ustada. Bu eylemler olasılığını azaltmayı amaçlamaktadır. split brain.

Standart izleme araçlarına ek olarak orkestratör kullanıcı arayüzü aracılığıyla da bildirilmesi gereken kurtarma işlemi sırasında sorunlar ortaya çıkabilir. Bu özelliği ekleyerek REST API'yi genişlettik (PR şu anda inceleniyor).

HA çözümünün genel diyagramı aşağıda sunulmuştur.

Yeni bir usta seçmek

Orkestracı yeterince akıllıdır ve seçim yapmaya çalışır. en uygun replika aşağıdaki kriterlere göre yeni bir usta olarak:

• kopya ana makinenin gerisinde kalıyor;
• Ana ve kopyanın MySQL sürümü;
• çoğaltma türü (RBR, SBR veya karışık);
• aynı veya farklı veri merkezlerinde konum;
• durumu errant GTID — kopya üzerinde yürütülen ve ana bilgisayarda bulunmayan işlemler;
• özel seçim kuralları da dikkate alınır.

Her ipucu bir usta için ideal bir aday değildir. Örneğin, verileri yedeklemek için bir kopya kullanılabilir veya sunucunun donanım yapılandırması daha zayıftır. Orkestratör поддерживает Aday seçim tercihlerinizi en çok tercih edilenden göz ardı edilene kadar özelleştirebileceğiniz manuel kurallar.

Yanıt ve iyileşme süresi

Bir olay durumunda sistemin kapalı kalma süresini en aza indirmek önemlidir, bu nedenle orkestratör tarafından küme topolojisinin oluşturulmasını ve güncellenmesini etkileyen MySQL parametrelerini göz önünde bulunduralım:

• slave_net_timeout — bağlantının kaybolduğunu fark edip yeniden bağlanmadan önce kopyanın ana sunucudan yeni veri veya kalp atışı sinyali gelmesini beklediği saniye sayısı. Değer ne kadar düşük olursa kopya, ana bilgisayarla iletişimin koptuğunu o kadar hızlı belirleyebilir. Bu değeri 5 saniyeye ayarladık.
• MASTER_CONNECT_RETRY — yeniden bağlanma girişimleri arasındaki saniye sayısı. Ağ sorunları durumunda bu parametrenin düşük bir değeri, hızlı yeniden bağlanmaya olanak tanıyacak ve küme kurtarma işleminin başlamasını engelleyecektir. Önerilen değer 1 saniyedir.
• MASTER_RETRY_COUNT — maksimum yeniden bağlanma denemesi sayısı.
• MASTER_HEARTBEAT_PERIOD — Master'ın bir kalp atışı sinyali göndermesinden sonraki saniye cinsinden aralık. Varsayılan olarak değerin yarısına ayarlanır slave_net_timeout.

Orkestratör parametreleri:

• DelayMasterPromotionIfSQLThreadNotUpToDate - eğer eşitse true, kopyanın SQL iş parçacığı Geçiş Günlüğündeki tüm uygulanmamış işlemleri tamamlayana kadar aday kopyaya ana rol uygulanmayacaktır. Tüm aday replikalar geride kaldığında işlemleri kaybetmemek için bu seçeneği kullanırız.
• InstancePollSeconds — topolojinin oluşturulma ve güncellenme sıklığı.
• RecoveryPollSeconds — topoloji analizinin sıklığı. Bir sorun algılanırsa topoloji kurtarma işlemi başlatılır. Bu sabit1 saniyeye eşittir.

Her küme düğümü, orkestratör tarafından her seferinde bir kez yoklanır InstancePollSeconds saniye Bir sorun tespit edildiğinde küme durumu zorlanır güncellenmişve ardından kurtarmanın gerçekleştirilmesi için nihai karar verilir. Farklı veritabanı ve orkestratör parametreleriyle denemeler yaparak yanıt ve kurtarma süresini 30 saniyeye indirmeyi başardık.

deneme standı

Yerel bir programın geliştirilmesiyle HA planını test etmeye başladık. Test tezgahı ve test ve üretim ortamlarında daha fazla uygulama. Yerel stand, Docker'ı temel alarak tamamen otomatikleştirilmiştir ve orkestratör ve ağ yapılandırmasını denemenize, kümeyi 2-3 sunucudan birkaç düzineye kadar ölçeklendirmenize ve güvenli bir ortamda alıştırmalar yapmanıza olanak tanır.

Alıştırmalar sırasında problem öykünme yöntemlerinden birini seçiyoruz: kullanarak ustayı anında vurun kill -9, işlemi yumuşak bir şekilde sonlandırın ve sunucuyu durdurun (docker-compose stop), kullanarak ağ sorunlarını simüle edin iptables -j REJECT veya iptables -j DROP. Aşağıdaki sonuçları bekliyoruz:

• orkestratör, ana birimdeki sorunları tespit edecek ve topolojiyi 10 saniyeden fazla olmayacak bir sürede güncelleyecektir;
• kurtarma prosedürü otomatik olarak başlayacaktır: ağ yapılandırması değişecek, yöneticinin rolü kopyaya geçecek, topoloji yeniden oluşturulacak;
• yeni ana kopya yazılabilir hale gelecek ve yeniden oluşturma işlemi sırasında canlı kopyalar kaybolmayacaktır;
• veriler yeni ana belleğe yazılmaya ve çoğaltılmaya başlanacak;
• Toplam iyileşme süresi 30 saniyeyi geçmeyecektir.

Bildiğiniz gibi sistem test ve üretim ortamlarında farklı donanım ve ağ konfigürasyonları, sentetik ve gerçek yük farklılıkları vb. nedenlerden dolayı farklı davranabilmektedir. Bu nedenle, ağ bağlantısı kesildiğinde veya bireysel parçaları bozulduğunda sistemin nasıl davrandığını kontrol ederek periyodik olarak gerçek koşullarda tatbikatlar yapıyoruz. Gelecekte her iki ortam için de tamamen aynı altyapıyı oluşturmak ve testlerini otomatikleştirmek istiyoruz.

Bulgular

Ana depolama sistemi düğümünün sağlığı, SRE ve operasyon ekibinin ana görevlerinden biridir. Orkestratörün ve VIP tabanlı HA çözümünün uygulanması aşağıdaki sonuçları elde etmemizi sağladı:

• veritabanı kümesinin topolojisi ile ilgili sorunların güvenilir şekilde tespiti;
• Master ile ilgili olaylara otomatik ve hızlı tepki vererek sistem aksama süresini azaltır.

Ancak çözümün sınırlamaları ve dezavantajları vardır:

• HA planının birkaç veri merkezine ölçeklendirilmesi, aralarında tek bir L2 ağı gerektirecektir;
• Yeni master'a VIP atamadan önce eski master'da serbest bırakmamız gerekiyor. İşlem sıralıdır, bu da iyileşme süresini artırır;
• VIP'nin serbest bırakılması, sunucuya SSH erişimini veya uzaktan prosedürleri çağırmanın başka herhangi bir yöntemini gerektirir. Sunucu veya veritabanında kurtarma işlemine neden olan sorunlar yaşandığından VIP kaldırma işleminin başarıyla tamamlanacağından emin olamayız. Bu da aynı sanal IP adresine sahip iki sunucunun ortaya çıkmasına ve bir soruna yol açabilir split brain.

Kaçınmak split brainyöntemini kullanabilirsiniz STONİTH (“Diğer Düğümü Kafadan Vur”), sorunlu düğümü tamamen izole eder veya devre dışı bırakır. Küme yüksek kullanılabilirliğini uygulamanın başka yolları da vardır: VIP ve DNS'nin bir kombinasyonu, hizmet keşfi ve proxy hizmetleri, eşzamanlı çoğaltma ve kendi dezavantajları ve avantajları olan diğer yöntemler.

MySQL yük devretme kümesi oluşturma yaklaşımımızdan bahsettim. Uygulanması kolaydır ve mevcut koşullar altında kabul edilebilir düzeyde güvenilirlik sağlar. Genel olarak tüm sistem, özel olarak da altyapı geliştikçe bu yaklaşım da şüphesiz gelişecektir.

Kaynak: habr.com