Database Replication

နားလည်ထားရမယ့် အချက်

Database instance တစ်ခုတည်းက CPU၊ memory၊ disk I/O saturate မဖြစ်ခင် read query ဘယ်လောက်ကို ကိုင်တွယ်နိုင်တာမှာ ကန့်သတ်ချက်ရှိပါတယ် — machine ကြီးတစ်ခု ဝယ်လိုက်တာ (vertical scaling) ကလည်း ceiling ရှိပြီး ဈေးနှုန်းလည်း မြင့်တက်လာပါတယ်။ Leader-follower (primary-replica) replication ကတော့ node တစ်ခုကို leader အဖြစ် သတ်မှတ်ပြီး write အားလုံးကို လက်ခံစေကာ leader ကရတဲ့ change တိုင်းကို follower node တစ်ခု ဒါမှမဟုတ် တစ်ခုထက်ပိုပြီး stream ပို့ကာ synchronized copy တွေ ဖြစ်စေတဲ့ ဒီပြဿနာကို ဖြေရှင်းပေးပါတယ်။ ဒီနောက် read traffic ကို leader နဲ့ follower အားလုံးမှာ ခွဲပေးနိုင်ပြီး replica အရေအတွက်နဲ့ အလားတူ read capacity ကို တိုးပေးနိုင်ကာ write ကတော့ leader တစ်ခုတည်းကို ဖြတ်စေတဲ့အတွက် write consistency ကို နားလည်ရလွယ်ကူစေပါတယ်။ Catch ကတော့ replication lag ပါ — follower ကို change stream ပို့ဖို့ time ကုန်ရတဲ့အတွက် write တစ်ခုက leader မှာ ရောက်ပြီးမကြာခင် follower ကနေ stale data ကို ခဏတာ serve ပေးနေနိုင်ပါတယ် — classic symptom ကတော့ user တစ်ယောက် form တင်ပြီး reload လုပ်တာနဲ့ own change ကို မမြင်ရတာ (read ကို lagging replica ဆီ route လုပ်ခဲ့လို့) — ဒါကို 'read-your-own-writes' ပြဿနာလို့ခေါ်ပါတယ်။ ဒီလို tolerate မလုပ်နိုင်တဲ့ application တွေက read တချို့ကို leader ဆီပြန် route လုပ်ရပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ကြီးထွားလာတာနဲ့အမျှ course/lesson browse လုပ်တာက write (enrollment၊ quiz answer တင်တာ) ထက် read traffic ပိုများလာပါတယ် — ဒါကြောင့် read replica ထည့်ပါတယ်၊ leader က write ကိုင်တွယ်ပြီး lesson-page read တွေကို follower အများနဲ့ load-balance လုပ်ကာ write logic ကို မထိအောင် read capacity ကို တိုးပေးနိုင်ပါတယ်။ ဒါပေမဲ့ learner တစ်ယောက် quiz answer တင်ပြီးတာနဲ့ 'results' page ကို redirect လုပ်တဲ့အခါ lagging replica ကနေ read လုပ်ရင် ဟောင်းနေတဲ့ unanswered state ကို ခဏတာမြင်ရနိုင်ပါတယ် — ဒီအတွက် platform က ဒီ read တစ်ခုချင်းကို leader ဆီပြန် route လုပ်တာ (ဒါမှမဟုတ် replica catch-up ကို စောင့်တာ) ဖြင့် learner ကိုယ်တိုင် တင်ခဲ့တဲ့ submission ကို ချက်ချင်းမြင်ရအောင် အာမခံပေးပါတယ်။

• Leader-follower replication က write အားလုံးကို leader တစ်ခုတည်းကနေ ဖြတ်စေပြီး follower များပေါ်ကို stream ပို့ပါတယ်။
• Read traffic ကို leader နှင့် follower များပေါ် ခွဲပေးနိုင်တဲ့အတွက် read capacity ကို horizontal scale လုပ်နိုင်ပါတယ်။
• Replication lag ကြောင့် follower တွေက stale data ကို ခဏတာ serve ပေးနိုင်ပြီး 'read-your-own-writes' ပြဿနာ ဖြစ်နိုင်ပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

                 WRITES
                   |
                   v
            +--------------+
            |   LEADER     |
            +--------------+
              /    |    \
     replicate  replicate  replicate (lag: ~50-200ms)
            /       |        \
           v        v         v
     +---------+ +---------+ +---------+
     |Follower1| |Follower2| |Follower3|
     +---------+ +---------+ +---------+

          READ TRAFFIC (spread across all 4 nodes)
     Leader <-- reads --> F1 <-- reads --> F2 <-- reads --> F3

  Just after a write lands on Leader, F1/F2/F3 may briefly
  return the OLD value until replication catches up ("lag").

Read traffic ကို node ၄ ခုအထိ ခွဲပေးနိုင်တာက read capacity ကို တိုးစေပေမယ့် replication lag ကြောင့် follower တွေက write ပြီးချက်ချင်းမှာ stale data ပြနိုင်ကြောင်း ပြသပါတယ်။

Wikipedia — Replication (computing) — System Design