Veritabanınız zorlanıyor ama yazma işlemleri az — asıl yük raporlar, listeler ve arama sorgularından geliyor. Bu tipik bir durum ve çözümü veritabanını büyütmek değil, ikinci bir kopya eklemek.
Bu yazı, okuma kopyası kurulumunu ve sınırlarını ele alıyor.
Temel Mantık
Okuma kopyası, ana veritabanının sürekli güncellenen bir yansımasıdır:
- Ana sunucuya yazma yapılır
- Değişiklikler bir günlüğe kaydedilir
- Kopya bu günlüğü okur
- Aynı değişiklikleri kendine uygular
- Okuma sorguları kopyaya yönlendirilir
Kazanç şudur: okuma yükü ana sunucudan alınır ve yazma işlemleri için tam kapasite kalır.
Çoğu web uygulamasında sorguların büyük çoğunluğu okumadır — bu yüzden tek bir kopya bile ana sunucuyu belirgin şekilde rahatlatır.
Kabul Edilmesi Gereken Gerçek
Bu yapının değişmez bir özelliği vardır ve tasarımınızı buna göre yapmalısınız:
- Kopya her zaman biraz geridedir. Milisaniyeler veya saniyeler.
- Yük arttıkça gecikme büyür.
- Büyük işlemler gecikmeyi sıçratır.
Bu, pratik bir sorun üretir: bir kayıt oluşturup hemen kopyadan okumaya çalışırsanız, kayıt henüz orada olmayabilir.
Kullanıcı açısından bu şöyle görünür: formu kaydeder, liste sayfasına yönlendirilir ve az önce eklediği kaydı göremez. Sayfayı yenileyince gelir.
Gecikmeyi Yönetmek
Bu sorunu çözmenin yolları:
| Yöntem | Nasıl çalışır |
|---|---|
| Yazma sonrası anaya yönlendir | Belirli bir süre boyunca |
| Kritik okumaları anadan yap | Ödeme, stok gibi |
| Gecikmeyi izle | Yüksekse kopyayı devre dışı bırak |
| Kullanıcıya beklet | Nadiren uygun |
Birinci satır en pratik çözümdür: bir kullanıcı yazma işlemi yaptıktan sonra kısa bir süre tüm okumaları ana sunucudan yapmak, tutarsızlığı görünmez kılar.
Bu bilgi oturumda saklanabilir ve süre dolduğunda kopyaya dönülür. Uygulama kodunda birkaç satırlık bir mantıkla halledilir.
Hangi Sorgular Kopyaya Gitmeli?
Ayrım her zaman "okuma kopyaya, yazma anaya" kadar basit değildir:
- Raporlar ve istatistikler: Kesinlikle kopyaya.
- Liste ve arama sayfaları: Kopyaya uygun.
- Ürün detay sayfaları: Kopyaya uygun.
- Stok kontrolü: Anadan okunmalı.
- Ödeme doğrulaması: Anadan okunmalı.
- Yetki kontrolü: Anadan okunmalı.
Altıncı madde bir güvenlik gerekçesi taşır: bir kullanıcının yetkisi kaldırıldığında, kopyadan okunan eski yetki bilgisi kısa süreliğine erişime izin verebilir.
Dördüncü madde ise ticari bir risktir. Kopyadan okunan eski stok bilgisi, olmayan bir ürünün satılmasına yol açabilir.
Kurulum Adımları
Kopya kurmak için genel süreç:
- Ana sunucuda günlük kaydını etkinleştirin.
- Çoğaltma için ayrı bir kullanıcı oluşturun.
- Anadan tutarlı bir yedek alın.
- Yedeği kopyaya yükleyin.
- Çoğaltmayı başlatın.
- Gecikmeyi izlemeye başlayın.
Üçüncü madde en dikkat gerektiren adımdır: yedek alınırken hangi noktada olunduğunun kaydedilmesi gerekir — kopya çoğaltmaya tam o noktadan devam etmelidir.
Bu kayıt eksikse kopya ya veri kaçırır ya da aynı değişikliği iki kez uygulamaya çalışıp durur.
İzlenmesi Gerekenler
Kopya kurulduktan sonra düzenli kontroller:
| Metrik | Anlamı |
|---|---|
| Çoğaltma gecikmesi | Kopya ne kadar geride |
| Çoğaltma durumu | Çalışıyor mu, durdu mu |
| Hata sayacı | Uygulanamayan değişiklik var mı |
| Disk alanı | Günlük dosyaları birikiyor mu |
İkinci satır kritik bir alarm gerektirir: çoğaltma durduğunda kopya çalışmaya devam eder ve sorgulara yanıt verir — ama giderek eskiyen veriyle.
Bu, en tehlikeli sessiz arızadır. Uygulama hata almaz, kullanıcılar yanlış veri görür ve kimse fark etmez.
Ek Faydalar
Okuma kopyası yalnızca performans için değildir:
- Yedek alma kopyadan yapılabilir. Ana sunucu etkilenmez.
- Ağır raporlar kopyada çalıştırılır.
- Ana sunucu arızasında yükseltilebilir.
- Şema değişiklikleri önce kopyada denenebilir.
Birinci madde tek başına bile kurulumu haklı çıkarır: büyük bir veritabanının yedeğini almak ana sunucuyu yavaşlatır — bu işi kopyaya devretmek üretim performansını korur.
Üçüncü madde ise felaket senaryosunda değerlidir, ancak otomatik değildir. Kopyayı ana sunucuya dönüştürmek elle yapılan ve dikkat gerektiren bir işlemdir. Kaynakları esnek şekilde ekleyebildiğiniz VDS çözümleri üzerinde ikinci bir veritabanı örneği açmak, bu yapıyı kurmanın en hızlı yoludur.
Sonuç
Okuma kopyası, veritabanı yükünü bölmenin en düşük karmaşıklıklı yoludur — çoğu uygulamada sorguların büyük çoğunluğu okumadır ve tek bir kopya ana sunucuyu belirgin şekilde rahatlatır. Karşılığında kabul etmeniz gereken şey gecikmedir: yazma sonrası hemen kopyadan okursanız kayıt henüz orada olmayabilir. Çözüm, yazma yapan kullanıcıyı kısa süre ana sunucuya yönlendirmektir. Ve mutlaka alarm kurun: çoğaltma durduğunda kopya hata vermez, giderek eskiyen veriyle yanıt vermeye devam eder.
Sıkça Sorulan Sorular (SSS)
Okuma kopyası ne zaman gerekli?
Veritabanı zorlanıyor ama yazma işlemleri azsa. Raporlar, listeler ve arama sorguları yükün büyük kısmını oluşturuyorsa, bu yükü kopyaya devretmek ana sunucuyu yazma işlemleri için serbest bırakır.
Kayıt ekledim ama listede görünmüyor?
Kopya her zaman biraz geridedir — kayıt henüz oraya ulaşmamış demektir. Çözüm, bir kullanıcı yazma işlemi yaptıktan sonra kısa bir süre onun tüm okumalarını ana sunucudan yapmaktır. Bu bilgi oturumda saklanabilir.
Hangi sorguları kopyaya yönlendirmemeliyim?
Stok kontrolü, ödeme doğrulaması ve yetki kontrolü anadan okunmalıdır. Yetki özellikle kritiktir: kullanıcının yetkisi kaldırıldığında kopyadan okunan eski bilgi kısa süreliğine erişime izin verebilir.
Çoğaltma durursa ne olur?
En tehlikeli senaryo budur çünkü sessizdir. Kopya çalışmaya ve sorgulara yanıt vermeye devam eder — ama giderek eskiyen veriyle. Uygulama hata almaz, kullanıcılar yanlış veri görür. Çoğaltma durumu için mutlaka alarm kurun.
