Replication একটি source (master) থেকে এক বা একাধিক replica-তে পরিবর্তন stream করে। source প্রতিটি committed পরিবর্তন তার binary log (binlog)-এ রেকর্ড করে; প্রতিটি replica-র I/O thread সেই log copy করে এবং একটি SQL/applier thread এটি replay করে, তাই replica-গুলো একই ডেটায় converge করে।
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (প্রকৃত row image log করে, নিরাপদ ডিফল্ট), STATEMENT, বা MIXED।write-গুলো source-এ নির্দেশ করুন এবং SELECT-গুলো replica জুড়ে ছড়িয়ে দিন। Read-heavy app (বেশিরভাগ web app) replica যোগ করে প্রায় linearly read scale করে, যখন একক source এখনও সব write সামলায়।
-- 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 source-এর পিছনে থাকে, একজন user যে লেখে তারপর সঙ্গে সঙ্গে একটি replica থেকে পড়ে সে নিজের পরিবর্তন নাও দেখতে পারে ("read-your-writes" লঙ্ঘন)। latency-sensitive বা সদ্য-লেখা read-গুলো source-এ route করুন, অথবা semi-sync ব্যবহার করুন।
Replication হলো read scale করার এবং failover/backup-এর জন্য একটি warm standby পাওয়ার আদর্শ প্রথম ধাপ। এর সংজ্ঞায়িত সীমাবদ্ধতা — lag, এবং একক write bottleneck — বাস্তব design গঠন করে: এটি ব্যাখ্যা করে কেন আপনি কখনো stale ডেটা পড়েন এবং কেন write scaling-এর জন্য শেষ পর্যন্ত sharding দরকার, কেবল বেশি replica নয়।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন