Yedekten Öteyi Konuşalım: MariaDB Galera Cluster ve MySQL Group Replication ile Kesintisizliğe Sıcak Bir Yolculuk

Bir Disk LED’inin Düşündürdükleri: Yedekten Öte Ne Vardır?

Hiç sabahın köründe ofise girip, sunucu odasında o minik disk LED’lerinin nefes alır gibi yanıp söndüğünü izlediniz mi? O günlerden birinde, beklenmedik bir kesinti yüzünden sipariş kuyruğu yerde sürünürken, hepimizin diline dolanan aynı cümle dökülmüştü: “Yedeğimiz var, değil mi?” Var tabii, ama yedek başka bir şey; yüksek erişilebilirlik bambaşka. Yedek dosyaları, başınıza bir iş geldiğinde geçmişe dönmek içindir; yüksek erişilebilirlik ise o kötü anı yaşatmamak, sisteminize ince bir esneklik katmaktır.

Bugün tam da bu köprüyü geçmeye niyetliyim. MariaDB tarafında Galera Cluster ile MySQL dünyasında Group Replication’ı, bir mühendis masasında kahve eşliğinde konuşur gibi ele alacağız. Nerede parlıyorlar, nerede ince ayar istiyorlar, ağ gecikmesi nasıl surat asıyor, uygulama desenleri ne söylüyor… Hepsini gerçek hayattan örneklerle, mesela gecenin 03:00’ünde alarm çalarken insanın aklından geçenlerle birlikte anlatacağım. En sonunda elinizde, “Bizim senaryoya hangisi daha yakışır?” diye sorunca daha net bir iç ses oluşsun istiyorum.

Galera ile İlk Randevu: Çoklu-ana, Tek Bir Kalp Atışı

Galera ile tanıştığım günlerden birinde, üç düğümlü küçük bir kümeyi ayağa kaldırmıştım. İlk izlenim, düğümlerin birbirine inanılmaz sıkı sarıldığıydı. Yazılan her şey sanki tek bir kalpte onaylanıyor, sonra aynı ritimle tüm düğümlere yayılıyordu. Çoklu-ana hissi sıcak; çünkü herhangi bir düğüme yazabiliyorsunuz. Ama bu özgürlük, ince bir dengeyi de beraberinde getiriyor: Yazı yükünüz aynı tabloda, aynı satırlara abanıyorsa, o kalbin atışı bazen hızlanıyor, bazen durup “bir dakika” diyor. Bu “bir dakika”, Galera’nın akış kontrolüdür; kısaca, daha yavaş olan düğümler yetişsin diye sizi biraz yavaşlatır.

Mesela şöyle düşünün: Bir oyun salonunda üç arkadaş aynı atari makinesini oynuyor. Her hamle tüm ekranlara aynı anda gitmek zorunda; yoksa skorlar şaşar. Eğer bir ekran gecikirse, diğerleri onu bekler. Galera, işte bu eşgüdümü çok ciddiye alır. Bunun güzelliği, bir düğüm düşse bile diğerlerinin aynı kararlılıkla devam etmesidir. Fakat bu düzen, uzun süren büyük işlemlerden pek hoşlanmaz. Büyük bir tablo güncellemesi, herkesin aynı anda adım atmasını beklediğinden, ritmi düşürebilir. Ben böyle anlarda, veriyi parça parça, kısa nefeslerle çiğneyip yutmayı tercih ederim. Kocaman lokmalar hep mideyi bozar.

Galera’nın kurulumu görece berraktır. Yazdığınız her işlemin deterministik olmasını ister; yani “aynı girişten aynı çıkış” bekler. Bu nedenle, adımlarınız düzenliyse, karşılığını net bir uyumla alırsınız. Bir kere, yeni bir düğüm katılacaksa onu kümenin yanına kibarca oturtmanız gerekir. İlk eşitleme sırasında tam kopya (SST) ile başlar, uygun durumdaysa parça parça artımlı kopya (IST) ile devam edebilir. Ben çoğu zaman Percona XtraBackup ile çevrimiçi kopya alma yolunu seçiyorum; hem sıcak, hem güvenli bir yaklaşım.

