Replication تبدیلیوں کو ایک source (master) سے ایک یا زیادہ replicas تک stream کرتی ہے۔ source ہر commit شدہ تبدیلی کو اپنے binary log (binlog) میں ریکارڈ کرتی ہے؛ ہر replica کا I/O thread اُس log کی نقل کرتا ہے اور ایک SQL/applier thread اسے دوبارہ چلاتا ہے، تاکہ replicas ایک ہی ڈیٹا پر آ جائیں۔
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (اصل row images log کرتی ہے، محفوظ default)، STATEMENT، یا MIXED۔writes کو source کی طرف بھیجیں اور SELECTs کو replicas پر پھیلا دیں۔ Read-heavy apps (زیادہ تر web apps) replicas بڑھا کر reads کو تقریباً linearly scale کرتی ہیں، جبکہ واحد source اب بھی تمام writes سنبھالتی ہے۔
-- 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 replicas source سے پیچھے رہتی ہیں، ایک user جو لکھتا ہے پھر فوراً کسی replica سے پڑھتا ہے شاید اپنی ہی تبدیلی نہ دیکھ سکے ("read-your-writes" کی خلاف ورزی)۔ latency کے لیے حساس یا ابھی لکھی گئی reads کو source کی طرف route کریں، یا semi-sync استعمال کریں۔
Replication reads scale کرنے اور failover/backups کے لیے ایک warm standby حاصل کرنے کا معیاری پہلا قدم ہے۔ اس کی نمایاں حد — lag، اور واحد write bottleneck — حقیقی designs کی تشکیل کرتی ہے: یہ واضح کرتی ہے کہ آپ کبھی کبھی stale ڈیٹا کیوں پڑھتے ہیں اور write scaling کو بالآخر sharding کیوں درکار ہوتی ہے، صرف زیادہ replicas نہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں