Örnek sorular
Replication ScalingZorluk 1
Veritabanı bağlamında replication ne anlama gelir?
- aBüyük bir tabloyu daha küçük parçalara bölüp ayrı sunucularda saklamak
- bAynı verinin kopyalarını birden fazla veritabanı sunucusunda tutmak✓
- cEski veriyi sıkıştırarak veritabanının zamanla daha az disk kullanmasını sağlamak
- dSık okunan satırları uygulama belleğinde cache'leyerek okumayı hızlandırmak
Açıklama:Replication, aynı veriyi birden fazla sunucuda senkron kopyalar hâlinde tutmaktır; HA (high availability), read scaling ve backup/DR sağlar. (a) sharding'i, (c) arşivleme/sıkıştırmayı, (d) uygulama cache'lemesini tarif eder.
Replication ScalingZorluk 1
Aşağıdakilerden hangisi replication kurmanın yaygın bir nedenidir?
- aİlgisiz iki tablo arasında foreign key constraint'leri zorlamak
- bŞema'yı otomatik olarak daha yüksek normal form'lara normalize etmek
- cVeritabanının bakımını yapması gereken index sayısını azaltmak
- dPrimary sunucu çökerse devralabilecek bir standby kopya tutmak✓
Açıklama:Replication genellikle high availability (terfi edilebilir bir standby), read scaling ve backup/DR için kurulur. (d) HA nedenidir. Diğerleri replication'ın çözdüğü konular değildir.
Replication ScalingZorluk 1
Klasik bir primary–replica (master–slave) kurulumunda write işlemleri (INSERT/UPDATE/DELETE) normalde nereye gönderilir?
- aPrimary'ye; değişiklikler ardından replica'lara yayılır (propagate edilir)✓
- bO an en düşük yükü olan herhangi bir replica'ya
- cUygulama tarafından, aynı anda doğrudan tüm sunuculara
- dÖnce bir replica'ya; o da değişikliği primary'ye iletir
Açıklama:Write'lar tek primary'ye gider ve primary bu değişiklikleri replica'lara replicate eder. Replica'lar salt-okunur kopyalardır ve uygulamadan write kabul etmez.
Replication ScalingZorluk 2
Bir servis read query'lerini bir read replica'ya gönderecek şekilde ayarlanmış. Bir geliştirici yanlışlıkla aynı read-replica bağlantısına bir UPDATE yönlendiriyor. Ne olur?
- aUpdate replica'da başarılı olur ve sonradan primary'ye geri kopyalanır
- bUpdate replica'da başarılı olur ama primary tarafından sessizce yok sayılır
- cWrite reddedilir, çünkü read replica salt-okunurdur✓
- dUpdate çalışır ve replica otomatik olarak yeni primary olur
Açıklama:Read replica salt-okunurdur; ona yapılan write denemeleri reddedilir. Write'lar primary'ye gitmelidir ve replication tek yönlüdür (primary → replica), asla ters yöne akmaz.
Replication ScalingZorluk 2
Synchronous ve asynchronous replication arasındaki temel trade-off nedir?
- aSynchronous write'ta daha hızlıdır ama son veriyi kaybedebilir; asynchronous daha yavaştır ama commit edilmiş hiçbir veriyi asla kaybetmeyeceği garanti edilir
- bSynchronous write'ı ancak bir replica aldıktan sonra onaylar, latency ekler; asynchronous hemen onaylar ama son write'ları kaybedebilir✓
- cSynchronous yalnızca read query'leri, asynchronous yalnızca write query'leri replicate eder
- dSynchronous tam olarak bir replica, asynchronous her zaman en az üç replica gerektirir
Açıklama:Synchronous replication write için bir replica'nın ack'ini bekler: daha güçlü durability, ama daha yüksek latency. Asynchronous önce yerelde onaylar: daha düşük latency, ama henüz gönderilmemiş write'lar failover'da kaybolabilir. (a) ilişkiyi ters çevirir.
Replication ScalingZorluk 3
Bir sistem asynchronous replication kullanıyor. Primary sert şekilde çöküyor ve bir replica primary'ye terfi ediliyor (promote). Kullanıcılar, çökmeden hemen önce commit edilen birkaç transaction'ın artık kayıp olduğunu bildiriyor. Bu neden mümkün?
- aPrimary, commit'leri replica almadan önce onaylar; dolayısıyla en yeni transaction'lar terfi eden replica'ya hiç ulaşmamış olabilir✓
- bBir replica'yı promote etmek tasarım gereği her zaman son bir dakikalık transaction'ları bilerek atar
- cAsynchronous replication yalnızca şema (DDL) değişikliklerini kopyalar, asıl satır verisini asla kopyalamaz
- dUygulama bu write'ları yerelde cache'ledi ve aslında hiç veritabanına göndermedi, primary'ye ulaşmadan çok önce sessizce düştüler
Açıklama:Async replication'da primary, değişiklik replica'ya ulaşmadan önce yerelde commit edip onaylar. Sert bir failover'da, terfi eden replica'ya henüz gönderilmemiş tüm write'lar kaybolur. Synchronous replication bunu (write latency bedeliyle) önlerdi.