Okuma replikalarının neden var olduğunu, hangi sorunları çözdüğünü ve ne zaman yardımcı (veya zararlı) olabileceğini öğrenin. Yaygın kullanım örnekleri, sınırlamalar ve pratik karar ipuçları içerir.
Bir okuma replikası, ana veritabanınızın (genellikle birincil diye anılan) bir kopyasıdır ve ondan gelen değişiklikleri sürekli alarak güncel kalır. Uygulamanız, replikalara sadece okuma sorguları (ör. SELECT) gönderebilir; birincil ise tüm yazmaları (ör. INSERT, UPDATE, DELETE) işlemeye devam eder.
Vaat basit: birincile ek yük bindirmeden daha fazla okuma kapasitesi.
Uygulamanız çok sayıda “getirme” trafiğine sahipse—ana sayfalar, ürün sayfaları, kullanıcı profilleri, panolar—bu okumalardan bir kısmını bir veya daha fazla replika üzerine taşımak birincilin yazma işine odaklanmasını sağlar. Birçok durumda bu, uygulamada az değişiklikle yapılabilir: bir veritabanını gerçeğin kaynağı olarak tutarsınız ve sorgulanacak ek yerler olarak replikalar eklersiniz.
Replikalar faydalıdır ama sihirli bir performans düğmesi değildir. Replikalar şunları yapmaz:
Replikaları bir okuma ölçeklendirme aracı olarak düşünün; her çözüm gibi ödünler vardır. Bu makalenin geri kalanı, ne zaman gerçekten yardımcı olduklarını, sıkça nasıl ters tepebileceklerini ve replikasyon gecikmesi ile nihai tutarlılık gibi kavramların bir kopyadan okumaya başladığınızda kullanıcıların ne göreceğini nasıl etkilediğini açıklıyor.
Tek bir birincil veritabanı sunucusu genellikle başlangıçta “yeterince büyük” görünür. Yazmaları (insert, update, delete) işler ve uygulamanız, panolarınız ve iç araçlarınızdan gelen her okuma isteğine (SELECT) cevap verir.
Kullanım arttıkça, okumalar genellikle yazmalardan daha hızlı çoğalır: her sayfa görüntüleme birden çok sorgu tetikleyebilir, arama ekranları birçok arama yapabilir ve analitik tarzı sorgular çok sayıda satırı tarayabilir. Yazma hacminiz ılımlı olsa bile, birincil yine de iki işi aynı anda yapmak zorunda kaldığı için darboğaz olabilir: değişiklikleri güvenli ve hızlı kabul etmek ve artan okuma trafiğini düşük gecikmeyle karşılamak.
Okuma replikaları bu iş yükünü bölmek için vardır. Birincil yazmaları işlemeye ve “gerçeğin kaynağı” olmaya odaklanırken, bir veya daha fazla replika yalnızca okuma sorgularını işler. Uygulamanız bazı sorguları replikalara yönlendirebildiğinde birincilin CPU, bellek ve I/O baskısını azaltırsınız. Bu genellikle genel yanıt verme süresini iyileştirir ve yazma ani yükleri için daha fazla boşluk bırakır.
Replikasyon, replikaların birincilden değişiklikleri kopyalayarak güncel kalmasını sağlayan mekanizmadır. Birincil değişiklikleri kaydeder ve replikalar bu değişiklikleri uygular, böylece neredeyse aynı veriyle sorgulara cevap verebilirler.
Bu desen birçok veritabanı sistemi ve yönetilen hizmette yaygındır (ör. PostgreSQL, MySQL ve bulut varyantları). Uygulama farklılıkları olsa da amaç aynıdır: birincili sonsuza dek dikey ölçeklemeye zorlamadan okuma kapasitesini artırmak.
Birincil veritabanını “gerçeklik kaynağı” olarak düşünün. O her yazmayı kabul eder—sipariş oluşturma, profilleri güncelleme, ödemeleri kaydetme—ve bu değişikliklere kesin bir sıra atar.
Bir veya daha fazla okuma replika daha sonra birincili takip eder, bu değişiklikleri kopyalar ve böylece sorgulara (ör. “sipariş geçmişimi göster”) ek yük bindirmeden cevap verebilirler.
Okumalar replikalardan sunulabilir, ancak yazmalar hâlâ birincile gider.
Replikasyon iki geniş modda olabilir:
Bu gecikme—replikaların birincilin gerisinde kalması—replikasyon gecikmesi olarak adlandırılır. Bu otomatik olarak bir hata değildir; okumaları ölçeklendirmek için kabul ettiğiniz normal bir ödün olabilir.
Kullanıcılar için gecikme, nihai tutarlılık olarak görülür: bir şeyi değiştirdikten sonra sistem her yerde tutarlı hale gelir, ama hemen olmayabilir.
Örnek: e-posta adresinizi güncellersiniz ve profil sayfanızı yenilersiniz. Sayfa bir replikadan servis ediliyorsa ve replikada birkaç saniye gecikme varsa, kısa süreliğine eski e-posta görünebilir—ta ki replika güncellemeyi uygulayıp “yetişene” kadar.
Okuma replikaları, birincil veritabanınız yazmalar için sağlıklı ama okuma trafiğini karşılamakta zorlandığında yardımcı olur. Yazma şeklinizi değiştirmeden anlamlı miktarda SELECT yükünü devredebildiğinizde en etkili olurlar.
Aşağıdaki kalıplara bakın:
SELECT sorgularının INSERT/UPDATE/DELETE’e göre çok yüksek oranıReplikaları eklemeden önce şunlarla doğrulayın:
SELECT içinde?Çoğu zaman ilk hamle tuning olmalıdır: doğru indeks eklemek, bir sorguyu yeniden yazmak, N+1 çağrılarını azaltmak veya sıcak okumaları önbelleğe almak. Bu değişiklikler replikalar işletmekten daha hızlı ve daha ucuz olabilir.
Replikaları seçin eğer:
Önce tuning seçin eğer:
Okuma replikaları, birincil veritabanınız yazma işleriyle meşgulken (checkout’lar, kayıtlar, güncellemeler) ama trafiğin büyük bir kısmı okuma-ağırlıklı olduğunda en çok değer katar. Birincil–replica mimarisinde doğru sorguları replikalara yönlendirmek, uygulama özelliklerini değiştirmeden veritabanı performansını iyileştirir.
Panolar genellikle uzun sorgular çalıştırır: gruplama, geniş tarih aralıkları üzerinde filtreleme veya çoklu tablo join’leri. Bu sorgular işlem işiyle CPU, bellek ve cache için yarışabilir.
Bir replikayı iyi bir yer olarak kullanabilirsiniz:
Böylece birincil hızlı, öngörülebilir transaction’lara odaklanırken analitik okumalar bağımsız olarak ölçeklenir.
Katalog gezintisi, kullanıcı profilleri ve içerik akışları benzer okuma sorgularının yüksek hacimlerini üretebilir. Okuma ölçeklendirme baskısı darboğaz olduğunda replikalar trafiği emebilir ve gecikme zirvelerini azaltabilir.
Bu, özellikle okumaların cache-miss ağırlıklı olduğu (çok sayıda benzersiz sorgu) veya yalnızca uygulama önbelleğine güvenilemediği durumlarda etkilidir.
Dışa aktarmalar, backfill’ler, özet yeniden hesaplamalar ve “X ile eşleşen her kaydı bul” işler birincili zorlayabilir. Bu taramaların replikada çalıştırılması genellikle daha güvenlidir.
Ancak job’un nihai tutarlılığı tolere etmesi gerektiğini unutmayın: replikasyon gecikmesi yüzünden en yeni güncellemeleri görmeyebilir.
Küresel kullanıcı kitleniz varsa, replikaları onlara yakın bölgelere koymak round-trip süresini azaltır. Takas, lag veya ağ sorunları sırasında eski okumaya daha fazla maruz kalmaktır, bu yüzden yalnızca “neredeyse güncel” olmasının kabul edilebilir olduğu sayfalar (gezinti, öneriler, herkese açık içerik) için uygundur.
Replikalar “yeterince yakın” iyi olduğunda harikadır. Ürününüz her okumanın en güncel yazmayı yansıttığını varsayıyorsa replikalar ters tepebilir.
Kullanıcı profilini düzenler, bir form gönderir veya hesap ayarlarını değiştirir—ve bir sonraki sayfa yüklemesi replikadan geliyorsa birkaç saniye eski veri görebilir. Güncelleme başarılı olmuştur ama kullanıcı eski veriyi görür, yeniden dener, çift gönderim yapar veya güvenini kaybeder.
Bu, e-posta adresi değiştirme, tercihi açma/kapama, belge yükleme veya yorum gönderip geri yönlendirme gibi anında onay beklenen akışlarda özellikle can sıkıcıdır.
Bazı okumalar kısa süre bile olsa eski olmayı tolere edemez:
Bir replika gerideyse yanlış sepet toplamı gösterebilir, stok fazlası satılmasına neden olabilir veya yanlış bakiye gösterebilir. Sistem daha sonra kendini düzeltebilse bile kullanıcı deneyimi (ve destek hacmi) zarar görür.
İç panolar genellikle gerçek kararlar alır: fraud incelemesi, müşteri desteği, sipariş karşılama, moderasyon ve olay müdahalesi. Bir yönetici aracı replikalardan okuma yapıyorsa, tamamlanmamış verilere göre hareket etme riski vardır—ör. zaten iade edilmiş bir siparişi geri ödeyebilir veya son durumu kaçırabilirsiniz.
Yaygın bir desen şartlı yönlendirmedir:
Bu, replikaların faydalarını korurken tutarlılığı tahmin oyununa çevirmeyi önler.
Replikasyon gecikmesi, bir yazmanın birincilde commit edilmesi ile aynı değişikliğin replikada görünmesi arasındaki gecikmedir. Uygulamanız bu süre boyunca replikadan okuma yaparsa “eski” sonuçlar dönebilir—kısa süre önce doğru olan ama artık geçerli olmayan veriler.
Lag normaldir ve genellikle stres altında büyür. Yaygın nedenler:
Lag sadece tazelikten etkilemez—kullanıcı açısından doğruluk da etkilenir:
Özelliğinizin ne kadar esnek olduğunu kararlaştırın:
Replika lag’ını (saniye/byte), replika apply oranını, replikasyon hatalarını ve replika CPU/disk I/O’sunu izleyin. Lag kabul edilebilir eşiğinizi aştığında (ör. 5s, 30s, 2m) ve lag zaman içinde artmaya devam ediyorsa (replikanın yakalanamayacağının işareti) uyarı verin.
Okuma replikaları, okuma ölçeklendirme aracıdır: SELECT sorgularını sunmak için daha fazla yer ekler. Yazma ölçeklendirme aracı değildir: sisteminizin kaç INSERT/UPDATE/DELETE kabul edebileceğini artırmazlar.
Replikalar eklendiğinde, okuma kapasitesi eklersiniz. Uygulamanız okuma-ağırlıklı uç noktalarda (ürün sayfaları, beslemeler, lookuplar) darboğazdaysa bu sorguları birden çok makineye yayabilirsiniz.
Bu genellikle şunları iyileştirir:
Yaygın yanlış anlaşılma: “daha fazla replikalar = daha fazla yazma throughput’u.” Tipik primary-replica kurulumunda tüm yazmalar hâlâ primary’e gider. Hatta daha fazla replika birincil için biraz daha iş yaratabilir, çünkü birincilin her replika için replikasyon verisi üretip göndermesi gerekir.
Eğer sorununuz yazma throughput’uysa, replikalar bunu çözmez. Genellikle farklı yaklaşımlar gerekir (sorgu/indeks tuning, batching, partitioning/sharding veya veri modelini değiştirme).
Replikalar size daha fazla okuma CPU’su sağlasa bile, hâlâ bağlantı limitlerine takılabilirsiniz. Her veritabanı düğümünün eşzamanlı bağlantı sınırı vardır ve replikalar eklemek uygulamanızın bağlanabileceği yer sayısını çoğaltır—toplam talebi azaltmadan.
Pratik kural: bağlantı havuzu veya bir pooler kullanın ve servis başına bağlantı sayılarınızı kasıtlı tutun. Aksi halde replikalar sadece “yüklenebilecek daha fazla veritabanı” haline gelebilir.
Replikalar gerçek maliyetler ekler:
Ödün basit: replikalar size okuma başlığı ve izolasyon alabilir ama karmaşıklık katar ve yazma sınırını yukarı çekmez.
Read replikalar okuma erişilebilirliğini iyileştirebilir: birincil aşırı yüklendiğinde veya kısa süre erişilemez olduğunda, bazı okuma trafiğini replikalardan sunmaya devam edebilirsiniz. Bu, müşteri tarafı sayfalarını (hafifçe eski verinin kabul edilebilir olduğu içerik için) yanıtlı tutar ve birincil olaylarının etki alanını küçültür.
Ancak replikalar tek başına tam bir yüksek erişilebilirlik planı sağlamaz. Bir replika genellikle otomatik olarak yazmaya hazır değildir ve “okunabilir bir kopya var” demek, “sistem güvenli ve hızlı şekilde yazmayı yeniden kabul edebilir” demekle aynı değildir.
Failover genellikle şu adımları içerir: birincil başarısızlığı tespit et → bir replika seç → onu yeni birincil olarak terfi ettir → yazmaları (ve genellikle okumaları) yeni düğüme yönlendir.
Bazı yönetilen veritabanları bu sürecin çoğunu otomatikleştirir, ama temel fikir değişmez: kim yazma kabul edebilecek değişir.
Failover’ı uygulamalı olarak çalıştırın. Staging’de (ve üretimde düşük riskli pencerelerde dikkatli) game-day testleri yapın: birincil kaybını simüle edin, kurtarma süresini ölçün, yönlendirmeyi doğrulayın ve uygulamanızın salt-okuma dönemlerini ve yeniden bağlanmaları düzgün yönettiğinden emin olun.
Read replikalar ancak trafiğiniz gerçekten onlara ulaştığında yardımcı olur. “Okuma/yazma ayırma”, yazmaları birincile ve uygun okumaları replikalara gönderme kurallarını kapsar—doğruluğu bozmadan.
En basit yaklaşım veri erişim katmanında açık yönlendirmedir:
INSERT/UPDATE/DELETE, şema değişiklikleri) birincile gider.Bu, gerekçelendirmesi kolay ve geri alması basittir. Ayrıca “checkout sonrası, bir süre sipariş durumunu birincilden oku” gibi iş kurallarını buraya kodlayabilirsiniz.
Bazı ekipler, birincil vs replika uç noktalarını anlayan ve sorgu tipine veya bağlantı ayarlarına göre yönlendiren bir veritabanı proxy’sı veya akıllı sürücü tercih eder. Bu, uygulama kodunda değişiklik gerektirmez ama dikkat: proxy’ler ürün açısından hangi okumaların “güvenli” olduğunu her zaman bilemez.
İyi adaylar:
Kullanıcının hemen ardından gelen okumaları (ör. “profili güncelle → profili tekrar yükle”) replikalara yönlendirmekten kaçının; eğer bir tutarlılık stratejisi yoksa.
Bir transaction içinde, tüm okumaları birincilde tutun.
Transaction dışındaysa, “okuduğunu yazdığını görme” oturumlarını düşünün: yazmadan sonra kullanıcı/oturum kısa bir TTL için birincile sabitlenebilir veya belirli takip sorguları birincile yönlendirilebilir.
Bir replika ekleyin, sınırlı sayıda uç nokta/sorgu yönlendirin ve karşılaştırın:
Etkisi net ve güvenliyse yönlendirmeyi genişletin.
Read replikalar “kur ve unut” değildir. Onlar kendi performans limitleri, başarısızlık modları ve operasyonel görevleri olan ek veritabanı sunucularıdır. Biraz izleme disiplinı genellikle “replikalar işe yaradı” ile “replikalar karışıklık kattı” arasındaki farktır.
Kullanıcı tarafı semptomlarını açıklayan göstergeye odaklanın:
Hedefiniz okuma offload’uysa bir replika ile başlayın. Bir constraint olduğunda daha fazlasını ekleyin:
Pratik kural: replikaları sadece okumaların darboğaz olduğunu doğruladıktan sonra ölçeklendirin (indeksler, yavaş sorgular veya uygulama önbelleklemesi değilse).
Read replikalar okuma ölçeklendirme için bir araçtır, fakat genellikle çekilecek ilk kaldıraç değildir. Operasyonel karmaşıklık eklemeden önce daha basit bir düzeltme aynı sonucu veriyor mu kontrol edin.
Önbellekleme veritabanından tüm okumaları kaldırabilir. “Çoğunlukla okunan” sayfalar (ürün detayları, herkese açık profiller, konfigürasyon) için uygulama önbelleği veya CDN trafiği dramatik şekilde azaltabilir—replikasyon gecikmesi getirmez.
İndeksler ve sorgu optimizasyonu çoğu durumda replikalara göre daha büyük kazanım sağlar: birkaç pahalı sorgunun CPU yakması söz konusuysa doğru indeksi eklemek, SELECT sütunlarını azaltmak, N+1 sorunlarını çözmek ve kötü join’leri düzeltmek çoğu problemi çözer.
Materialized view / ön-aynılaştırma iş yükü doğası gereği ağırsa (analitik, panolar) yardımcı olur. Karmaşık sorguları yeniden çalıştırmak yerine hesaplanmış sonuçları saklayıp belirli aralıklarla yenileyebilirsiniz.
Eğer yazmalar darboğaz yapıyorsa (hot-row’lar, kilit contention, yazma IOPS limitleri), replikalar pek yardımcı olmaz. Bu durumda tabloları zamana/tenant’a göre partition’lamak veya müşteri ID’sine göre sharding yapmak yazma yükünü yayar. Bu daha büyük bir mimari adımdır ama gerçek sınırlamayı çözer.
Dört soru sorun:
Yeni bir ürün prototipleiyorsanız veya bir servisi hızlı başlatıyorsanız, bu kısıtları baştan mimariye dahil etmek yardımcı olur. Örneğin Koder.ai üzerinde geliştiren ekipler genellikle basitlik için tek bir birincil ile başlar, sonra panolar, akışlar veya dahili raporlama işlem trafiği transaction trafiğiyle yarışmaya başlayınca replikalara geçerler. Plan odaklı bir iş akışı hangi uç noktaların nihai tutarlılık gerektirip hangilerinin birincile “okuma-yazma”ya ihtiyaç duyduğunu önceden belirlemeyi kolaylaştırır.
Eğer hangi yolu seçeceğiniz konusunda yardıma ihtiyacınız varsa, seçenekler için /pricing sayfasına bakın veya ilgili rehberleri /blog üzerinde göz atın.
Bir read replica, birincil veritabanınızın bir kopyasıdır; değişiklikleri sürekli alır ve sadece okuma sorgularına (ör. SELECT) cevap verebilir. Birincilin üzerindeki okuma yükünü azaltarak okuma kapasitesi eklemenize yardımcı olur.
Hayır. Tipik bir primary–replica kurulumunda tüm yazmalar hâlâ birincile gider. Replikalar, birincilin her replikaya değişiklik göndermesi gerektiği için bir miktar ek yük bile getirebilir.
Genellikle okunmaya bağlı olduğunuzda yardımcı olurlar: SELECT trafiği CPU/I/O veya bağlantı baskısı yaratıyorsa ve yazma hacmi nispeten sabitse. Ağır okuma işleri (raporlama, dışa aktarma) ile işlem trafiğini izole etmek için de yararlıdırlar.
Zorunlu değildir. Bir sorgu eksik indeksler, kötü join’ler veya çok geniş taramalar yüzünden yavaşsa, bu sorgu replika üzerinde de yavaş çalışır—sadece farklı bir yerde. Toplam zamanı domine eden birkaç sorgunuz varsa, önce sorgu ve indeksleri iyileştirin.
Replikasyon gecikmesi, bir yazmanın birincide commit edilmesi ile aynı değişikliğin replika üzerinde görünür hale gelmesi arasındaki gecikmedir. Bu süre boyunca replica okumaları eski veri döndürebilir; bu yüzden replikalar kullanıldığında bazı okumalarda nihai tutarlılık (eventual consistency) söz konusudur.
Yaygın sebepler şunlardır:
Aşağıdaki gibi, son yazmayı kesinlikle yansıtması gereken okumalar replikalardan yapılmamalıdır:
Bu tip kritik yollar için birincilden okumayı tercih edin.
Bir read-your-writes stratejisi kullanın:
Ölçümlemeniz gereken temel sinyaller şunlardır:
Lag, ürününüzün kabul edilebilir eşiğini aştığında (ör. 5s/30s/2m) uyarı verin.
İyi alternatifler şunlardır:
Replikalar, okumalar zaten makul düzeyde optimize edildiğinde ve bir miktar eskime kabul edilebiliyorsa en iyi seçenektir.