يبثّ الـ replication التغييرات من source (master) إلى واحد أو أكثر من replicas. يسجّل الـ source كل تغيير مؤكَّد في binary log (binlog) خاص به؛ ويقوم خيط الإدخال/الإخراج (I/O thread) في كل replica بنسخ ذلك السجل، ثم يعيد خيط SQL/التطبيق تشغيله، فتتقارب الـ replicas إلى البيانات نفسها.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (يسجّل صور الصفوف الفعلية، وهو الافتراضي الآمن) أو STATEMENT أو MIXED.وجّه الكتابات إلى الـ source ووزّع عبارات SELECT عبر الـ replicas. التطبيقات كثيفة القراءة (معظم تطبيقات الويب) توسّع القراءات بشكل خطي تقريبًا بإضافة replicas، بينما لا يزال الـ source الوحيد يتولّى كل الكتابات.
-- 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
لأن الـ replicas غير المتزامنة تتخلّف عن الـ source، فإن مستخدمًا يكتب ثم يقرأ فورًا من replica قد لا يرى تغييره الخاص (انتهاك "read-your-writes"). وجّه القراءات الحسّاسة لزمن الاستجابة أو المكتوبة للتوّ إلى الـ source، أو استخدم semi-sync.
الـ replication هو الخطوة الأولى المعتادة لتوسيع القراءات ولكسب نسخة احتياطية دافئة للتجاوز عند الفشل (failover) والنسخ الاحتياطي. وحدوده المميّزة — التأخّر، وعنق زجاجة الكتابة الوحيد — تشكّل التصاميم الحقيقية: فهي تفسّر لماذا تقرأ أحيانًا بيانات قديمة، ولماذا يحتاج توسيع الكتابة في النهاية إلى sharding، لا مجرّد مزيد من الـ replicas.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع