Replication, değişiklikleri bir source (master)'dan bir veya daha fazla replica'ya akıtır. Source, commit edilmiş her değişikliği binary log (binlog)'una kaydeder; her replica'nın I/O thread'i o log'u kopyalar ve bir SQL/applier thread'i onu yeniden oynatır, böylece replica'lar aynı veriye yakınsar.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (gerçek satır görüntülerini loglar, güvenli varsayılan), STATEMENT veya MIXED.Yazmaları source'a yönlendirin ve SELECT'leri replica'lara dağıtın. Okuma ağırlıklı uygulamalar (çoğu web uygulaması) replica ekleyerek okumaları neredeyse doğrusal olarak ölçekler, tek source ise tüm yazmaları hâlâ yönetir.
-- On a replica, watch how far behind it is:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Async replica'lar source'un gerisinde kaldığından, yazıp hemen bir replica'dan okuyan bir kullanıcı kendi değişikliğini görmeyebilir ("read-your-writes" ihlali). Gecikmeye duyarlı veya yeni yazılmış okumaları source'a yönlendirin ya da semi-sync kullanın.
Replication, okumaları ölçeklemenin ve failover/yedekleme için sıcak bir yedek elde etmenin standart ilk adımıdır. Belirleyici sınırlaması — lag ve tek yazma darboğazı — gerçek tasarımları şekillendirir: bazen neden bayat veri okuduğunuzu ve yazma ölçeklemesinin sonunda neden yalnızca daha çok replica değil, sharding gerektirdiğini açıklar.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap