Read Replica ile Okuma Yükünü Dağıtma

Tek bir veritabanı sunucusu bir noktaya kadar her şeyi kaldırır. Sonra trafik artar, raporlar ağırlaşır, listeleme sayfaları çoğalır ve aynı makine hem her saniye yüzlerce SELECT çalıştırmaya hem de siparişleri yazmaya çalışır. Read replica (okuma replikası), bu iki işi ayırmanın en doğrudan yoludur: yazmalar tek bir birincil sunucuda kalır, okumaların büyük bölümü ise sürekli senkronize edilen bir ya da birden fazla kopyaya dağıtılır.

Bu rehberde read replica mimarisini gerçekçi biçimde ele alacağım: hangi durumda gerçekten işe yaradığını (ve hangi durumda çözüm olmadığını), kurulumun kritik kontrol noktalarını, uygulamada okuma-yazma ayrımını nasıl yapacağınızı, replikasyon gecikmesinin yarattığı "kendi yazdığını okuyamama" sorununu ve bunun somut çözümlerini, yönlendirmeyi uygulamada mı proxy'de mi yapmanız gerektiğini ve replikalı bir kurulumda izleme ile yedeklemenin nasıl değiştiğini anlatacağım.

Read Replica Ne Zaman Doğru Çözümdür#

Replika, okuma ağırlıklı iş yükleri için tasarlanmış bir ölçekleme aracıdır. Tipik bir web uygulamasında okuma/yazma oranı 10:1 ile 50:1 arasındadır; bu tabloda okumaları dağıtmak birincil sunucuyu ciddi biçimde rahatlatır. Buna karşılık yazma yükü altında ezilen bir sistemde replika hiçbir şey çözmez: her yazma zaten tüm replikalara da uygulanır, yani yazma kapasitesi artmaz, hatta birincil sunucuya ek günlük yükü biner.

Replika eklemeden önce iki daha ucuz seçeneği tüketin. Birincisi sorgu ve indeks optimizasyonudur; ikincisi önbellek katmanıdır. Bir kategori listesini önbellekten sunmak, o sorguyu bir replikaya taşımaktan çok daha ucuzdur; anlatımı veritabanı önünde cache katmanı yazısında.

Dördüncü satır çoğu kişinin fark etmediği bir kazançtır: yedeği replikadan almak, birincil sunucudaki disk ve kilit yükünü tamamen ortadan kaldırır. Tek başına bu bile bir replikayı hak ettirebilir.

Kurulumun Kritik Kontrol Noktaları#

Replikasyon kurulumunun adım adım anlatımı MySQL replikasyon kurulumu yazısında var; burada okuma replikası özelinde atlanmaması gereken noktalara odaklanacağım. Birincil sunucuda binary log açık ve benzersiz bir server_id tanımlı olmalıdır; GTID kullanmak, sonradan yük devretme yapacaksanız işinizi ciddi biçimde kolaylaştırır:

# Birincil sunucu (/etc/mysql/my.cnf)
[mysqld]
server_id = 1
log_bin = /var/log/mysql/binlog
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800

Replika tarafında en kritik iki ayar read_only ve super_read_only'dir. Yalnızca read_only açmak yeterli değildir; SUPER yetkisine sahip bir hesap yine yazabilir ve bir gün biri yanlış bağlantıda UPDATE çalıştırdığında replika birincilden sessizce ayrışır:

# Replika sunucu
[mysqld]
server_id = 2
read_only = ON
super_read_only = ON
relay_log = /var/log/mysql/relay
replica_parallel_workers = 4

replica_parallel_workers değeri, replikanın gelen değişiklikleri paralel uygulamasını sağlar ve gecikmeyi azaltmanın en etkili tek ayarıdır. Bağlantı kurulduktan sonra durumu her zaman şu komutla doğrulayın:

SHOW REPLICA STATUS\G
-- Kontrol edilecekler:
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
-- Seconds_Behind_Source: 0
-- Last_Error: (boş olmalı)

Üç alandan biri bile beklenen değerde değilse replika okuma trafiği almamalıdır. Bu kontrolü sağlık denetimi olarak otomatikleştirin; el yordamıyla bakılan bir replika, bir gün saatlerdir durmuş halde bulunur.