Bu noktada, farklı platformların üzerine kurulu uygulamalar için okuma ve yazma desenlerini iyi tanımak şart. Eğer ağırlıklı okuma trafiğiniz var, yazı az ve kısa nefesliyse, Galera’nın çoklu-ana rahatlığı basit bir yük dengeleme ile tatlı bir dengede kalır. Tam tersine, yoğun yazı ve aynı satırlara sürekli dokunan bir düzen söz konusuysa, topu tek bir düğüme paslamak ve diğerlerini okumaya ayırmak bazen daha huzurlu bir hayat sağlar. Bu fikri, WooCommerce’de okuma/yazma mimarisi üzerine detaylı notlar arasında daha somut örneklerle de ele almıştık.

Galera’nın dokümantasyonu net ve sahada işe yarar ipuçlarıyla doludur. Mimariyi merak edip daha derine inmek isterseniz, Galera Cluster mimarisi hakkında resmi rehber sade bir başlangıç noktasıdır. Bazen bir şemanın altındaki tek cümle, günlerce sürecek bir deneme-yanılmanın önüne geçer.

MySQL Group Replication: Takım Oyunu, Otomatik Düzen

Group Replication ile ilk projelerimde hissettiğim şey, “takım oyunu” idi. MySQL’in kendi evinin içinde büyüyen bir düzen olduğu için, tanıdık bir disiplinle davranır. İsterseniz tek-ana modunda, isterseniz çoklu-ana modunda ilerlersiniz; fakat günlük hayatta çoğu ekip tek-ana ile başlar. Neden mi? Çünkü yazı yarışına pek girmek istemeyiz; kavgada kim kazanırsa kazansın, gecenin bir yarısı hata düğümünü aramak istemezsiniz. Tek-ana düzen, basitlik sunar ve devreye alma sürecini rahatlatır.

İşin güzel tarafı, küme kendi sağlığını izler ve liderlik seçiminde kararlıdır. Bazı ortamlarda, otomatik katılım ve ayrılma davranışının net olması, yeni düğüm eklemek gibi sıradan işleri “seremoni” olmaktan çıkarır. Burada dikkat edilen konulardan biri, işlemlerin masaya nasıl geldiğidir. Çakışan yazılarda, daha geç gelen işlemin nazikçe geri çevrildiğini görürsünüz. Uygulama katmanında bu duruma hazır olmak gerekir; kısa bir yeniden deneme döngüsü çoğu zaman yeterlidir.

Benim hoşuma giden bir taraf, yönetimsel komutların ve durum değişkenlerinin adeta bir pano gibi her şeyi göstermesidir. Kümenin mevcut durumu, gecikmeler, rol dağılımı… Hepsi elinizin altındadır. Yine de, “Veri merkezleri arası çoklu-ana, yazı trafiğinin ortasında” gibi zorlu senaryolarda, ağ gecikmesinin tatsız sürprizlerini unutmayın. Uzak mesafeler, saniyelere değil, milisaniyelere bile hassastır. Bu yüzden, mimari çizimini ilk yaptığınız gün, haritaya cetvelle mesafe çizmekte yarar var. MySQL’in resmi kılavuzu olan Group Replication dokümantasyonu bu konuda temiz ipuçları verir.

Bu arada, “proxy” seçimi bu iki dünyada da aynı derecede önemlidir. Basit bir HAProxy veya ProxySQL ile yazı-yönlendirme ve okuma-dağıtımı gayet düzenli hale gelir. Uygulamanız tek bir bağlantı havuzu gibi düşünür; alttaki akrobasi proxy katmanında biter. Bir müşteri projesinde, tek-ana modunda çalışan Group Replication üzerinde ProxySQL ile altın üçlüye ulaşmıştık: basit yönlendirme, hızlı failover ve sade bir gözlemleme.

Gerçek Dünya Örnekleri: Mağaza, SaaS ve İç Sistemler

