MariaDB Yüksek Erişilebilirlik: Galera Cluster mı, Primary‑Replica mı? WooCommerce İçin Okuma/Yazma Mimarisi

Bir Sipariş Yağmurunda Frene Basmayan Veritabanı Nasıl Kurulur?

Hiç başınıza geldi mi? Mağazanızda güzel bir kampanya başlatırsınız, Instagram’dan trafik yağar, sepetler dolup taşar. Sonra bir anda “sepete ekle” butonu döner durur, ödeme adımı bekler, stoklar garip davranır. Ofiste ilk akla gelen suçlu genelde veritabanı olur. O günlerden birinde ben de “Bu işte bir mimari meselesi var” deyip sandalyeyi geriye itmiştim. MariaDB tarafında aynı iki kavram hep döner durur: Galera Cluster ve Primary‑Replica. İkisi de yüksek erişilebilirlik der, ama hissettirdikleri, takılmayı sevdikleri yerler farklıdır.

Bu yazıda WooCommerce gözlüğüyle bakacağız. Okuma ve yazma trafiği nasıl akar, ödeme ve stok adımlarında başımıza neler gelir, hangi senaryoda Galera’nın senkron kafası bize iyi gelir, hangi durumda Primary‑Replica’nın sükuneti daha doğru hissettirir… Mesela “okuma ağırlıklı saatlerde şöyle, yoğun sepet ve stok çatışmalarında böyle” diye akışın içinden konuşacağız. Arada pratik tüyolar, proxy ipuçları, izleme ve yedekleme önerileri de düşecek. En sonunda da “Bugün benim mağaza için hangisi?” sorusuna sade bir yol haritası çizeceğiz.

WooCommerce Trafiğinin Kalp Atışı: Okuma Nereye, Yazma Nerede Patlar?

WooCommerce’i bir sohbet gibi düşünün. Ürün sayfalarını gezenler bol bol soru sorar: bu ürün ne, varyasyonları ne, stokta var mı? Bunların çoğu okuma. Kasa tarafına gelince cümleler kısalır ama kalınlaşır: siparişi oluştur, adresi yaz, kuponu uygula, stoktan düş, ödeme durumunu güncelle. İşte orası yazmadır ve en küçük takılma, müşterinin sabrını kolayca tüketir.

Asıl ilginç kısım şu: Yazma yükü bazen sandığımız kadar küçük değil. Sepet, oturum, geçici seçenekler… Eğer bunlar akıllıca bir önbelleğe ya da oturum deposuna taşınmadıysa veritabanına minik minik iğneler batırılır. Benim deneyimimde, kampanyalarda en çok zorlanan şey genelde “kısmi ama sürekli yazma” olur. O yüzden MariaDB tarafında hangi mimariyi seçersek seçelim, WooCommerce’in bu küçük yazmalarını azaltmak büyük rahatlık sağlar. Bunun yolu da genelde nesne önbelleği ve sağlam bir sayfa önbelleğinden geçer. Mesela WooCommerce için kalıcı nesne önbelleği seçerken Redis mi Memcached mi sorusunu çözmek, InnoDB’nin üzerinden epey yük alır. Bir de vitrini nefes aldırmak için tam sayfa önbellekleme çok iyi gelir; bunun için nazik bir tam sayfa önbellekleme rehberi daha ilk günden meyvesini verir.

Galera Cluster’ı Gözünüzde Canlandırın: Aynı Anda Yazmak Güçlüdür, Ama Nazik Davranır

Galera, “her düğüm yazabilir” diyen senkron bir dünya kurar. Yazdığınız şey, diğer düğümlerde de onay almadan “tamam” sayılmaz. Bu kulağa sihir gibi gelir çünkü bir düğüm gittiğinde bile diğerleri aynı veriyi bilir. Fakat bunun da bir mizacı var: Yazdığınız her şeyin diğerlerine hızlıca ulaşması gerekir, yoksa “bekle, tamamlanmadan geçemeyiz” der. Bu da özellikle uzak mesafede veya düğümlerden biri yavaşsa hissedilir.