Uygulamada Okuma-Yazma Ayrımı#

Replikayı kurmak işin kolay yarısıdır; asıl iş uygulamanın hangi sorguyu nereye göndereceğine karar vermesidir. Temel kural nettir: INSERT, UPDATE, DELETE, DDL ve işlem (transaction) içindeki her şey birincile; geri kalan SELECT'ler replikaya.

Modern çerçevelerin çoğunda bu ayrım yapılandırma düzeyinde desteklenir: iki bağlantı tanımlarsınız, ORM yazma işlemlerini otomatik olarak birincile yönlendirir. Elle yönetiyorsanız uygulanacak sıra şudur:

1. İki ayrı bağlantı havuzu tanımlayın: yazma ve okuma.
2. Varsayılanı birincil yapın. Yanlış varsayılan, sessiz veri tutarsızlığı üretir; tersi sadece performans kaybettirir.
3. Yalnızca güvenli olduğunu bildiğiniz sorguları açıkça replikaya işaretleyin.
4. Bir işlem başladığı andan bittiği ana kadar tüm sorguları birincilde tutun.
5. Bir yazmadan hemen sonraki isteklerde aynı kullanıcıyı kısa süre birincile sabitleyin (aşağıda anlatılıyor).

-- Replikaya gönderilmesi güvenli olanlar
SELECT id, ad, fiyat FROM urunler WHERE kategori_id = 12 LIMIT 20;
SELECT COUNT(*) FROM siparisler WHERE olusturma_tarihi >= '2026-08-01';

-- Asla replikaya gönderilmemesi gerekenler
SELECT stok FROM urunler WHERE id = 8241 FOR UPDATE;  -- kilit alır
START TRANSACTION;  -- işlem içi her şey birincilde

SELECT ... FOR UPDATE gibi kilitleyici okumalar teknik olarak SELECT ile başlasa da yazma niyeti taşır ve read_only bir replikada hata verir. Yönlendirmeyi sorgunun ilk kelimesine bakarak yapan basit kurallar bu yüzden yetersizdir.

Replikasyon Gecikmesi ve Kendi Yazdığını Okuma#

Replikasyon eşzamanlı değildir. Birincile yazılan bir kayıt replikaya milisaniyeler, yük altında saniyeler sonra ulaşır. Bu, kullanıcı açısından çok somut bir hataya dönüşür: müşteri adresini kaydeder, sayfa yenilenir ve eski adresi görür. Buna "read-your-writes" tutarlılık sorunu denir ve replikaya geçen her ekibin er ya da geç karşılaştığı ilk gerçek problemdir.

Üç pratik çözüm var ve genelde ikisi birlikte kullanılır:

Yazma sonrası sabitleme. Bir kullanıcı yazma yaptığında, o kullanıcının sonraki birkaç saniyelik isteklerini birincile yönlendirin. Oturumda basit bir zaman damgası tutmak yeterlidir; uygulaması kolay, etkisi yüksektir.

Konum bekleme. Yazmadan sonra elde ettiğiniz GTID'yi saklayıp okumadan önce replikanın o noktaya geldiğini bekleyebilirsiniz. Kesin ama her istekte küçük bir gecikme ekler:

-- Birincilde yazma sonrası
SELECT @@GLOBAL.gtid_executed;

-- Replikada okumadan önce, en fazla 3 saniye bekle
SELECT WAIT_FOR_EXECUTED_GTID_SET('3e11fa47-71ca-11e1-9e33-c80aa9429562:1-42', 3);
-- 0 döndü: yetişti | 1 döndü: zaman aşımı, birincile düş

Kritik okumaları hep birincile göndermek. Ödeme, stok, bakiye ve oturum gibi tutarlılığın pazarlık konusu olmadığı yerlerde replika kullanmayın. Bu, mimarinin en sade ve en sağlam kuralıdır.

Yönlendirmeyi Uygulamada mı Proxy'de mi Yapmalı#

İki yaklaşım var. Uygulama içi yönlendirme, çerçevenin çoklu bağlantı desteğini kullanır; ek bileşen gerektirmez, ayrıntılı kontrol verir ama her uygulamada ayrı ayrı doğru yapılması gerekir. Proxy tabanlı yönlendirme ise uygulamanın önüne bir katman koyar (ProxySQL, MaxScale ya da basit bir HAProxy dağıtımı); uygulama tek bir adrese bağlanır, ayrım ve yük dengeleme proxy'de yapılır.

