Örnek sorular
Mysql Replication ScalingZorluk 1
MySQL replikasyonunda, source (ana) sunucu bir replica'nın aynı değişiklikleri uygulayabilmesi için gerçekte ne gönderir?
- aInnoDB buffer pool sayfalarının ham bir TCP akışı
- bSource'ta gerçekleşen değişiklikleri tanımlayan binary log (binlog) olaylarından oluşan bir akış✓
- cTüm veri dizininin her gece alınan sıkıştırılmış bir kopyası
- dReplica'nın
INSERT ifadeleri olarak yeniden oynattığı bir SELECT sonuç kümesi
Açıklama:MySQL replikasyonu binlog tabanlıdır: source her değişikliği (ya da formata bağlı olarak sonuç satır değişikliklerini) binary log'una yazar, replica'lar bunu bir replication I/O thread'i ile okuyup yerelde relay log olarak saklar ve bir SQL/apply thread'iyle uygular. Normal replikasyonda ham sayfa akışı ya da periyodik tam dizin kopyası yoktur.
Mysql Replication ScalingZorluk 2
binlog_format, STATEMENT, ROW veya MIXED olarak ayarlanabilir. Bir UPDATE için ROW formatı binary log'a gerçekte neyi kaydeder?
- a
UPDATE ifadesinin tam SQL metnini, replica'da olduğu gibi yeniden çalıştırılmak üzere - bYalnızca etkilenen satırın primary key'ini, yeni değerleri bulmayı replica'ya bırakarak
- cSQL ifadesinin kendisi yerine, değişen satırların gerçek önce/sonra (before/after) imajlarını✓
- dYalnızca replica veri bütünlüğünü doğrulamak için kullanılan, etkilenen sayfanın bir checksum'ı
Açıklama:Row-based replication (RBR), SQL ifadesi yerine gerçek veri değişikliklerini — UPDATE/DELETE için satırın önce imajını ve sonra imajını — loglar. Bu, NOW(), RAND() gibi fonksiyonlar kullanan veya yan etkili trigger'lara sahip ifadelerde bile source ve replica'da farklı davranabilecek durumları deterministik hale getirir; statement-based replikasyon ise SQL metnini loglayıp yeniden çalıştırır.
Mysql Replication ScalingZorluk 2
Bir geliştirici, bir tabloya eklenen değeri üretmek için UUID() çağıran bir stored routine yazıyor ve sunucu binlog_format=STATEMENT ile çalışıyor. Bu neden replikasyon için risklidir?
- a
UUID() deterministik değildir; replica aynı ifadeden farklı bir değer üretebilir✓ - b
UUID(), statement-based replikasyonda stored routine içinde hiç kullanılamaz ve ifade doğrudan reddedilir - cStatement-based replikasyon yalnızca sayısal kolon tiplerini destekler, bu yüzden UUID string kolonu replikasyonu bozar
- dRisk yoktur; MySQL
UUID()'i otomatik algılar ve binlog_format ne olursa olsun ifadeyi anında row-based'e çevirir
Açıklama:Statement-based replikasyon (SBR), loglanan SQL'i replica'da yeniden çalıştırır; bu yüzden UUID(), RAND(), bazı bağlamlarda NOW() gibi deterministik olmayan herhangi bir fonksiyon source ve replica'da farklı sonuçlar üretip veri sapmasına yol açabilir. MySQL'in row-based replikasyonu getirmesinin ve MIXED formatın güvensiz bulduğu ifadeleri otomatik olarak row-based loglamaya geçirmesinin tam nedeni budur.
Mysql Replication ScalingZorluk 2
Modern MySQL replikasyon terminolojisinde (8.0.23+), bir replica'nın source'tan ne kadar geride olduğu dahil replikasyon durumunu hangi komut gösterir?
- a
SHOW ENGINE INNODB STATUS - b
SHOW PROCESSLIST - c
SHOW BINLOG EVENTS - d
SHOW REPLICA STATUS✓
Açıklama:SHOW REPLICA STATUS (eski SHOW SLAVE STATUS'un modern adı, ikisi de hâlâ destekleniyor), replica'nın I/O ve SQL thread durumunu, bağlı olduğu source'u ve replikasyon gecikmesini gösteren Seconds_Behind_Source (eski adıyla Seconds_Behind_Master) değerini raporlar. SHOW ENGINE INNODB STATUS ve SHOW PROCESSLIST genel amaçlı diagnostiklerdir, özel olarak replikasyon durumuyla ilgili değildir.
Mysql Replication ScalingZorluk 2
GTID (Global Transaction Identifier) tabanlı replikasyonun, klasik dosya/pozisyon tabanlı replikasyona kıyasla temel amacı nedir?
- aGTID'ler, transaction'lar ayrı bir metadata tablosunda takip edildiği için binary log ihtiyacını tamamen ortadan kaldırır
- bGTID'ler replikasyonu varsayılan olarak asenkron yerine senkron yapar
- cHer transaction'a global olarak benzersiz bir kimlik atanır, böylece bir replica yeni bir source'a yönlendirildiğinde binlog dosyasını ve pozisyonunu elle belirtmeye gerek kalmadan doğru şekilde devam edebilir✓
- dGTID'ler yalnızca
mysqldump export'larını hızlandırmak için kullanılır, replica failover'ıyla ilgili değildir
Açıklama:GTID tabanlı replikasyonda (GTID_MODE=ON), her transaction benzersiz bir kimlikle (source_uuid:transaction_id) etiketlenir. Bir replica yeni bir source'a yönlendirildiğinde (ör. failover sırasında), MySQL GTID kümelerini karşılaştırarak hangi transaction'ların eksik olduğunu otomatik belirleyebilir; klasik pozisyonel replikasyondaki gibi operatörün tam binlog dosya adını ve byte offset'ini elle takip etmesi gerekmez.
Mysql Replication ScalingZorluk 1
Varsayılan olarak, bir source bir transaction'ı commit edip replica'lara gönderdiğinde, client'a başarı dönmeden önce herhangi bir replica'nın alındığını onaylamasını bekler mi?
- aHayır — varsayılan MySQL replikasyonu asenkrondur, bu yüzden source herhangi bir replica'yı beklemeden commit edip başarı döner✓
- bEvet — source, commit etmeden önce her zaman TÜM replica'ların transaction'ı uygulamasını bekler
- cEvet — source, varsayılan olarak commit etmeden önce tam olarak bir replica'nın onaylamasını bekler
- dBu, herhangi bir replikasyon ayarına değil, replike edilen tabloların storage engine'ine bağlıdır
Açıklama:Standart (asenkron) MySQL replikasyonu herhangi bir replica onayı gerektirmez: source yerel olarak commit edip client'a başarı döner, sonra binlog olaylarını replica'lara bağımsız olarak gönderir. Bu en iyi yazma gecikmesini sağlar ama commit'ten hemen sonra bir çökme, hiçbir replica'ya ulaşmamış transaction'ların kaybolmasına yol açabilir — semi-sync replikasyonun tam olarak kapatmaya çalıştığı boşluk budur.