Bir e-ticaret vitrininin Cuma akşamı yaşadığı telaşı hayal edin. Sepete ekle, kupon uygula, ödeme onayı derken, yazı trafiği zıplar. Ödeme adımında tek bir satırın birden fazla işlem tarafından itelenmesi kadar kalp çarpıtan az şey vardır. Ürün stokları, kupon kullanım sayıları, sipariş tablosu… Hepsi aynı anda ışıldar. Böyle bir yerde, Galera’nın çoklu-ana rahatlığı cazip gelir; ancak aynı satır güncellemeleri sıklaştıkça ritim düşebilir. Bu yüzden kimi zaman tek bir yazı düğümü belirleyip, diğer düğümleri okumaya ayırmak, mağazanın nefesini ritimde tutar. Aynı senaryoda Group Replication’ı tek-ana modda kullanırken de benzer huzuru yakalayabilirsiniz; üstelik otomatik liderlik devri için sırayı beklemeyi seviyorsanız, işler şık ilerler.

SaaS projeleri, özellikle çok kiracılı yapılar, farklı davranır. Bir müşteri verisi diğerine pek çarpmazsa, yazı çakışmaları az olur. Bu durumda Galera’nın çoklu-ana imkânı daha rahat hissedilir; bölge bölge yazı alıp, okumaları yerel tutmak, gecikmeyi azaltır. Fakat şehirler arası bir düzen kuracaksanız, gecikme kavgası her zaman masadadır. Çoklu-ana yerine, bölgesel tek-ana ve yerel okumalarla ilerlemek daha sağlıklıdır. Hangi düzen olursa olsun, DNS tarafında akıllı yönlendirme ile kullanıcıyı en yakın kapıya almak iyi hissettirir; bunun için coğrafi ve ağırlıklı DNS yönlendirmesi üzerine sıcak bir yolculuk yazısına göz atabilirsiniz.

İç sistemler, mesela raporlamanın ağır bastığı bir ERP, daha sakin bir akışa yaslanır. Burada büyük raporların yarattığı uzun okuma oturumları, yazı trafiğiyle sataşabilir. Galera’da akış kontrolünü tetikleyen bu uzun işlemleri, rapor kopyalarını ayrı bir düğüme taşıyarak yumuşatmak mümkündür. Group Replication’da da benzer düşünce geçerlidir; okumayı sakin bir düğüme aktarıp, ana düğümü kısa ve net yazılar için huzurlu tutarsınız. Raporlama pencerelerini geceye alıp, uygulamayı daha küçük parçalara böldüğünüzde, veritabanı da size teşekkür eder.

Operasyonun Mutfağı: Kurulum, Bakım ve Yükseltme Endişesini Yatıştırmak

Kurulumun ilk günü, her şey umut vericidir; gerçek sınav ikinci ayın pazartesi sabahıdır. Güncellemeler, güvenlik yamaları, indeks değişimleri… Hepsi bir şekilde sıfır kesinti hedefine yaslanır. Galera tarafında, döngüsel güncelleme yapmak günlük hayattır. Bir düğümü bakıma alırsınız, güncellersiniz, geri getirirsiniz; sıra diğerine gelir. Uygulama tarafında bağlantıları bir süreliğine diğer düğümlere kaydırmak, taşları yerinden oynatmadan ilerlemenizi sağlar. Benzer bir yaklaşımı Group Replication ile de uygulamak mümkün. Tek-ana modda, lider değişimini planlı bir ana pencereye alıp, öncesinde bağlantı havuzlarını yumuşakça yönlendirdiğinizde, kullanıcıların kulağına sadece fon müziği çalar.

Bu süreçleri korkulacak olmaktan çıkarmak için, dağıtım hattınızı beslemek şart. Bir projede, uygulama tarafını sıfır kesinti CI/CD adımları ile sadeleştirdiğimizde, veritabanı bakımları da daha özgüvenli ilerledi. Çünkü sorun çıktığında geri dönüş yolunuz belliyse, cesur adımlar atmak kolaylaşır. Aynı hissi, geliştirme–staging–canlı yolculuğunu disipline ederek de yakalarsınız. Düğüm güncellemeleri sırasında uygulama sürümlerinin de uyumlu olmasına dikkat edin; protokol ve sürüm uyuşmazlıklarının çoğu, önceden planlanan küçük bir bakım penceresiyle buhar olur gider.

