MySQL Grup Replikasyonu (MGR), MySQL'in ikili günlük (binary log) mekanizmasına dayanan ve Paxos protokolü kullanılarak uygulanan dağıtık bir replikasyon modudur. RDS Cluster Edition kullanan ApsaraDB RDS for MySQL örnekleri MGR'yi destekler.
Geleneksel replikasyon asenkron veya yarı senkron çalışır: Birincil düğüm işlemi ikili günlüğüne yazar ve ikincil düğümlere iletir; ancak arıza oluşmadan önce ikincil düğümlerin veriyi aldığına dair garanti bulunmaz. MGR temelden farklı bir yaklaşım benimser: Bir işlem commit edilmeden önce çoğunluk düğümün ikili günlükleri aldığını onaylaması gerekir. Bu çoğunluk onayı modeli, MGR'ye geleneksel replikasyon modlarına kıyasla daha güçlü veri garantileri sunar.
| Özellik | MGR | Yarı senkron replikasyon | Asenkron replikasyon |
|---|---|---|---|
| Veri güvenilirliği | ★★★★★ | ★★★ | ★ |
| Veri tutarlılığı | Sağlanır | Sağlanmaz | Sağlanmaz |
| Global işlem tutarlılığı | Desteklenir | Desteklenmez | Desteklenmez |
Avantajlar
Yüksek veri güvenilirliği
MGR, Paxos protokolünün çoğunluk kuralını kullanır: Bir işlem, RDS kümesindeki çoğu düğüm ikili günlüklerini aldıktan sonra commit edilir. Bu durum, azınlıktaki düğümlerde arıza meydana gelse bile veri kaybını önler.
Örneğin, 5 düğümlü bir kümede 3 düğüm ikili günlüklerini alırken 2 düğüm alamadığında:
Arızalı 2 düğüm ikili günlükleri alanlar arasında yer alıyorsa veriyi tutan en az 1 düğüm çalışmaya devam eder.
Arızalı 2 düğüm ikili günlükleri almayanlar arasında yer alıyorsa veriyi tutan 3 düğümün tamamı çalışmaya devam eder.
Güçlü veri tutarlılığı
Geleneksel birincil-ikincil replikasyonda birincil düğüm, işlemi ikili günlüğe yazdıktan ancak ikincil düğümlere iletmeden önce başarısız olursa veri tutarsızlığı ortaya çıkar. MGR bunu engeller: İşlemler ikili günlüğe yazılmadan önce diğer düğümlere iletilir; bu sayede commit edilen her işlem zaten çoğunluk düğümde bulunur.
Birincil düğüm başarısız olup yeniden başlatıldığında kümeye otomatik olarak yeniden katılır ve eksik ikili günlükleri senkronize ederek güncel duruma gelir.
Global işlem tutarlılığı
Okuma ve yazma işlemleri için tutarlılık düzeyini kontrol etmek üzere group_replication_consistency parametresini ayarlayın:
Güçlü okuma tutarlılığı (ikincil düğümlerde
group_replication_consistency=BEFORE): Sorgu, birincil düğümde kendisinden önce gelen tüm işlemler tamamlanana kadar yürütülmez. Bu sayede ikincil düğümlerdeki okumaların asla eski veri döndürmemesi garanti edilir.Güçlü yazma tutarlılığı (birincil düğümde
group_replication_consistency=AFTER): Yazma işlemi, tüm düğümlerde başarıyla uygulanana kadar commit edilmez.
Dağıtım yöntemleri
MGR iki dağıtım modunu destekler. Aşağıdaki tablo, iş yükünüz için doğru modu seçmenize yardımcı olmak amacıyla bu modların yeteneklerini ve ödünleşimlerini karşılaştırır.
| Çoklu lider | Tekli lider | |
|---|---|---|
| Yazma düğümleri | Tüm düğümler | Yalnızca birincil düğüm |
| Okuma düğümleri | Tüm düğümler | Birincil olmayan tüm düğümler |
| Yazma aktarım hızı | Daha yüksek (düğümler arasında paralel yazma) | Daha düşük (tek yazma yolu) |
| Okuma aktarım hızı | Standart | Daha yüksek (salt okunur düğümler optimize edilmiştir) |
| Azınlık düğüm arızalarında kullanılabilirlik | Düşük — anket sırasındaki arızalı düğümden sonraki düğümler veri gönderemez | Etkilenmez — çoğunluk düğüm kullanılabilir olduğu sürece küme çalışmaya devam eder |
| Birincil düğüm arızasında birincil/ikincil geçişi | Yok | Paxos protokolüne dayalı olarak otomatik |
| Veri tutarlılığı garantisi | Güçlü | Güçlü |
Çoklu lider
Tüm düğümler hem okuma hem de yazma isteklerini işler. Çoklu lider modu, Paxos mekanizmalarını kullanarak birden fazla kaydı aynı anda yazar ve satır düzeyinde çakışmaları algılar; böylece tüm düğümler veriyi aynı sırayla alır ve yazma aktarım hızı artar.
Sınırlama: Bir düğümde titreme veya arıza yaşandığında anket sıralamasında bu düğümden sonra gelen düğümler veri gönderemez. Bu durum kümenin geçici olarak kullanılamaz hale gelmesine neden olur. Bu, çoklu lider modunun ortadan kaldırılamayan doğal bir sınırlamasıdır.
Tekli lider
Yalnızca bir düğüm yazma isteklerini işler; diğer tüm düğümler okuma isteklerini işler. Tekli lider modu, Paxos protokolünün tek liderli replikasyon stratejisini kullanarak okuma aktarım hızını en üst düzeye çıkarır ve yüksek kullanılabilirliği korur:
Bir ikincil düğüm başarısız olursa ve çoğunluk düğüm kullanılabilir kalırsa küme kesintisiz çalışmaya devam eder.
Birincil düğüm başarısız olursa küme, Paxos protokolüne dayalı olarak otomatik bir birincil/ikincil geçişi gerçekleştirir ve güçlü veri tutarlılığını korur.
ApsaraDB RDS for MySQL, tekli lider modunda MGR kullanan RDS kümeleri oluşturmayı destekler. Bu modda, salt okunur düğümler küme performansını iyileştirmek üzere optimize edilirken yüksek veri güvenilirliği ve güçlü veri tutarlılığı sağlanır.
Mimari
MGR, MySQL'in sunucu ve çoğaltma katmanlarının altına üç ek katman yerleştirir:
| Katman | Rolü |
|---|---|
| Grup replikasyonu mantık katmanı | MySQL'in sunucu katmanıyla etkileşime girerek işlemleri grup iletişim sistemi (GCS) katmanına gönderir ve buradan alır, ayrıca işlemleri uygular |
| GCS katmanı | Mesajları iletir, arızaları tespit eder ve küme üyeliğini yönetir |
| XCom katmanı | Paxos protokolüne dayanarak veri sırası tutarlılığını ve çoğunluk düğüm kullanılabilirliğini sağlar |
Paxos protokolü
Paxos protokolü MGR'de iki işlevi yerine getirir:
Kümedeki tüm düğümlerin bir işlemin ikili günlüklerini aynı sırada almasını sağlar. Bu durum çoklu lider modu için gereklidir.
Bir işlemin, ikili günlüklerinin alındığına dair çoğunluk düğümden onay alınana kadar commit edilmemesini sağlar.
XCom katmanı, Paxos tabanlı bir varyant olan Mencius protokolüne dayanır. Bu protokol, Paxos'un kilitlemeye dayalı sıralamasını anket mekanizmasıyla değiştirir. Böylece düğümler arasında yük dengeleme sağlanır ve genel verimlilik artırılır.
Çoklu lider modunun çalışma şekli
Çoklu lider modunda her düğüm bir Paxos grubuna aittir. XCom katmanı, tutarlı bir global veri sırası sağlamak için iki mekanizma kullanır:
Grup içinde seri gönderim: Her gruptaki veri, grup içi sıralama tutarlılığını sağlamak amacıyla seri olarak gönderilir.
Gruplar arasında anket: Birden fazla grup veri gönderdiğinde global düzeyde tutarlı bir sıra sağlamak için anket mekanizması devreye girer. Örneğin, veriler (1,1), (1,2), (1,3) sırasıyla gönderilir.
(m,n) gösteriminde n grup numarasını, m ise o grubun gönderdiği veri kaydının sıra numarasını ifade eder. Örneğin, (2,1) ifadesi 1. Grubun ikinci veri kaydını gönderdiği anlamına gelir.
noop mekanizması boşta kalan düğümleri yönetir: Bir düğümün gönderecek verisi yoksa ancak kendisinden sonra gelen düğümlerden gelen veriler küme çoğunluğu tarafından zaten alındıysa düğüm, kendini atlayarak anket sırasındaki sonraki düğümün engellenmesini önlemek için bir noop durumu yayınlar.
Tekli lider modunun çalışma şekli
Tekli lider modunda yazma işlemlerini yalnızca bir düğüm gönderdiği için sadece bir Paxos grubunun etkin olması yeterlidir. Alıcı, anket sırasında diğer tüm Paxos gruplarını yoksayar. Bu yaklaşım, çoklu lider modunda görülen noop kaynaklı kullanılabilirlik sorununu ortadan kaldırır: Çoğunluk düğüm kullanılabilir olduğu sürece bireysel düğüm arızalarına rağmen küme çalışmaya devam eder.
Tekli lider modundaki ikincil düğümler işlem göndermez; yalnızca küme yönetimi bilgilerini iletir. İkincil bir düğüm herhangi bir veri göndermeden önce birincil düğümden bir gönderim yuvası talep etmelidir. Yukarıdaki diyagramda <3,1> gösterimi böyle bir yuvayı temsil eder. Küme yönetimi mesajları seyrek olduğundan bu yuva talep mekanizmasının gecikme yükü küme aktarım hızı üzerinde anlamlı bir etki yaratmaz.
Grup replikasyonu mantık katmanı
Grup replikasyonu mantık katmanı, hem birincil hem de ikincil düğümlerde işlem yayılımını ve çakışma tespitini yönetir.
Birincil düğüm akışı:
Bir işlem commit edilmeden önce grup replikasyonu mantık katmanı ikili günlüklerini XCom katmanına gönderir ve XCom bunları diğer tüm düğümlere yayınlar. Çoğunluk düğüm alımı onayladıktan sonra çakışma tespiti çalıştırılır:
Başarılı: İşlem ikili günlük dosyasına yazılır ve commit edilir.
Başarısız: İşlem geri alınır.
İkincil düğüm akışı:
Çoğunluk düğüm bir işlemi onayladıktan sonra XCom katmanı bunu çakışma tespiti için grup replikasyonu mantık katmanına iletir:
Başarılı: İşlem röle günlük dosyasına yazılır ve uygulayıcı iş parçacığı tarafından uygulanır.
Başarısız: İşlem verisi atılır.
Çakışma tespiti
Çakışma tespitinin gerekli olduğu durumlar:
Çoklu lider modu: Birden fazla düğüm eşzamanlı olarak yazma kabul edebildiği için her yazma işleminde gereklidir.
Tekli lider modu: Yalnızca birincil/ikincil geçişi sırasında ve yeni birincil düğüme orijinal birincilden gelen röle günlükleri tamamen uygulanmadan önce yazma işlemleri ulaştığında gereklidir.
Çalışma şekli:
Her düğüm, işlem kimlik doğrulama bilgilerinden oluşan bir karma dizisi tutar:
Anahtar: Değiştirilen bir veri satırının (birincil anahtara dayalı olarak) karma değeri.
Değer: Geçerli işlemin global işlem tanımlayıcısı (GTID) ile
gtid_executeddeğerlerinin birleşimi; yani geçerli işlem commit edilmeden önce kaynak düğümde commit edilen tüm GTID'lerin kümesi.
Bir işlem commit edilmeden önce her düğüm, işlem tarafından değiştirilen tüm satırların karma değerlerini kimlik doğrulama dizisinde arayarak bir bağımlılık kümesi oluşturur. Bağımlılık kümesi, geçerli işlemin güvenli bir şekilde commit edilebilmesi için önceden tamamlanmış olması gereken tüm işlemleri temsil eder.
Sistem daha sonra işlemin commit kümesini (kaynak düğümde bu işlemden önce commit edilen işlemler) bağımlılık kümesiyle karşılaştırır:
Commit kümesi bağımlılık kümesini içeriyorsa işlem çakışma tespitinden geçer, kaynak düğümde commit edilir ve diğer düğümlerdeki röle günlüklerine yazılır.
Commit kümesi bağımlılık kümesini içermiyorsa işlem çakışma tespitinden başarısız olur, kaynak düğümde geri alınır ve diğer düğümlerdeki röle günlük verileri atılır.
Eski kimlik doğrulama verilerinin silinmesi:
Bir işlem kümedeki tüm düğümlerde uygulandıktan sonra ilgili satırlar kimlik doğrulama dizisinden kaldırılabilir. MGR, eski kimlik doğrulama verilerini her 60 saniyede bir temizler.
MGR kararlılığı için AliSQL optimizasyonları
Tekli lider modu MGR kararlılığını önemli ölçüde artırır ancak belirli bir senaryo sorunlu olmaya devam eder: Bir ikincil düğüm yüksek gecikme süresi yaşadığında işlemleri yeterince hızlı uygulayamaz ve bu durum kimlik doğrulama bilgilerinin birikmesine neden olur. Bu durum iki soruna yol açar:
Yüksek bellek tüketimi ve bellek yetersizliği (OOM) hataları riski.
Birikmiş kimlik doğrulama verilerinin periyodik olarak temizlenmesinden kaynaklanan yüksek ek yük, bu da küme performansını düşürür.
AliSQL, her düğümde tutulan kimlik doğrulama bilgisi hacmini azaltarak bu sorunu ele alır:
Birincil düğüm: Tekli lider modunda birincil düğümdeki kimlik doğrulama dizisi çakışma tespiti için hiçbir zaman kullanılmaz. AliSQL bu diziyi tamamen kaldırarak bellek ve temizleme ek yükünü ortadan kaldırır.
İkincil düğüm: Kimlik doğrulama bilgilerine yalnızca
group_replication_consistencyparametresiEVENTUALolarak ayarlandığında ihtiyaç duyulur.EVENTUALayarı, yeni seçilen bir birincil düğümün röle günlük oynatmasının tamamlanmasını beklemeden hemen harici trafiği hizmet etmesine olanak tanır; bu durum veri çakışmalarına neden olabilir ve üretim ortamlarında nadiren kullanılır.EVENTUALkullanılmadığında AliSQL ikincil düğümlerden de kimlik doğrulama dizisini kaldırarak bellek tüketimini önemli ölçüde azaltır ve küme kararlılığını artırır.