WooCommerce tarafında Galera’nın pırıltısı, siparişi güvenle işleme kısmında parlar. Stock düşüşü, ödeme durum güncellemesi gibi kalbî anlarda “tek gerçek” duygusu güçlüdür. Ama iş aynı anda çok sayıda yazma geldiğinde, üstelik bunların içinde aynı ürünün stok satırlarına dokunanlar karıştığında, Galera “şu an bir nefes alalım” diyebilir. Buna akış kontrolü ve çakışma kontrolünün doğal sonucu diye bakın. Mesela şöyle düşünün: Aynı beden tişört için yüz kişi son adımda. Hepsi aynı satırı kurcalıyor. Galera hepsini sıraya sokar, gerekirse bir kısmını geri iter. Güvenlidir, ama bazen sabırsız kullanıcıya uzun gelebilir.

Bu yüzden ben Galera’yı tercih ettiğim WooCommerce kurulumlarında, yazma trafiğini bir düğümde toplayıp diğer düğümleri daha çok okuma için kullanmayı severim. Evet, her düğüm yazabilir; ancak pratikte ödeme, stok ve sipariş güncellemesi gibi yoğun yazma anlarını tek bir yola almak, çakışmaları azaltır. Bu bir zorunluluk değil, ama genelde daha pürüzsüz bir his bırakır.

Kurulumda aklınızda olsun: Düğüm sayısı tek olsun, düğümler birbirine yakın ve hızlı konuşsun, veritabanı boyutu büyüdükçe ilk senkron işlerini planlı yapın. Yedekleme için akıllı bir strateji koymayı da unutmayın; günlük işlerin ortasında bir düğüm ilk defa veri alacaksa sağlam bir çoğaltma yöntemi gerekir. Offsite yedekler için uzak yedekleme rehberine bir göz atmak, gelecekte geceleri rahat uyumayı sağlar.

Primary‑Replica ile Sakin Su: Yazma Tek Yerden, Okuma Dilediğin Kadar

Primary‑Replica dünyasında hikâye daha klasik akar. Bir düğüm yazmanın evi olur; diğerleri ondan öğrenir. Bu öğrenme genelde gecikmeli olur, bazen anlık, bazen birkaç saniye. WooCommerce’de vitrinin büyük kısmı okuma olduğu için, bu model çoğu mağazada güzel çalışır. Ürün listeleri, filtreler, blog yazıları… Bunlar replika üzerinden akıp gider. Birden trafik patlayınca yeni bir replika eklemek gibi hamleler, günü kurtarmayı kolaylaştırır.

Fakat ödeme adımına gelince küçük bir ince ayar gerekir. “Şimdi az önce verdiğim siparişi göremiyorum” ya da “kuponu uyguladım ama indirim görünmüyor” gibi şikayetler genelde okumanın yanlış yere yönlenmesinden çıkar. Çözüm basit: kritik anlarda okumayı da primary’ye yönlendirmek. Sepet, kasa, hesap sayfaları, sipariş detaylarının hemen görüldüğü anlar… Bu kısımlarda tutarlılığın tadı başkadır. Uygulama tarafında sorgu ayırmak mümkün değilse, veritabanı önünde akıllı bir vekil kullanmak güzel olur. ProxySQL ya da MaxScale gibi araçlar “yazıyı buraya, okumayı şuraya” mantığını konuşur hale getirir. Bu araçlar konusunda daha teknik bilgiye meraklıysanız MariaDB çoğaltma genel bakış sayfalarına göz atmak, kafadaki resimleri netleştirir.

Bir de şunu hep not düşüyorum: Primary‑Replica’da çoğaltma gecikmesi olduğunda kullanıcı hemen hisseder mi? Çoğu zaman hayır, çünkü vitrin içerikleri çok hızlı güncellenmesi gerekmeyen şeylerdir. Ama stok gibi anlık görünen alanlarda “okumayı primary’ye zorlamak” aradığınız huzuru verir. Bunu yapmanın yolu ister uygulama içinde seçici bağlantı, ister proxy üzerinden akıllı kurallar olabilir. Önemli olan, kritikte “öğretmen” olan düğümden konuşmak.

WooCommerce’de Okuma/Yazma Yönlendirmesi: Gerçek Hayatta Ne İşe Yarar?

