لماذا توجد نسخ للقراءة ومتى تكون مفيدة فعلاً

ما هي نسخة القراءة (وماذا ليست)\n\nنسخة القراءة هي نسخة من قاعدة بياناتك الرئيسية (غالبًا ما تُسمى الأصلية) تبقى محدثة عن طريق استقبال التغييرات منها باستمرار. يمكن لتطبيقك إرسال استعلامات قراءة فقط (مثل SELECT) إلى النسخة، بينما تواصل الأساسية التعامل مع كل عمليات الكتابة (مثل INSERT، UPDATE، وDELETE).\n\n### الوعد الأساسي\n\nالوعد بسيط: سعة قراءة أكبر دون وضع ضغط إضافي على الأساسية.\n\nإذا كان تطبيقك يتلقى الكثير من حركة "الإحضار"—صفحات رئيسية، صفحات منتج، ملفات تعريف المستخدمين، لوحات تحكم—فإن نقل بعض هذه القراءات إلى نسخة أو أكثر يمكن أن يحرر الأساسية لتركيز على عمليات الكتابة والقراءات الحرجة. في كثير من الإعدادات، يمكن فعل ذلك بتغييرات تطبيقية طفيفة: تحافظ على قاعدة بيانات واحدة كمصدر للحقيقة وتضيف نسخًا كمواقع إضافية للاستعلام.\n\n### ما ليست عليه نسخة القراءة\n\nنسخ القراءة مفيدة، لكنها ليست زر أداء سحري. فهي لا تفعل:\n\n- زيادة سعة الكتابة. تذهب كل الكتابات دائمًا إلى الأساسية.\n- إصلاح الاستعلامات البطيئة. إذا كان الاستعلام غير كفء (فاقد فهرس، مسح جداول ضخمة، نمط ربط سيئ)، فسيكون بطيئًا على النسخ أيضًا—فقط البُطء سيظهر في مكان آخر.\n- استبدال التصميم الجيد للمخطط والبيانات. النسخ لا تحل نقاط الاختناق الساخنة، صفوفًا كبيرة جدًا، أو جدول "كل شيء" متضخم.\n- إلغاء الحاجة للمراقبة. النسخ تضيف أجزاء متحركة: تأخر، حدود اتصالات، وسلوك فشل التحوّل.\n\n### توقعات لباقي الدليل\n\nفكر في النسخ كأداة لتحجيم القراءة مع مقايضات. يشرح بقية هذا المقال متى تفيد فعلاً، الطرق الشائعة التي تفشل بها، وكيف تؤثر مفاهيم مثل تأخر التكرار والاتساق في نهاية المطاف على ما يراه المستخدمون عند البدء بالقراءة من نسخة بدلاً من الأصلية.\n\n## لماذا توجد نسخ للقراءة\n\nخادم قاعدة بيانات أساسي واحد غالبًا ما يبدو "كافياً" في البداية. يستقبل الكتابات (إدخالات، تحديثات، حذف) ويجيب أيضًا على كل طلبات القراءة (SELECT) من تطبيقك، لوحات التحكم، والأدوات الداخلية.\n\nمع ازدياد الاستخدام، عادةً ما تتكاثر القراءات أسرع من الكتابات: كل مشاهدة صفحة قد تحفز عدة استعلامات، شاشات البحث قد تتفرع إلى العديد من الاستدعاءات، واستعلامات التحليلات قد تفحص الكثير من الصفوف. حتى لو كان حجم الكتابة معتدلًا، قد تصبح الأساسية عنق زجاجة لأنها تقوم بوظيفتين في آن واحد: قبول التغييرات بأمان وبسرعة، و\nتقديم تراكم متزايد من حركة القراءة بزمن استجابة منخفض.\n\n### فصل القراءات عن الكتابات\n\nالنسخ موجودة لتقسيم ذلك العبء. تبقى الأساسية مركزة على معالجة الكتابات والحفاظ على "مصدر الحقيقة"، بينما تتعامل نسخة أو أكثر مع الاستعلامات للقراءة فقط. عند تمكن تطبيقك من توجيه بعض الاستعلامات إلى النسخ، تقلل من ضغط CPU والذاكرة وI/O على الأساسية. هذا يحسن الاستجابة العامة ويترك مجالًا أكبر لفترات ذروة الكتابة.\n\n### التكرار في جملة واحدة\n\nالتكرار هو الآلية التي تبقي النسخ محدثة عن طريق نسخ التغييرات من الأساسية إلى خوادم أخرى. تسجل الأساسية التغييرات، وتطبق النسخ تلك التغييرات بحيث يمكنها الإجابة عن الاستعلامات باستخدام بيانات شبه متطابقة.\n\nهذا النمط شائع في العديد من نظم قواعد البيانات والخدمات المدارة (مثل PostgreSQL وMySQL والنُسخ المستضافة سحابيًا). تختلف التفاصيل، لكن الهدف واحد: زيادة سعة القراءة دون إجبار الأساسية على التحجيم الرأسي إلى ما لا نهاية.\n\n## كيف يعمل التكرار (نموذج ذهني بسيط)\n\nفكر في قاعدة البيانات الأساسية كمصدر الحقيقة. تقبل كل كتابة—إنشاء طلبات، تحديث ملفات تعريف، تسجيل مدفوعات—وتمنح تلك التغييرات ترتيبًا محددًا.\n\nثم تتبع نسخة أو أكثر الأساسية، وتنسخ تلك التغييرات حتى تتمكن من الإجابة عن استعلامات القراءة (مثل "أظهر سجل الطلبات الخاص بي") دون وضع عبء إضافي على الأساسية.\n\n### التدفق الأساسي\n\n1. الأصلية تقبل الكتابات وتُسجلها في سجل دائم (الاسم الدقيق يختلف حسب قاعدة البيانات).\n2. النسخ تبث أو تسترد تلك الإدخالات من السجل لدى الأساسية.\n3. النسخ تعيد تشغيل نفس التغييرات بنفس الترتيب، وتلحق تدريجيًا.\n\nيمكن تقديم القراءات من النسخ، لكن الكتابات تظل للأصلية.\n\n### التكرار المتزامن مقابل غير المتزامن (مستوى عالٍ)\n\nيمكن أن يحدث التكرار بنمطين عامين:\n\n- متزامن: تنتظر الأساسية تأكيدًا من نسخة (أو من أغلبية) بأنها استلمت التغيير قبل أن يعتبر الكتابة "ملتزمة". هذا يقلل القراءات القديمة، لكنه قد يزيد زمن الكتابة ويجعل الكتابات حساسة لمشاكل الشبكة/النسخ.\n- غير متزامن: تقوم الأساسية بتأكيد الكتابة فورًا، وتلحق النسخ لاحقًا. يحافظ هذا على سرعة الكتابات ومقاومتها، لكن النسخ قد تتأخر مؤقتًا.\n\n### تأخر التكرار و"الاتساق في نهاية المطاف"\n\nذلك التأخير—كون النسخ متأخرة عن الأساسية—يسمى تأخر التكرار. ليس فشلًا تلقائيًا؛ غالبًا ما يكون المقايضة التي تقبلها لتحجيم القراءات.\n\nللمستخدمين، يظهر التأخر كـ اتساق في نهاية المطاف: بعد تغيير شيء ما، سيصبح النظام متسقًا في كل الأماكن، لكن ليس بالضرورة فورًا.\n\nمثال: تحدّثت بريدك الإلكتروني وقمت بتحديث صفحة ملفك. إذا كانت الصفحة تُقدّم من نسخة متأخرة ببضع ثوانٍ، قد ترى البريد القديم لفترة وجيزة—حتى تطبق النسخة التغيير وتلحق بالأصلية.\n\n## متى تفيد نسخ القراءة فعليًا\n\nتفيد النسخ عندما تكون قاعدة البيانات الأساسية صحية بالنسبة للكتابة لكنها مُثقلة بخدمة حركة القراءة. تكون فعالة جدًا عندما يمكنك نقل جزء معنوي من حمل SELECT دون تغيير كيفية كتابة البيانات.\n\n### إشارات أنك مرتبط بالقراءة (وليس بالكتابة)\n\nابحث عن أنماط مثل:\n\n- CPU عالية على الأساسية خلال ذرى الحركة، بينما معدل الكتابات ليس مرتفعًا بشكل غير عادي\n- نسبة عالية جدًا من استعلامات SELECT مقارنة بـ INSERT/UPDATE/DELETE\n- بطء استعلامات القراءة خلال الذُرى رغم ثبات الكتابات\n- امتلاء مجموعات الاتصال ناجم عن نقاط نهاية ثقيلة القراءة (صفحات المنتج، الخلاصات، نتائج البحث)\n\n### كيف تؤكد أن المشكلة قراءة (مقاييس يجب فحصها)\n\nقبل إضافة نسخ، تحقق بإشارات ملموسة:\n\n- CPU مقابل I/O: هل CPU على الأساسية مشغول عندما ترتفع كمون القراءة؟ أم أن عائق القرص للقراءة هو المشكلة؟\n- خليط الاستعلامات: نسبة الوقت في جمل SELECT (من سجل الاستعلامات البطيئة/APM).\n- كمون p95/p99 للقراءة: تعقب نقاط نهاية القراءة وكمون استعلامات قاعدة البيانات منفصلة.\n- معدل ضرب ذاكرة/الـ buffer/cache: قد يعني معدل ضرب منخفض أن القراءات تجبر الوصول إلى القرص.\n- أهم الاستعلامات حسب الوقت الكلي: استعلام واحد مكلف قد يهيمن على "الحمل القراءة".\n\n### لا تتخطى الإصلاحات الأرخص\n\nغالبًا ما يكون أول تحرك أفضل هو الضبط: إضافة الفهرس الصحيح، إعادة كتابة استعلام واحد، تقليل مكالمات N+1، أو تخزين نتائج قراءات ساخنة مؤقتًا. هذه التغييرات قد تكون أسرع وأرخص من تشغيل نسخ.\n\n### قائمة مختصرة: نسخ أم ضبط؟\n\nاختر النسخ إذا:\n\n- معظم الحمل عبارة عن حركة قراءة، والقراءات مُحسّنة بالفعل نسبيًا\n- يمكنك تحمل قراءات قديمة أحيانًا للطلبات التي تُفَوَّض\n- تحتاج سعة إضافية بسرعة دون تغييرات خطيرة في المخطط/الاستعلام\n\nاختر الضبط أولًا إذا:\n\n- بعض الاستعلامات تهيمن على وقت القراءة الكلي\n- فهارس مفقودة أو ارتباطات غير فعالة واضحة\n- القراءات بطيئة حتى بحركة منخفضة (علامة على مشاكل تصميم الاستعلام)\n\n## حالات الاستخدام الأنسب\n\nنسخ القراءة ذات قيمة كبيرة حين تكون الأساسية مشغولة بمعالجة الكتابات (عمليات الدفع، التسجيلات، التحديثات)، لكن جزءًا كبيرًا من الحركة قراءة ثقيلة. في بنية أصلية–نسخة، دفع الاستعلامات المناسبة إلى النسخ يحسن أداء قاعدة البيانات دون تغيير ميزات التطبيق.\n\n### 1) لوحات التحكم والتحليلات التي لا يجب أن تبطئ المعاملات\n\nتجري لوحات التحكم غالبًا استعلامات طويلة: تجميع، تصفية عبر فترات زمنية كبيرة، أو ربط جداول متعددة. يمكن لتلك الاستعلامات أن تتنافس مع العمل المعاملاتي على CPU والذاكرة وذاكرة التخزين المؤقت.\n\nالنسخة مكان جيد لـ:\n\n- أحمال التقارير الداخلية\n- لوحات إدارة\n- طرق عرض "يومية/أسبوعية" للقياسات\n\nتحافظ على تركيز الأساسية على المعاملات السريعة والمتوقعة بينما تتحجّم قراءات التحليلات بشكل مستقل.\n\n### 2) صفحات البحث والتصفح ذات حجم قراءة كبير\n\nتولّد تصفح الكتالوج، ملفات تعريف المستخدمين، والخلاصات حجمًا عاليًا من استعلامات مماثلة. عندما يكون ضغط تحجيم القراءة هو عنق الزجاجة، يمكن للنسخ استيعاب الحركة وتقليل تقلبات الكمون.\n\nهذا فعال خصوصًا عندما تكون القراءات كثيرة الفروق (cache-miss) أو عندما لا يمكنك الاعتماد فقط على ذاكرة تطبيق.\n\n### 3) مهام خلفية تفحص الكثير من البيانات\n\nالتصدير، إعادة المعالجة، إعادة حساب الملخصات، وعمليات "إيجاد كل السجلات المطابقة لِـ X" قد تثر الأرضية على الأساسية. تشغيل هذه المسحّات ضد نسخة يكون غالبًا أكثر أمانًا.\n\nتأكد فقط أن المهمة تتسامح مع الاتساق النهائي: قد لا ترى أحدث التحديثات خلال تأخر التكرار.\n\n### 4) قراءات متعددة المناطق لخفض الكمون (مع تحذير التشارك)\n\nإذا كان لديك مستخدمون عالميون، وضع نسخ قراءة أقرب إليهم يقلل زمن الرحلة ذهابًا وإيابًا. المقايضة هي تعرض أقوى للقراءات القديمة خلال التأخر أو مشكلات الشبكة، لذا فهي أفضل للصفحات التي "تقارب الحداثة" مثل التصفح، التوصيات، والمحتوى العام.\n\n## أين يمكن أن تفشل النسخ\n\nالنسخ رائعة عندما تكون "قريبًا بما فيه الكفاية" مقبولًا. تفشل عندما يفترض منتجك ضمنًا أن كل قراءة تعكس أحدث كتابة مباشرة.\n\n### العرض الكلاسيكي: "حدّثت للتو، فلم يتغير؟"\n\nيحرر المستخدم ملفه، يقدّم نموذجًا، أو يغيّر إعدادات—وتحمل الصفحة التالية من نسخة متأخرة ببضع ثوانٍ. نجح التحديث، لكن المستخدم يرى بيانات قديمة ويحاول مرة أخرى، يرسل طلبًا مزدوجًا، أو يفقد الثقة.\n\nهذا يكون مؤلمًا خصوصًا في المسارات التي يتوقع فيها المستخدم تأكيدًا فوريًا: تغيير البريد الإلكتروني، تبديل الإعدادات، رفع مستند، أو نشر تعليق ثم إعادة التوجيه للعرض.\n\n### الشاشات التي "يجب أن تكون حديثة" (لا تقامر هنا)\n\nبعض القراءات لا تحتمل أن تكون قديمة حتى للحظات قليلة:\n\n- عربات التسوق وإجماليات الدفع\n- أرصدة المحافظ، نقاط الولاء، تعداد المخزون\n- شاشات حالة "هل وصل الدفع؟"\n\nإذا كانت النسخة متأخرة، قد تعرض إجماليات خاطئة، تبيع مخزونًا منتهيًا، أو تعرض رصيدًا قديمًا. حتى لو صحح النظام نفسه لاحقًا، تجربة المستخدم (وحجم الدعم) تتأثر.\n\n### أدوات الإدارة والعمليات تحتاج الحقيقة الأحدث\n\nلوحات داخلية تقود قرارات فعلية: مراجعة الاحتيال، دعم العملاء، تنفيذ الطلبات، المراجعة والاعتدال، واستجابة الحوادث. إذا قرأت هذه الأدوات من النسخ، قد تتخذ إجراءات على بيانات غير مكتملة—مثلاً استرداد دفعة سبق استردادها بالفعل أو تفويت حالة حديثة.\n\n### حل عملي: توجيه "قراءة-بعد-الكتابة" إلى الأساسية\n\nنمط شائع هو التوجيه الشرطي:\n\n- بعد كتابة المستخدم، أرسل قراءاته التأكيدية إلى الأساسية لفترة قصيرة (ثوانٍ إلى دقائق).\n- احتفظ بالقراءات الخلفية أو المجهولة الهوية على النسخ.\n\nهذا يحافظ على فوائد النسخ دون أن يجعل الاتساق لعبة تخمين.\n\n## فهم تأخر التكرار والقراءات القديمة\n\nتأخر التكرار هو الفارق الزمني بين كتابة ما على الأساسية وظهور التغيير نفسه على النسخة. إذا قرأت من نسخة خلال ذلك الفارق، قد تسترجع نتائج "قديمة"—بيانات كانت صحيحة قبل لحظات لكنها لم تعد كذلك.\n\n### لماذا يحدث التأخر\n\nالتأخر طبيعي، وعادة ما يزداد تحت الضغط. الأسباب الشائعة:\n\n- قفزات الحمل على الأساسية: الكثير من الكتابات تعني المزيد من التغييرات للنقل والتطبيق.\n- نسخة ضعيفة المواصفات أو مشغولة: لا تستطيع تطبيق التغييرات بالسرعة المطلوبة (CPU، قرص I/O).\n- زمن الشبكة أو تقلبها: تأخير في نقل تيار التكرار.\n- معاملات كبيرة / تحديثات جماعية: تغيير واحد كبير قد يستغرق وقتًا للتسلسل والنقل وإعادة التشغيل.\n\n### كيف تظهر القراءات القديمة في سلوك المنتج\n\nلا يؤثر التأخر على "الحداثة" فحسب—بل على الصواب من منظور المستخدم:\n\n- يحدث المستخدم تحديثًا لملفه، ثم عند التحديث يرى القيمة القديمة.\n- شارات "رسائل غير مقروءة" أو العدادات تنحرف لأن الحسابات مبنية على صفوف قديمة.\n- شاشات الإدارة/التقارير تفوّت أحدث الطلبات أو عمليات الاسترداد أو تغييرات الحالة.\n\n### طرق عملية للتعامل معه\n\nابدأ بتحديد ما الذي يمكن لخاصيتك تحمله:\n\n- أضف نافذة تحمل: "قد تكون البيانات قديمة حتى 30 ثانية" مقبولة للعديد من اللوحات.\n- وجّه قراءة-بعد-الكتابة إلى الأصلية: بعد أن يغير المستخدم شيئًا، اقرأ ذلك الكيان من الأساسية لفترة قصيرة.\n- رسائل واجهة المستخدم: اضبط التوقعات ("جارٍ التحديث..."، "قد يستغرق الظهور بضع ثوان").\n- منطق إعادة المحاولة: إذا كانت قراءة حرجة تفتقد سجلًا كُتب لتوه، أعد المحاولة على الأساسية أو بعد مهلة قصيرة.\n\n### ما الذي تراقبه وتصدر إنذارات بشأنه\n\nتعقب تأخر النسخ (بالثواني/بالبايت)، معدل تطبيق النسخ، أخطاء التكرار، وCPU/قرص I/O على النسخ. أنبه عندما يتجاوز التأخر حد تحملك (مثلاً 5s، 30s، 2m) وعندما يستمر التأخر في الازدياد مع الزمن (علامة أن النسخة لن تلحق دون تدخل).\n\n## تحجيم القراءة مقابل تحجيم الكتابة (مقايضات رئيسية)\n\nالنسخ هي أداة لـ تحجيم القراءة: إضافة أماكن أكثر لخدمة استعلامات SELECT. ليست أداة لـ تحجيم الكتابة: زيادة عدد عمليات INSERT/UPDATE/DELETE التي يمكن لنظامك قبولها.\n\n### تحجيم القراءة: ما الذي تجيده النسخ\n\nعند إضافة نسخ، تضيف سعة قراءة. إذا كان تطبيقك محصورًا عند نقاط نهاية قراءة ثقيلة، يمكنك توزيع تلك الاستعلامات عبر عدة آلات.\n\nغالبًا ما يُحسن ذلك:\n\n- كمون الاستعلام تحت الحمل (تنافس أقل على الأساسية)\n- معدل مرور القراءة (مزید CPU/ذاكرة/I/O متاحة لـ SELECT)\n- عزل القراءات الثقيلة، مثل أحمال التقارير، حتى لا تتداخل مع حركة المعاملات\n\n### تحجيم الكتابة: ما الذي لا تفعله النسخ\n\nمفهوم شائع خاطئ هو "المزيد من النسخ = مزيد من معدل الكتابة". في إعداد أساسي-نسخة التقليدي، كل الكتابات ما تزال تذهب إلى الأساسية. في الواقع، يمكن للنسخ أن تزيد قليلًا من عمل الأساسية لأنها يجب أن تولد وترسل بيانات التكرار إلى كل نسخة.\n\nإذا كان ألمك هو معدل كتابة عالي، فالنسخ لن تحل المشكلة. تبحث عادةً عن مقاربات مختلفة (تحسين استعلام/فهرس، تجميع الدُفعات، تقسيم/شِطر، أو تغيير نموذج البيانات).\n\n### حدود الاتصالات وتجميعها: عنق الزجاجة الخفي\n\nحتى لو منحتك النسخ CPU قراءة أكثر، قد لا تزال تضرب حدود الاتصال أولًا. كل عقدة قاعدة بيانات لها عدد أقصى من الاتصالات المتزامنة، وإضافة نسخ قد تضاعف عدد الأماكن التي قد يتصل بها تطبيقك—دون تقليل الطلب الكلي.\n\nقاعدة عملية: استخدم تجميع الاتصالات (pooling) واحتفظ بعدد الاتصالات لكل خدمة مقصودًا. وإلا، قد تصبح النسخ "المزيد من قواعد البيانات التي يمكن إجهادها".\n\n### تكاليف: السعة ليست مجانية\n\nالنسخ تضيف تكاليف حقيقية:\n\n- المزيد من العقد (تكلفة الحوسبة)\n- المزيد من التخزين (كل نسخة عادةً تخزن نسخة كاملة)\n- المزيد من جهد العمليات (مراقبة التأخر، استراتيجية النسخ الاحتياطية/الاستعادة، تغييرات المخطط، الاستجابة للحوادث)\n\nالمقايضة بسيطة: النسخ تشتري لك رأسًا للقِراءة والعزل، لكنها تضيف تعقيدًا ولا ترفع سقف الكتابة.\n\n## التوفر العالي والفشل: ما الذي تفعله النسخ\n\nيمكن للنسخ تحسين توفر القراءة: إذا كانت الأساسية محملة أو متعطلة مؤقتًا، قد تظل قادرًا على تقديم بعض حركة القراءة من النسخ. هذا يحافظ على صفحات العملاء متاحة (للمحتوى الذي يتسامح مع بعض القدر من التقادم) ويقلل نطاق الانعكاس لحادث الأساسية.\n\nما لا توفره النسخ بمفردها هو خطة توفر عالية كاملة. عادةً ما لا تكون النسخة جاهزة لقبول الكتابات تلقائيًا، و"وجود نسخة قابلة للقراءة" يختلف عن "النظام قادر بأمان وبسرعة على قبول الكتابات مرة أخرى".\n\n### الترقية والفشل (مفهوميًا)\n\nالتعافي عادة يعني: اكتشاف فشل الأساسية → اختيار نسخة → ترقيتها لتصبح الأساسية الجديدة → إعادة توجيه الكتابات (وغالبًا القراءات) إلى العقدة المرقاة.\n\nبعض قواعد البيانات المدارة تؤتمت الكثير من هذا، لكن الفكرة الأساسية تبقى: أنت تغيّر من يحق له قبول الكتابات.\n\n### مخاطر رئيسية يجب التخطيط لها\n\n- بيانات النسخة المتأخرة: قد تكون النسخة متأخرة. إذا قمت بترقيتها، قد تفقد آخر الكتابات التي لم تُنسخ بعد.\n- تجنب الانقسام الدماغي (split-brain): يجب منع عقدتين من قبول الكتابات في آن واحد. لذلك عادةً ما تُمنح عملية الترقية سلطة واحدة (لوحة تحكم مُدارة، نظام أغلبية، أو إجراءات تشغيل صارمة).\n- إعادة التوجيه والذاكرات المؤقتة (caches): يحتاج تطبيقك لآلية موثوقة للتبديل—سلاسل اتصال، DNS، بروكسي، أو موجه قاعدة بيانات. تأكد من أن حركة الكتابة لا تستمر بالوصول إلى الأصل القديم "بطريق الخطأ".\n\n### اختبره كما تختبر ميزة\n\nعامل فشل التحوّل كشيء تتدرب عليه. قم بتشغيل اختبارات يوميات الحوادث في بيئة التحضير (وبعناية في الإنتاج خلال نوافذ منخفضة المخاطر): حاكي فقدان الأساسية، قِس زمن الاسترداد، تحقق من التوجيه، وتأكد أن تطبيقك يتعامل مع فترات القراءة فقط وإعادة الاتصال بسلاسة.\n\n## أنماط التوجيه العملية (فصل القراءة/الكتابة)\n\nالنسخ تفيد فقط إذا وصلت إليها الحركة فعليًا. "فصل القراءة/الكتابة" هو مجموعة القواعد التي ترسل الكتابات إلى الأساسية والقراءات المؤهلة إلى النسخ—دون كسر الصحة.\n\n### النمط 1: الفصل في التطبيق\n\nأبسط نهج هو التوجيه الصريح في طبقة الوصول للبيانات:\n\n- كل الكتابات (INSERT/UPDATE/DELETE، تغييرات المخطط) تذهب إلى الأساسية.\n- فقط قراءات محددة مسموح لها باستخدام نسخة.\n\nهذا سهل الفهم وسهل التراجع. كما يمكنك ترميز قواعد الأعمال مثل "بعد السداد، اقرأ حالة الطلب من الأساسية لفترة".\n\n### النمط 2: الفصل عبر وكيل أو برنامج تشغيل ذكي\n\nيفضل بعض الفرق وكيل قاعدة بيانات أو برنامج تشغيل ذكي يفهم نقاط نهاية "الأصل مقابل النسخة" ويوجه بناءً على نوع الاستعلام أو إعدادات الاتصال. هذا يقلل تغييرات الكود، لكن كن حذرًا: الوكلاء لا يمكنهم دائمًا معرفة أي القراءات "آمنة" من منظور المنتج.\n\n### اختيار أي استعلامات يمكن توجيهها بأمان إلى النسخ\n\nمرشّحون جيدون:\n\n- أحمال التحليلات والتقارير واللوحات\n- صفحات البحث/التصفح حيث تقبل البيانات القريبة من الحداثة\n- مهام الخلفية التي تعيد المحاولة ولا تحتاج أحدث قيمة\n\nتجنّب توجيه القراءات التي تلي كتابة المستخدم مباشرة (مثل "تحديث الملف → إعادة تحميل الملف") إلا إذا كان لديك استراتيجية اتساق.\n\n### المعاملات واتساق الجلسة\n\nضمن معاملة، احتفظ بكل القراءات على الأساسية.\n\nخارج المعاملات، فكر في "القراءة-بعد-الكتابة" للجلسات: بعد كتابة، أثبت تلك الجلسة/المستخدم إلى الأساسية لفترة TTL، أو وجّه استعلامات المتابعة المحددة إلى الأساسية.\n\n### ابدأ صغيرًا وقِس\n\nأضف نسخة واحدة، وجّه مجموعة محدودة من النقاط النهائية/الاستعلامات، وقارن قبل/بعد:\n\n- CPU الأساسية وقراءة IOPS\n- استخدام النسخة\n- معدل الأخطاء ونسب الكمون\n- الحوادث المرتبطة بالقراءات القديمة\n\nوسّع التوجيه فقط عندما يكون الأثر واضحًا وآمنًا.\n\n## أساسيات المراقبة والتشغيل\n\nالنسخ ليست "أعددها ثم انسها". إنها خوادم قاعدة بيانات إضافية لها حدود أداء ووضعيات فشل ومهام تشغيل خاصة بها. قليل من انضباط المراقبة عادة ما يكون الفرق بين "النسخ أفادت" و"النسخ أضافت ارتباكًا".\n\n### ماذا تراقب (القليل من المقاييس المهمة)\n\nتركيزك على مؤشرات تشرح أعراض المستخدمين:\n\n- تأخر النسخ: كم هي متأخرة النسخة عن الأساسية (ثوانٍ، بايت، أو موقع WAL/LSN). هذه إنذار مبكر للقراءات القديمة.\n- أخطاء التكرار: انقطاعات الاتصال، فشل المصادقة، امتلاء القرص، أو مشكلات مقعد التكرار. عاملها كحوادث.\n- كمون الاستعلام (p50/p95) على النسخ مقابل الأساسية: قد تكون النسخ بطيئة حتى عندما تكون الأساسية بخير.\n- معدل ضرب الكاش: نسخة تفقد الكاش باستمرار قد تظهر كمونًا أعلى بعد إعادة التشغيل أو تحولات الحركة.\n\n### تخطيط السعة: كم عدد النسخ التي تحتاجها؟\n\nابدأ بنسخة واحدة إذا كان هدفك تخفيف القراءة. أضف المزيد عندما يكون لديك قيد واضح:\n\n- معدل مرور القراءة: نسخة واحدة قد لا تكفي لذروة QPS أو استعلامات تحليلية ثقيلة.\n- العزل: خصص نسخة لتحميل التقارير حتى لا تسرق لوحات البيانات موارد حركة المستخدم.\n- الجغرافيا: نسخة لكل منطقة تقلل الكمون لكنها تزيد عبء التشغيل.\n\nقاعدة عملية: زد النسخ فقط بعد تأكيد أن القراءات هي عنق الزجاجة (وليس الفهارس، الاستعلامات البطيئة، أو الكاش التطبيق).\n\n### مهام تشغيلية شائعة\n\n- النسخ الاحتياطية: قرر من أين تُأخذ النسخ الاحتياطية. أخذ النسخ من نسخة يمكن أن يقلل الحمل على الأساسية، لكن تحقق من متطلبات الاتساق وصحة النسخة.\n- تغييرات المخطط: اختبر الترحيلات مع التكرار في الاعتبار (DDL طويل الأمد قد يزيد التأخر). نسق التحديثات بحيث يبقى التطبيق والمخطط متوافقين أثناء الانتشار.\n- نوافذ الصيانة: ترقية أو إعادة تشغيل النسخ تقلل مؤقتًا من سعة القراءة. درّ دورات بحيث لا تنخفض سعة القراءة تحت الحد المطلوب.\n\n### قائمة فحص استكشاف الأخطاء: "النسخ بطيئة"\n\n1. تحقق من تأخر النسخ: إذا كان مرتفعًا، قد يعيد المستخدمون المحاولات أو يشاهدون بيانات قديمة.\n2. قارن سجلات الاستعلامات البطيئة على النسخة مقابل الأساسية: غالبًا ما تظهر استعلامات التقارير هنا.\n3. تحقق من CPU، الذاكرة، قرص I/O، والشبكة على مضيف النسخة.\n4. ابحث عن تنازع القفل أو معاملات طويلة على الأساسية التي تؤخر التكرار.\n5. تأكد أن توجيه القراءات لا يُثقل نسخة واحدة (تحميل غير متوازن).\n6. تحقق من أن الفهارس موجودة على النسخ (ينبغي أن تعكس الأساسية) والإحصاءات محدثة.

