Database replication: leader-follower, lag ও failover
Replication আপনার database-এর কপি অন্য server-এ রাখে। এতে read ক্ষমতা ও নিরাপত্তা বাড়ে, কিন্তু আসে replication lag আর failover-এর সিদ্ধান্ত।
Replication মানে একই data একাধিক server-এ রাখা। লক্ষ্য: বেশি read ক্ষমতা, fault tolerance, আর কখনো user-এর কাছে কপি রেখে কম latency।
Leader-follower (primary-replica)
একজন leader সব write নেয়। Follower পরিবর্তন কপি করে এবং read সামলায়। App write পাঠায় leader-এ আর read ছড়িয়ে দেয় follower-দের মধ্যে। এটি সবচেয়ে প্রচলিত setup (PostgreSQL, MySQL ও আরও অনেকে)।
Synchronous বনাম asynchronous
- Synchronous: leader follower-এর নিশ্চিতকরণের অপেক্ষা করে। Leader মরলেও data যায় না, কিন্তু write ধীর এবং একটি ধীর follower সবকিছু আটকাতে পারে।
- Asynchronous: leader সাথে সাথে উত্তর দেয়, follower পরে ধরে। দ্রুত, কিন্তু crash-এ সাম্প্রতিক write হারাতে পারে।
- অনেক সিস্টেম একটি sync follower আর বাকিগুলো async রাখে।
Replication lag
Follower সামান্য পিছিয়ে থাকে। User profile সেভ করে refresh দিল, আর পিছিয়ে থাকা follower থেকে পড়ল: তার পরিবর্তন উধাও মনে হয়। সামলানোর উপায়:
- Read-your-writes: write-এর পর অল্প সময় leader থেকে পড়ুন।
- গুরুত্বপূর্ণ read leader-এ পাঠান।
- যেখানে ক্ষতি নেই (যেমন like সংখ্যা), পুরোনো data মেনে নিন।
Failover
Leader মরলে একজন follower-কে promote করতে হয়। এটি স্বয়ংক্রিয় বা হাতে করা যায়। ঝুঁকি: শেষ কয়েকটি write হারানো, এবং split brain, যখন দুটি server দুজনেই নিজেকে leader ভাবে। ঠিক coordination টুল আর fencing ব্যবহার করুন।
অন্য মডেল
বিশেষ প্রয়োজনে multi-leader (একাধিক জন write নেয়, conflict মেটাতে হয়) ও leaderless (Dynamo-ধাঁচের quorum read-write) আছে।
মূল কথা: read scaling ও নিরাপত্তার জন্য leader-follower নিন, lag মাথায় রেখে ডিজাইন করুন, আর দরকার পড়ার আগেই failover-এর মহড়া দিন।
System Design সিরিজের 9 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Database sharding: data একাধিক server-এ ভাগ করা.