Bir gün bir mağazada ödeme adımında kararsız bir sabitle karşılaştık. Bazı siparişler, “başarılı” desek de ekranlarında eski sepet bilgisi görünüyordu. Hikâyeyi izleyince gördük ki, okuma replikaya gidiyor, yazma primary’de oluyor; replika da “birazdan yetişirim” diyor. Basit dokunuşlar yaptık: ödeme ve sepetle ilgili sayfalarda okuma da primary’ye gitti, sorun bitti. Bu tür dokunuşlar bazen tek satır bir ayarla, bazen proxy üzerinde bir kural ile çözülür.

Mesela şöyle düşünün: Ürün kataloğunu gezen on bin kişi var. Hepsini primary’ye çekmek anlamsız. Replikalar bu kalabalığı taşır. Ama ödeme adımında yüz kişi var ve hepsi hassas. Burada “tek gerçek kaynaktan oku” demek mantıklıdır. WooCommerce tarafında bazı eklentiler tek bağlantı mantığıyla çalışır; sorgu bazında ayrım yapamazsınız. Böyle durumlarda veritabanı önünde “sadece SELECT olan, ama şu tabloları içermeyen” gibi kurallar tanımlamak iyi sonuç verir. ProxySQL’in okuma-yazma ayırma yetenekleri bu noktada hayat kolaylaştırır; meraklısı için Galera Cluster ve okuma-yazma stratejileri hakkında MariaDB’nin belgeleri sade bir çerçeve sunar.

Bu arada veritabanının sırtından gereksiz yükü almak için önbellek ve schema düzeni baş roldedir. İnce ayarı seviyorsanız, WooCommerce için InnoDB ayarları ve yavaş sorgu analizi rehberini sindire sindire okumak iyi gelir. Bir parantez de oturumlar ve sepet verileri için açayım; Redis gibi bir yapı ile bunları veritabanından uzaklaştırmak çoğu senaryoda fark edilir.

Dayanıklılık, Hatalar ve Gece Gündüz Uykusu

Galera’yı seçtiğinizde, bir düğümün gidişi dünyayı karartmaz. Diğerleri aynı veriye sahiptir. Yeter ki küme çoğunluğu ayakta kalsın. Ağ gecikmesi artarsa küme sabırlı davranır ama her yazmayı onaylamak istediği için bunu kullanıcı bazen küçük bir bekleme olarak hisseder. Öte yandan Primary‑Replica’da primary giderse, birkaç dakikalık lider ataması, yönlendirme ve küçük bir dikkat gerekir. Bu süreç iyi oturtulduğunda kullanıcı bunu fark etmez, ama mimaride “kim primary oldu” sorusuna cevap veren bir orkestratör şarttır.

Her iki dünyada da en iyi arkadaşınız gözlem olacaktır. Replika gecikmesi, Galera’da akış kontrolü, yavaş sorgular, veritabanı bağlantı havuzunun sağlığı… Bunları gözünüzün önüne alırsanız, arızalar sürpriz olmaz. Ben genelde Prometheus ve Grafana ile panolar kurup, “Checkout p95 süresi yükselirse haber ver” gibi uyarılar tanımlamayı seviyorum. Başlamak için temel bir rehber arıyorsanız, VPS izleme ve uyarı kurulumuna dair yazı güzel bir ilk adım olur.

Ve yedekler… Yüksek erişilebilirlik, yedeklemenin yerine geçmez. Bir restoranda iki aşçı olması nasıl mutfak yangınında tarifi geri getirmiyorsa, HA da silinen veriyi geri getirmez. Galera’da SST/IST gibi veri taşıma yöntemleri var, Primary‑Replica’da da replike günlüklerle hızlı toparlanmalar mümkün. Yine de ayrı ve test edilmiş bir yedek planı, içe sinen tek gerçek güvencedir.

Performans Tuzakları: Küçük Dokunuşlarla Büyük Etki