Yedeklemeyi burada tekrar anmak da adil. Yüksek erişilebilirlik, yedeklemenin yerine geçmez; ikisi el ele yürür. Galera’da bir düğüm donör olurken, üretim yükünü incitmeyecek ayrıntılar önemlidir. Group Replication tarafında da, yedek alma penceresinin ana düğümü boğmaması gerekir. Uzak depolamaya akan artımlı yedekler hem içinizi rahatlatır hem de deneme–geri dönüş pratiklerini kolaylaştırır. Yedek dünyasına özel bir bakış için, S3 uyumlu uzak yedeklemeyi anlattığım yazı güzel bir tamamlayıcıdır.

Ağ, Gecikme ve Küçük Pürüzlerin Büyük Etkisi

Veritabanı kümeleri naziktir; onlara iyi bir ağ verin, çiçek açarlar. Kümeyi tek veri merkezine koyduğunuzda, milisaniyeler ceptedir. Şehirler arası yaydığınızda, her milisaniye “ben de varım” diye bağırır. Galera’da bu bağırış, akış kontrolüyle bir tür metronoma dönüşür. Yazılar fazla büyüdüğünde veya art arda geldiğinde, yavaşlayan düğüm “durun, nefeslenelim” der ve tüm küme ona eşlik eder. Bu, kulağa keyifsiz gelse de, verinin tutarlılığı için bilinçli bir tavırdır. Uzaktaki bir ofiste içecek siparişi verip, hesabın aynı hızla kapanmasını beklemek gibi düşünün; kasiyer aynı anda hem siparişi yazamaz hem de ödeme fişini kesemez.

Group Replication da gecikmeye hassastır. Çoklu-ana modunda, karşılıklı yazı yarışları gecikmeyi daha görünür kılar. Tek-ana modunda ise gecikmeyi büyük ölçüde okuma tarafında hissedersiniz. Bir projede, Avrupa ve Amerika arasında koşan bir SaaS uygulamasında tek-ana yaklaşımı, yerel okuma kopyalarıyla dengeledik. Kullanıcılar yakın okumalardan tat aldı, yazılar okyanusu sakince geçti. Bu düzenin arkasında, akıllı DNS ve iyi bir bağlantı havuzu vardı.

Bu noktada, bağlantı zaman aşımı, paket kaybı, anlık ağ titreşimleri gibi “ufak” görünen şeylerin kümeyi nasıl gerdiğini gözden kaçırmamak lazım. Sağlanamayan “kalp atışları”, istemeden liderlik değişimi gibi sonuçlar doğurabilir. Küçük pürüzleri erkenden yakalamak için iyi bir gözlemleme şart. İlk adımda Prometheus ve Grafana ile basit bir izleme başlangıcı size iyi gelir; oradan, veritabanına özgü panolara yürümek daha kolaydır.

Gözlemleme ve Sorun Giderme: Sessiz Çığlıkları Duymak

Kümelerde sorunlar bazen bağırmaz; fısıldar. Galera’da akış kontrolü yüzdesi, istatistikler ve replikasyon kuyrukları, “ben biraz yoruldum” diyen bir düğümün sessiz çığlığıdır. Uzayan işlemler, büyük transaction’lar ve kilitlenmeler, ritmi bozar. Bu yüzden uygulamada kısa ve öz yazma alışkanlığı, veritabanının en sevdiği hediyedir. DDL değişikliklerini küçük dilimler halinde yapmak, bir düğümü yerinden etmeyen yaklaşımlarla ilerlemek her zaman işe yarar.

