Herhangi bir büyük proje birkaç sunucuyla başlar. İlk başta bir DB sunucusu vardı, daha sonra okumayı ölçeklendirmek için ona köleler eklendi. Ve sonra - dur! Bir efendi var ama çok sayıda köle var; kölelerden biri ayrılırsa her şey yoluna girecek, ancak efendi ayrılırsa kötü olacak: kesinti, yöneticiler sunucuyu yükseltmeye çalışıyor. Ne yapalım? Bir usta rezerve edin. Meslektaşım Pavel bunu zaten yazdı , tekrarlamayacağım. Bunun yerine, MySQL için Orchestrator'a neden kesinlikle ihtiyaç duyduğunuzu anlatacağım!
Ana soruyla başlayalım: “Master ayrıldığında kodu yeni bir makineye nasıl geçireceğiz?”
- En çok VIP (Sanal IP) şemasını beğendim, aşağıda bundan bahsedeceğiz. En basit ve en belirgin olanıdır, ancak bariz bir sınırlaması vardır: Rezerve edeceğimiz master, yeni makine ile L2 segmentinde olmalıdır, yani ikinci DC'yi unutabiliriz. Ve dostane bir şekilde, büyük L2'nin kötü olduğu kuralını izlerseniz, çünkü L2 yalnızca raf başınadır ve L3 raflar arasındadır ve böyle bir planın daha da fazla kısıtlaması vardır.
- Koda bir DNS adı yazıp /etc/hosts aracılığıyla çözümleyebilirsiniz. Aslında hiçbir çözüm olmayacak. Planın avantajı: İlk yöntemin hiçbir sınırlama özelliği yoktur, yani bir çapraz DC düzenlemek mümkündür. Ancak o zaman bariz soru ortaya çıkıyor: Değişikliği Puppet-Ansible aracılığıyla /etc/hosts dosyasına ne kadar hızlı iletebiliriz?
- İkinci yöntemi biraz değiştirebilirsiniz: Kodun ana veritabanına gideceği tüm web sunucularına önbellekleme DNS'sini yükleyin. DNS'deki bu giriş için TTL 60'ı ayarlayabilirsiniz. Doğru uygulandığında yöntemin iyi olduğu görülüyor.
- Konsolosluk vb. kullanımını ima eden, hizmet keşfi içeren bir plan.
- İle ilginç bir seçenek . Tüm trafiği ProxySQL aracılığıyla MySQL'e yönlendirmeniz gerekir; ProxySQL'in kendisi kimin yönetici olduğunu belirleyebilir. Bu arada, bu ürünü kullanma seçeneklerinden birini kitabımda okuyabilirsiniz. .
Github'da çalışan Orchestrator'ın yazarı, ilk şemayı önce VIP ile uyguladı, ardından bunu konsoloslu bir şemaya dönüştürdü.
Tipik altyapı düzeni:
Dikkate alınması gereken bariz durumları hemen anlatacağım:
- VIP adresi hiçbir sunucudaki yapılandırmaya kaydedilmemelidir. Bir durum hayal edelim: Master yeniden başlatıldı ve yüklenirken Orchestrator yük devretme moduna geçti ve kölelerden birini master yaptı; sonra eski usta yükseldi ve şimdi VIP iki arabada. Bu kötü.
- Orkestratör için, eski yöneticiyi ve yeni yöneticiyi çağırmak için bir komut dosyası yazmanız gerekecektir. Eski master'da ifdown'u, yeni master'da ise ifup vip'i çalıştırmanız gerekiyor. Bu komut dosyasına, bir yük devretme durumunda, herhangi bir bölünmüş beyinden kaçınmak için eski ana makinenin anahtarındaki bağlantı noktasının basitçe kapatılacağını da eklemek güzel olurdu.
- Orchestrator, önce VIP'yi kaldırmak ve/veya anahtardaki bağlantı noktasını söndürmek için komut dosyanızı çağırdıktan ve ardından yeni ana cihazda VIP yükseltme komut dosyasını çağırdıktan sonra, herkese yeni VIP'nin artık geçerli olduğunu söylemek için arping komutunu kullanmayı unutmayın. Burada.
- Tüm kölelerin salt okunur=1 olması gerekir ve köleyi ana öğeye yükselttiğinizde salt okunur=0 olmalıdır.
- Bunun için seçtiğimiz herhangi bir kölenin usta olabileceğini unutmayın (Orchestrator'ın yeni bir usta için ilk etapta hangi köleyi aday olarak değerlendireceği, ikinci sırada hangi köleyi değerlendireceği ve hangi kölenin olması gerektiği konusunda tam bir tercih mekanizması vardır. hiçbir koşulda seçilmemelidir usta). Köle efendi olursa kölenin yükü onun üzerinde kalacak ve efendinin yükü de eklenecektir, bu dikkate alınmalıdır.
Orkestratörünüz yoksa neden Orkestratöre ihtiyacınız var?
- Orchestrator, topolojinin tamamını görüntüleyen oldukça kullanıcı dostu bir grafik arayüze sahiptir (aşağıdaki ekran görüntüsüne bakın).
- Orkestratör hangi kölelerin geride kaldığını ve çoğaltmanın genel olarak nerede bozulduğunu izleyebilir (SMS göndermek için Orkestratöre eklenmiş komut dosyalarımız vardır).
- Orkestratör size hangi kölelerin GTID hatasına sahip olduğunu söyler.
Orkestratör Arayüzü:
GTID hatası nedir?
Orkestratörün çalışması için iki temel gereksinim vardır:
- MySQL kümesindeki tüm makinelerde sözde GTID'nin etkinleştirilmesi gerekir; GTID'yi etkinleştirdik.
- Her yerde tek tip binlog olması gerekiyor, deyimi kullanabilirsiniz. Ana ve çoğu kölenin Satıra sahip olduğu ve ikisinin tarihsel olarak Karma modda kaldığı bir yapılandırmamız vardı. Sonuç olarak Orkestratör bu köleleri yeni yöneticiye bağlamak istemedi.
Bir üretim kölesinde en önemli şeyin efendiyle tutarlılığı olduğunu unutmayın! Hem ana makinenizde hem de ikincil makinenizde Küresel İşlem Kimliği'ni (GTID) etkinleştirdiyseniz, gtid_subset işlevini kullanarak aynı veri değişikliği taleplerinin bu makinelerde gerçekten yürütülüp yürütülmediğini öğrenebilirsiniz. Bu konuda daha fazlasını okuyabilirsiniz .
Böylece Orkestratör, GTID hatası aracılığıyla size kölede ana bilgisayarda olmayan işlemlerin olduğunu gösterir. Bu neden oluyor?
- Read_only=1 ikincil cihazda etkin değil, birisi bağlandı ve verileri değiştirme isteğini tamamladı.
- Super_read_only=1 köle üzerinde etkinleştirilmedi, ardından sunucunun kafasını karıştıran yönetici içeri girdi ve isteği orada yürüttü.
- Önceki her iki noktayı da hesaba kattıysanız, bir püf noktası daha var: MySQL'de, binlog'ları temizleme isteği de binlog'a gider, böylece ilk yıkamada, ana ve tüm yardımcılarda hatalı bir GTID görünecektir. Bundan nasıl kaçınılır? Perona-5.7.25-28, binlog'lara düz yazmayı yasaklayan binlog_skip_flush_commands=1 ayarını tanıttı. Mysql.com web sitesinde yerleşik bir tane var .
Yukarıdakilerin hepsini özetleyeyim. Henüz Orchestrator'ı yük devretme modunda kullanmak istemiyorsanız gözlem moduna geçirin. O zaman her zaman gözlerinizin önünde MySQL makinelerinin etkileşiminin bir haritası ve her makinede ne tür bir çoğaltma olduğu, kölelerin geride kalıp kalmadığı ve en önemlisi ana makineyle ne kadar tutarlı oldukları hakkında görsel bilgiler olacak!
Açıkça sorulan soru şudur: "Orkestratör nasıl çalışmalıdır?" Mevcut kölelerden yeni bir yönetici seçmeli ve ardından tüm bağımlıları ona yeniden bağlamalıdır (GTID bunun için gereklidir; binlog_name ve binlog_pos ile eski mekanizmayı kullanıyorsanız, ardından bir köleyi mevcut yöneticiden yenisine değiştirmelisiniz) kesinlikle imkansızdır!). Orkestratörümüz olmadan önce tüm bunları manuel olarak yapmak zorunda kalıyordum. Eski usta, hatalı bir Adaptec denetleyicisi nedeniyle asılıydı; yaklaşık 10 kölesi vardı. VIP'yi ana cihazdan kölelerden birine aktarmam ve diğer tüm köleleri ona yeniden bağlamam gerekiyordu. Kaç konsol açmam gerekiyordu, kaç tane eş zamanlı komut girdim... Gece 3'e kadar beklemem, ikisi hariç tüm kölelerin yükünü kaldırmam, iki master'dan ilk makineyi yapmam, hemen ikinci makineyi takmam gerekiyordu. buna göre diğer tüm köleleri yeni yöneticiye bağlayın ve yükü geri verin. Genel olarak korkunç...
Orchestrator yük devretme moduna geçtiğinde nasıl çalışır? Bu, en kolay şekilde, bir ustayı şu anda sahip olduğumuzdan daha güçlü, daha modern bir makine yapmak istediğimiz bir durum örneğiyle açıklanabilir.
Şekil sürecin ortasını göstermektedir. Bu noktaya kadar zaten ne yapıldı? Bazı köleleri yeni efendi yapmak istediğimizi söyledik. Orkestratör, yeni efendinin bir geçiş makinesi gibi davranmasıyla diğer tüm köleleri ona yeniden bağlamaya başladı. Bu şemada hiçbir hata oluşmaz, tüm köleler çalışır, Orkestratör VIP'yi eski yöneticiden çıkarır, yenisine aktarır, read_only=0 yapar ve eski yöneticiyi unutur. Tüm! Hizmetimizin kesinti süresi 2-3 saniye olan VIP transfer süresidir.
Bugünlük bu kadar, herkese teşekkür ederim. Yakında Orchestrator ile ilgili ikinci bir makalemiz olacak. Ünlü Sovyet filmi “Garaj”da bir karakter şöyle dedi: “Onunla keşfe çıkmam!” O halde Orkestratör, ben de sizinle keşif gezisine gelirim!
Kaynak: habr.com