WooCommerce’in en çok canını yakan şeylerden biri “tek bir tablonun hep aynı satırının itilip kakılması”dır. Stok satırları buna güzel örnek. Onlar için uygulama tarafında kilitli okumalar, en kritik anlarda tek düğüme yönlendirme, hatta busy ürünleri bir süre özel bir kuyruğa alıp stok güncellemeyi “hızlı ama düzenli” bir hale getirmek işe yarar. Bu, Galera’da çakışma geri çevirmelerini azaltır, Primary‑Replica’da da primary’nin işini sadeleştirir.

Bir başka küçük ama etkili dokunuş, sayfayı mümkün olan en dış katmanda önbelleğe almaktır. Ürün listeleme sayfaları ve blog içerikleri çoğu zaman saatlerce aynıdır. Vitrine bir nefes aldırmak için Nginx seviyesinde tam sayfa önbellek şahane bir arkadaştır. Kurulumuna dair ayrıntılı ve sıcak anlatımlı bir rehber ararsanız, tam sayfa önbellek rehberi elinizi tutar. Ardından kalıcı nesne önbelleği ile veritabanına giden tekrar eden sorguları susturursunuz. Bu ikili kurulduğunda, veritabanı mimarinizin hangi modelde olacağına karar vermek daha kolay olur, çünkü üzerindeki basınç zaten azalmıştır.

Bir de kapasite planlaması. Ben basit bir pratik kullanıyorum: kampanya öncesinde üretimde ne varsa bir “kurcalama” senaryosu çalıştırıyorum. Ürün aramaları, filtreler, varyasyon sayfaları, peş peşe sepet eklemeleri, sahte ödeme adımları… Hepsi kısa bir prova. Bu sırada veritabanı panelinde p95 ve p99 sürelerini, en uzun sorguları ve replikasyon gecikmesini izliyorum. Küçük bir çıkıntı varsa kampanya öncesi düzeltmek gibisi yok.

Somut Mimariler: Bugün Mağaza Kaç Kişiyle Dans Ediyor?

Minik ama canlı bir mağaza. Trafik düzenli, kampanyalar mütevazı. Burada güçlü bir tekil MariaDB, iyi ayarlanmış InnoDB tamponları ve düzenli yedek çoğu zaman yeter. Sayfanın önbelleği ve nesne önbelleği de yerini aldıysa, veritabanının yüzü gülmeye başlar.

Orta ölçekli, günde birkaç kez “hafif fırtına” gören mağaza. Primary‑Replica burada çok huzurlu hissettirir. Yazma primary’ye, okuma replikalara. Checkout, sepet, hesap sayfalarında okumayı da primary’ye zorlayacak kurallar. Üstüne ProxySQL veya benzeri bir katmanla ismine göre ayrılmış sorgular. Bu yapı bir süre sizi sırtında taşır. Bu seviyede WooCommerce’in sunucu gereksinimlerine ve önerilerine kulak vermek de iyi bir checklist sağlar.

Yoğun kampanya, anlık patlamalar, çok eşzamanlı ödeme ve stok hareketi. Galera burada güçlü bir seçenek olur, çünkü veri bütünlüğü anında sağlanır. Ama akış kontrolü ve çakışmalarla nazik davranmak gerekir. Yazmayı bir düğüme toplamak, diğerlerini ağırlıkla okuma için kullanmak, düğümleri düşük gecikmeli bir ağda tutmak… Bu ayarlar yapılınca Galera’dan hem güven hem de akışkanlık alınır. Bir de büyük sorguları küçük lokmalara bölmek ve gereksiz sütunları bırakmamak hoş bir jesttir.

Her iki senaryonun ortak noktası şu: Veritabanına gitmeden önce mümkün olduğunca işinizi dışarıda halledin. Nesne önbelleğine atabildiğinizi atın, statik sayfaları önbelleğe alın, yavaş sorguları tıraşlayın. Bu temeli sağlam kurduktan sonra, “Benim dans pistim hangisi?” sorusunun cevabı kendiliğinden belirir.

Proxy, Şema ve Güncelleme Meselesi: Ufak Dokunuşlar

Okuma/yazma ayrımı yapılacaksa, proxy katmanı işin ince zekâsıdır. ProxySQL veya MaxScale ile “SELECT’leri şuraya, şu tabloları içeren SELECT’leri ise primary’ye” gibi kurallar tanımlamak mümkündür. Yönetimi kolay bir yapı kurduğunuzda, geliştirici ekip her sorguyu tek tek düşünmek zorunda kalmaz. Yine de checkout akışları gibi kritik yolları etiketlemek ve o anki okumanın da primary’de yapılmasını garanti etmek sağlıklı bir alışkanlık olur.