Tek bir uygulamanız varsa uygulama içi yönlendirmeyle başlayın; birden çok servis aynı veritabanına bağlanıyorsa proxy neredeyse zorunlu hale gelir. Hangi yolu seçerseniz seçin, proxy'nin ya da uygulamanın sağlık denetimi yapması şarttır: gecikmesi eşiği aşan ya da replikasyonu durmuş bir replika havuzdan otomatik çıkarılmalıdır. Sağlık denetimi olmayan bir dağıtım, bozuk replikayı da eşit oranda beslemeye devam eder ve kullanıcıların bir kısmı saatler öncesine ait veri görür.

İzleme, Yedekleme ve Yük Devretme#

Replikalı bir kurulumda izleme listesine üç metrik eklenir: gecikme, replikasyon iş parçacıklarının durumu ve replika ile birincil arasındaki veri tutarlılığı. Gecikme alarmını kurarken kritik ayrıntı şudur: Seconds_Behind_Source alanının NULL dönmesi gecikmenin sıfır olduğu anlamına gelmez, replikasyonun durduğu anlamına gelir. Alarm koşulunuz mutlaka "NULL veya eşikten büyük" olmalıdır. Diğer metrikler için veritabanı izleme metrikleri yazısına bakabilirsiniz.

# Basit gecikme denetimi (izleme sistemine bağlanabilir)
GECIKME=$(mysql -N -B -e "SHOW REPLICA STATUS\G" | grep Seconds_Behind_Source | awk '{print $2}')
if [ "$GECIKME" = "NULL" ] || [ "$GECIKME" -gt 30 ] 2>/dev/null; then
  echo "UYARI: replika gecikmesi sorunlu: $GECIKME" >&2
fi

Yedekleme tarafında replika büyük bir rahatlık sağlar: tam yedeği replikadan alırsınız, birincil hiç etkilenmez. Ancak burada tehlikeli bir yanılgı var — replika yedek değildir. Yanlışlıkla çalıştırılan bir DROP TABLE saniyeler içinde replikaya da gider. Replika, sunucu arızasına karşı korur; insan hatasına karşı korumaz. Zamanda geriye gitmek için ayrıca gerçek yedeğe ihtiyacınız vardır.

Yük devretme (failover) konusunda gerçekçi olun: otomatik yük devretme, yanlış yapılandırıldığında iki sunucunun aynı anda birincil olmasına (split-brain) yol açabilir ve bu, veri kaybından daha kötüdür. Küçük ve orta ölçekli kurulumlarda kontrollü, elle yapılan bir devretme prosedürü genelde daha güvenlidir; önemli olan bu prosedürün yazılı olması ve en az bir kez prova edilmesidir.

Sık Yapılan Hatalar#

Replikayı yazma sorunlarına çözüm sanmak. Yazma yükü altında ezilen bir sistemde replika eklemek yükü artırır. Önce yazma yolunu (disk, toplu işlem, gereksiz indeks) düzeltin.

super_read_only ayarını açmamak. Yalnızca read_only yeterli değildir; yetkili bir hesap yine yazabilir ve replika sessizce ayrışır. Ayrışmayı fark ettiğinizde tek çözüm replikayı baştan kurmaktır.

Sağlık denetimsiz yük dengeleme. Durmuş bir replikaya trafik göndermeye devam etmek, kullanıcıların bir bölümüne eski veri göstermek demektir ve bu tür hatalar destek kayıtlarında "bende görünmüyor" olarak gelir, teşhisi çok zordur.

İşlem içindeki okumaları replikaya kaçırmak. Bir işlem sırasında replikadan okumak, tutarsız bir görüntü üzerinde karar vermenize yol açar. İşlem başladığı andan bittiği ana kadar tek sunucuda kalın.

Replikaya indeks eklemeyi unutmak. Ağır raporları replikaya taşıdıktan sonra o sorguların ihtiyaç duyduğu indeksler replikada da olmalıdır. Şema replikasyonla geldiği için genelde vardır, ama replika özelinde eklenen ek indeksler bir sonraki yeniden kurulumda kaybolur; onları da göç dosyalarında tutun.