\n## البدائل وإطار قرار بسيط\n\nالنسخ أداة واحدة لتحجيم القراءة، لكنها نادرًا ما تكون الذراع الأولى لسحبها. قبل إضافة التعقيد التشغيلي، تحقق ما إذا كان إصلاح أبسط يعطيك النتيجة نفسها.\n\n### بدائل جربها أولاً\n\n يمكن أن يزيل فئات كاملة من القراءات من قاعدة البيانات. للصفحات "قليلة التغيير" (تفاصيل المنتج، ملفات تعريف عامة)، ذاكرة تطبيق أو CDN يمكن أن تخفف الحمل بشكل كبير—بدون إدخال تأخر التكرار.\n\n غالبًا ما تتفوق على النسخ للحالة الشائعة: بعض الاستعلامات المكلفة تحرق CPU. إضافة الفهرس الصحيح، تقليل أعمدة ، تجنب N+1، وإصلاح الارتباطات السيئة يمكن أن يحوّل "نحتاج نسخ" إلى "نحتاج خطة أفضل".\n\n مفيدة عندما يكون الحمل بطبيعته ثقيلًا (تحليلات، لوحات). بدلًا من تشغيل استعلامات معقدة باستمرار، خزّن نتائج محسوبة وقم بتحديثها مجدولًا.\n\n### متى تفكر في الشِطرَة/التجزئة بدلاً من ذلك\n\nإذا كانت عنق الزجاجة (صفوف ساخنة، تنازع قفل، حدود I/O للكتابة)، فالنسخ لن تساعد كثيرًا. هنا قد يكون تقسيم الجداول حسب الزمن/العميل، أو شطر البيانات بحسب معرّف العميل، هو الحل لتوزيع حمل الكتابة وتقليل التنافس. هذه خطوة معمارية أكبر لكنها تعالج القيد الحقيقي.\n\n### إطار قرار بسيط\n\nاسأل أربعة أسئلة:\n\n1. تقليل كمون القراءة، عزل أحمال التقارير، أم تحسين التوفر؟\n2. إذا كنت لا تحتمل قراءات قديمة، قد تسبب النسخ مشكلات مرئية للمستخدم.\n3. النسخ تضيف تكاليف بنية تحتية وتشغيل مستمرة.\n4. فصل القراءة/الكتابة، التعامل مع الاتساق النهائي، واختبار الفشل ليست أمورًا بسيطة.\n\nإذا كنت تجري نموذجًا أوليًا أو تطلق خدمة بسرعة، فالمساعدة في تضمين هذه القيود في التصميم مبكرًا مفيدة. على سبيل المثال، فرق تبني على غالبًا ما تبدأ بأصلية واحدة للبساطة، ثم تنتقل إلى نسخ بمجرد أن تبدألوحات القيادة، الخلاصات، أو تقارير داخلية بالتنافس مع حركة المعاملات. استخدام سير عمل قائم على التخطيط يسهل اتخاذ قرار مسبق حول أي نقاط نهاية يمكن أن تقبل الاتساق النهائي وأيها يجب أن تكون "قراءة-بعد-الكتابة" من الأساسية.\n\nإذا أردت مساعدة في اختيار مسار، راجع /pricing للاطلاع على الخيارات، أو تصفح الأدلة المرتبطة في /blog.