Group Replication tarafında da benzer bir hikâye var. Üyelik durumu, liderlik değişimleri, kabul edilmeyen yazı denemeleri… Hepsi belli göstergelerde saklı. Uygulamaya geri çevrilen bir yazıyı sakince tekrar denemek, çoğu defa büyüyen bir sorunun önüne geçer. Burada, uygulama ve veritabanının aynı dili konuşması gerekir. Bağlantı havuzları, zaman aşımı değerleri ve yeniden deneme sayıları, projenizin kişisel ayak numarası gibidir; herkese uyan bir çift ayakkabı yoktur.

Gözlemleme sadece metrik panoları değildir. Günlükler, olay akışları ve “az önce ne oldu?” sorusunun kısa cevaplarıdır. Küçük bir örnek: Bir projede, ani gecikmeleri akış kontrolüyle ilişkilendiremediğimizde, ağ tarafındaki bir mikrosaniyelik titremenin paket yeniden iletimini tetiklediğini bulmuştuk. O günden sonra, veritabanı panolarının yanı sıra ağ cihazlarının da küçük bir kontrol listesini günlük rutine ekledik. İtiraf edeyim, o listeden sonra gece alarmları azaldı.

Uygulama Desenleri: Kümenin Dostu Kod

Veritabanı kümeniz ne kadar düzgünse, uygulamanız o kadar rahat eder. Yazma işlemlerini gereksiz büyüten, okunabilirliği düşüren desenler, kümenin sabrını zorlar. Mesela toplu güncellemeleri akşamdan sabaha taşıyıp, küçük partilere bölmek çoğu zaman mucize yaratır. Tek bir büyük kilit yerine, seri küçük dokunuşlar, tüm düğümlerin derin bir nefes almasını sağlar. Aynı şekilde, “her şeyi tek bir satıra yazdırma” alışkanlığının da size zarif görünmeyen yan etkileri olur. Ayır, sadeleştir, yeniden kullan; bu üçlü, kümenin de hoşuna gider.

Okuma/yazma ayrımı uygulama katmanında netse, proxy katmanını da neşeyle kullanırsınız. Yazıları tek bir düğüme yönlendirip, okumaları geniş bir havuza dağıtmak birçok senaryoda temiz bir çözüm. Galera’da da Group Replication’da da bu doğru. Önemli olan, tutarlılık beklentinizi bilip, seçimi ona göre yapmak. Bazı raporlar bir-iki saniye eski veriyi dert etmiyorsa, rahatça okuyun. Sipariş onayı gibi anlarda ise yazıyı yapan düğümden doğrulamayı alın. Bu ayrım, hem tutarlılık hem performans açısından güzellikler getirir.

İşgünü planlaması da göz ardı edilmemeli. Kampanya başlangıcı, bordro kesimi, ay kapanışı gibi anlarda, veritabanı kümeleri farklı tepki verir. O anların ayak seslerini tanıyıp, küçük ölçekli kapasite artışları, indeks bakımı ve günlüklerin çevrimini önceden yaparsanız, küme “ben hazırım” der. Bunun yanında, onlarca servisin güncellemesini aynı güne sıkıştırmamak da iyi bir alışkanlıktır. Uygulama dağıtımını sade ve emin bir çizgiye almak için, canlıya alırken panik yapmamanızı sağlayan küçük oyun planları her zaman elinizin altında olsun.

Sık Karşılaşılan Yanılgılar: Yedek mi, Kopya mı; Çoklu-Ana mı, Tek-Ana mı?

Bir kez daha altını çizmek isterim: Yedek, geriye dönüş biletidir; yüksek erişilebilirlik, oyunun hiç durmamasıdır. İkisi kardeştir ama aynı kişi değillerdir. Bir diğer karışan konu, çoklu-ana ve tek-ana beklentisinin duygusal tarafı. Çoklu-ana kulağa özgürlük gibi gelir; her yerden yaz, her yerden mutlu ol. Fakat çakışan yazılarda, bu özgürlük nazlıdır. Trafiğinizin doğasını bilmeden çoklu-ana demek, yokuşu hızla inip virajda fren tutmaması gibi hissettirebilir. Tek-ana ise bazen sıkıcı ama güvenli bir otobana benzer; uzun yolda konfor sağlar.