Sıkça Sorulan Sorular#

Read replica yazma performansını artırır mı#

Hayır. Her yazma işlemi birincilde çalışır ve ardından tüm replikalara aktarılır; yani yazma kapasitesi artmadığı gibi birincile bir miktar ek günlük yükü de biner. Replika yalnızca okuma trafiğini dağıtır. Yazma darboğazını çözmek için disk hızı, toplu işlem yazımı, gereksiz indekslerin temizlenmesi ve gerekiyorsa bölümleme gibi başka yöntemler gerekir.

Kaç tane replika kurmalıyım#

Genelde bir replika ile başlamak doğrudur ve çoğu orta ölçekli site için yeterlidir. İkinci replikayı, raporlama gibi ağır sorguları site trafiğinden ayırmak istediğinizde ekleyin. Her ek replika birincile ek günlük aktarım yükü getirdiği için sınırsız çoğaltmak mantıklı değildir; ikiden fazlaya çıkmadan önce önbellek ve sorgu optimizasyonunu tükettiğinizden emin olun.

Replikasyon gecikmesi ne kadar olmalı#

Sağlıklı bir kurulumda gecikme genelde bir saniyenin altındadır. Zaman zaman birkaç saniyeye çıkması normaldir, özellikle büyük toplu güncellemelerden sonra. Sürekli 10 saniyenin üzerinde seyrediyorsa replikanın diski ya da işlemcisi yetmiyordur veya paralel uygulayıcı iş parçacığı sayısı düşüktür. Alarm eşiğini uygulamanızın tolere edebildiği bayatlık süresine göre belirleyin.

Replika sunucudan yedek almak güvenli mi#

Evet, hatta önerilir; birincil sunucuyu yedekleme sırasındaki disk ve kilit yükünden tamamen kurtarır. Tek dikkat edilecek nokta, yedeği alırken replikanın gecikmesinin makul olması ve yedekle birlikte replikasyon konumunun da kaydedilmesidir. Ayrıca unutmayın: replikanın kendisi yedek değildir, yanlışlıkla silinen veri replikada da yoktur.

Replika bozulursa ne yapmalıyım#

Önce SHOW REPLICA STATUS çıktısındaki Last_Error alanını okuyun; çoğu durumda tek bir çakışan işlemden kaynaklanır. Hatayı atlayarak devam etmek cazip görünür ama replikayı sessizce tutarsız bırakır ve bu tutarsızlık sonradan çok daha zor teşhis edilir. Güvenli yol, replikayı birincilden alınmış güncel bir yedekle baştan kurmaktır; GTID kullanıyorsanız bu işlem oldukça kolaydır.

PostgreSQL'de karşılığı nedir#

PostgreSQL'de aynı işi akış replikasyonu (streaming replication) ve hot standby yapar: replika salt okunur açılır ve pg_stat_replication görünümünden gecikme izlenir. Uygulama tarafındaki okuma-yazma ayrımı ve tutarlılık kuralları birebir aynıdır. Yönlendirme için genellikle bir bağlantı havuzlayıcı ya da proxy kullanılır; kavramlar farklı isimlerle de olsa aynı mantıkla çalışır.

Kapanış#

Read replica, okuma ağırlıklı sistemlerde en doğrudan ölçekleme kazancını verir ama ücretsiz gelmez: uygulamanın hangi sorguyu nereye göndereceğini bilmesi, gecikmenin sürekli izlenmesi ve tutarlılığın pazarlık konusu olduğu yerlerin net biçimde ayrılması gerekir. Aklınızda kalması gereken dört alışkanlık şu: varsayılanı birincil yapın, super_read_only açın, sağlık denetimi olmadan trafik dağıtmayın ve yazma sonrası okumaları kısa süre birincile sabitleyin.

Replika kurmak için ikinci bir sunucuya ihtiyacınız varsa bulut sunucu ve VDS paketlerimiz hızlı NVMe disk ve yeterli bellekle bu iş için uygundur; replikadan alınan yedeklerin sunucu dışına kopyalanması için yedekleme çözümümüzü, kurulum, izleme ve devretme prosedürlerini bizim üstlenmemizi isterseniz sunucu yönetimi hizmetimizi değerlendirebilirsiniz.