Şema güncellemeleri ve eklenti dünyası da başka bir başlık. WooCommerce’de bir eklenti, veritabanında yeni bir sütun ister. Galera’da bu tür değişiklikler tüm düğümlerde aynı anda görünmek zorunda olduğu için, kısa bir planlama ve bakımı uygun bir zaman penceresine almak huzur verir. Primary‑Replica’da ise değişiklik primary’den akar; replikaların peşinden gelmesini izlersiniz. Her durumda canlıda şema değişikliği yapacaksanız, küçük parçalara bölmek ve yoğun saatlerden kaçmak gönül rahatlığı sağlar.

Bu arada altyapıda HTTP/2 veya HTTP/3 gibi iyileştirmeler bile dolaylı etkiler yaratır. İstemciler hızlı kaynaklara erişince, backend daha düzenli nefes alır. Bununla ilgili kurulum rehberini merak edenler için uçtan uca HTTP/2 ve HTTP/3 kurulumu faydalı bir refakatçi olur.

Karar Anı: Galera mı, Primary‑Replica mı? Sorunun Cevabı Hep Senaryoda Saklı

Bir müşterim şöyle demişti: “Benim önceliğim, siparişlerin taş gibi güvenle yazılması ve düğüm düşse bile itirazsız devam edebilmek.” Bu cümle çoğu zaman Galera’nın sesidir. Ama bir diğeri, “Okuma çok, yazma az; kampanyada içerik akıyor ama ödeme adımı görece sakin” dediğinde ben Primary‑Replica’ya daha bir sıcak bakarım. Burada sihirli formül yok; mağazanın ritmi var. Ne kadar eşzamanlı yazma var, stoklar aynı anda çok mu kurcalanıyor, düğümler aynı ağda mı, gecikme ne durumda… Bunlar sorulduğunda cevap kendini gösterir.

Tek bir ipucu bırakayım: Karar vermeden önce bir ile üç gün arası gerçek trafiği izleyin. Checkout akışının an be an sürelerini, ürün sayfalarının sorgu yoğunluğunu, yavaş sorgu günlüğünün en çok görülenlerini not edin. Sonra bu notlarla “okuma nereden, yazma nereden” kararını verin. Üstüne önbellek ve sayfa önbelleği ile veritabanına giden gereksiz yolları kapatın. Böyle yapınca hangisini seçseniz, mimarinizle barışık kalırsınız.

Kapanış: Mağazanızın Ritmini Duyun, Mimariniz Ona Eşlik Etsin

Bugün beraber şunu konuştuk: WooCommerce aslında iki hikâye anlatıyor. Vitrin, yani okunası dünya; kasa, yani yazılası dünya. MariaDB tarafında Galera, “her yerde aynı anda” derken güveni büyütüyor; Primary‑Replica, “yazma burada, okuma orada” diyerek ölçeği kolaylaştırıyor. Hangisini seçeceğiniz, sizin mağazanın melodisine bağlı. Çok eşzamanlı yazma ve stok çatışmaları mı? Galera’yı nazikçe kurgulayın. Okuma deniz, yazma dere gibi akıyorsa, Primary‑Replica’nın sakinliğini değerlendirin.

Pratik birkaç tavsiye bırakıyorum. Sipariş ve stokla ilgili kritik anlarda okumayı da primary’ye yönlendirin. Nesne önbelleği ve tam sayfa önbelleği ile veritabanını rahatlatın. İzleme kurmadan kampanyaya girmeyin, uyarılarınız cebinizde dursun. Yedekleri test etmeden kendinizi güvende sanmayın. Takıldığınız yerde, bir kahve molası verip küçük bir uygulama güncellemesiyle büyük bir nefes alacağınızı unutmayın. Umarım bu rehber yol gösterici olmuştur. Sorularınız olursa yazın, bir dahaki yazıda belki sizin senaryonuzu konuşuruz.