Bir başka yanılsama, “Ağımız iyi, şehirler arası kurar, geçeriz” cümlesi. Aradaki gecikme, sayılara dökülünce masum görünür; ama replikasyon protokolü o sayıyı her işlemde hisseder. Burada doğru çözüm, kullanıcıyı yakın tutmak ve yazıyı olabildiğince kısa yoldan koşmaktır. Verilerin ülke sınırlarını aşarken hukukla da sohbet ettiğini unutmayın; bazen teknik bir karar, hukuki bir çerçeveye dayanır. Mimari masasında hukuk ve operasyon aynı anda oturunca, sonuçlar daha kalıcı olur.

Belge, Topluluk ve Küçük Notlar

Küme işlerinde belgeler, kıymetli bir seyir defteridir. Bazen tek bir satır, saatlerce sürecek bir keşfi hızlandırır. Galera tarafında resmi yazıların yanı sıra topluluk paylaşımları da zengindir; “neden böyle oldu?” sorusuna benzer birinin daha önce rastladığına neredeyse kesin gözüyle bakabilirsiniz. MySQL Group Replication için de resmi kaynaklar düzenlidir; sürüm notları, davranış değişimlerini özetler. Bu ikisinin yanında, pratik kılavuzları seviyorsanız, Galera Cluster mimarisini anlatan resmi sayfa ile MySQL Group Replication kılavuzu favori yer imlerinde dursun.

Belge okurken, kendi ortamınızın karakterini not etmeyi alışkanlık yapın. İşlem boyutları, trafik dalgalanmaları, yoğun saatler, ağın kısa nefesleri… Hepsi bir sonraki bakımda size yol gösterir. Ben çoğu projede, “kayıt defteri” gibi bir doküman tutuyorum. Neyi, ne zaman, neden yaptık? Sorunun cevabı orada. Böyle olunca, altı ay sonra gelen “o değişikliği neden savunmuştuk?” sorusuna, “çünkü şu günkü grafikte bunu görmüştük” diye net bir yanıt çıkıyor.

Kapanış: Yedekten Öteyi Kurarken Sıcak Bir Yol Haritası

Sonunda yine aynı yere dönüyoruz: Yedekler cebimizde, ama hedefimiz kesintisiz bir akış. MariaDB Galera Cluster ve MySQL Group Replication, bu yolculukta farklı karakterlere sahip iki iyi dost. Galera, çoklu-ana hissi ve sıkı tutarlılığıyla dikkat çekiyor; akış kontrolü ve işlem alışkanlıklarıyla ahenk istiyor. Group Replication ise takım düzenine yakın duran bir disiplin sunuyor; tek-ana yaklaşımıyla basitliği severken, çoklu-ana ile de belirli desenlerde güçlü kalabiliyor. Seçim, sizin trafiğinizin ritmine, ekibinizin alışkanlıklarına ve ağınızın mizacına göre şekilleniyor.

Pratik bir kapanış yapmak gerekirse, önce uygulamanızın okuma ve yazma desenlerini dürüstçe çıkarın. Büyük işlemleri parçalamayı, uzun oturumları kısaltmayı, raporları sakin saatlere taşımayı alışkanlık yapın. Proxy ile yazı-yönlendirmesini sadeleştirin; izleme panolarını ilk günden kurun. Bölgesel gecikmeleri, DNS ile yakınlığı ve yedek planınızı birlikte düşünün. Kafanızda soru kaldıysa, burada değindiğim detayların çoğunu, hem okuma/yazma mimarisi üstüne notlarda hem de akıllı DNS yönlendirmesi rehberinde daha ayrıntılı görebilirsiniz. Umarım bu satırlar, bir gece vakti çalan alarmı daha sakin susturmanıza yardımcı olur. Bir dahaki yazıda, belki de veritabanı tarafında sıfır kesinti şemalarıyla operasyonu biraz daha ehlileştiririz. Görüşmek üzere.