النسخُ المتماثل يُبقي خادمًا ثانيًا يحمل البيانات نفسها، يطبّق التغييرات نفسها بُعيد الأوّل. وهو نافعٌ لثلاثة أشياء، ويُنشَر بانتظامٍ لرابعٍ لا يقدّمه.

فيمَ يصلح

  • سعةُ القراءة — التقاريرُ والبحث تذهب إلى النسخة التابعة، والكتابةُ إلى الأصل.
  • نسخٌ احتياطيّ بلا حِمل — انسخ من التابعة ولا يلاحظ الموقعُ الحيّ شيئًا.
  • التحويلُ عند العطب — نسخةٌ دافئة جاهزةٌ للترقية، تحوّل إعادةَ بناءٍ إلى تحويلة.

وما ليس هو

النسخةُ التابعة ليست نسخةً احتياطية. فالأمر DROP TABLE orders يُنسَخ في أقلّ من ثانية، وقد صارت النسختان بلا ذلك الجدول. النسخُ الاحتياطيّ يقي من الأخطاء، والتوابعُ تقي من موت جهاز. وأنت تحتاجهما معًا — انظر النسخ الاحتياطيّ ضابطًا أمنيًّا.

التأخّرُ الذي لا يحسب له أحدٌ حسابًا

النسخُ المتماثل غيرُ متزامنٍ افتراضيًّا: فالأصلُ لا ينتظر. وكتابةٌ تتبعها في الحال قراءةٌ من التابعة قد تعود بالقيمة القديمة — يحفظ عميلٌ ملفَّه فيظهر كما كان.

mysql -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind|Replica_(IO|SQL)_Running'

والقاعدةُ التي تتجنّبه: لا تقرأ من التابعة إلّا حيث تُقبَل بياناتٌ متأخّرةٌ قليلًا. أمّا ما كتبه المستخدم للتوّ فيُقرأ من الأصل.

إقامتُه، في خطوطٍ عريضة

  1. فعّل التسجيل الثنائيّ على الأصل — log_bin، وserver_id فريدًا، وgtid_mode = ON.
  2. أنشئ مستخدمًا للنسخ — بصلاحيّة REPLICATION SLAVE وحدها.
  3. ازرع التابعةَ من نسخةٍ متّسقة — mysqldump --single-transaction --source-data=2
  4. وجّهها إلى الأصل وشغّلها — ثمّ راقب الحالة حتى تلحق.

وراقبها بعد ذلك

التابعةُ المتوقّفة صامتة. تظلّ تجيب القراءات ببياناتٍ عمرُها الآن أيّام، وذلك أسوأ من أن تكون ساقطة. فأنذِر على رايات التشغيل وعلى التأخّر معًا.