قواعد البيانات

طلب قاعدة بيانات، وما ينجو منه كل ترتيب، ولماذا لا يُعدّ النسخ المتماثل نسخة احتياطية.

تُطلب قاعدة البيانات المُدارة بمعزل عن أي تطبيق، لأنها تعمّر أطول منه. ستعيد نشر التطبيق مئة مرة مقابل قاعدة البيانات نفسها.

تنشئها المنصّة، وتُبقيها تعمل، وتحدّثها، وتسلّمك بيانات الاعتماد مرة واحدة. أمّا ما بداخلها فهو ملكك.

اختيار الترتيب

ثلاثة ترتيبات، يضيف كل منها قدرة واحدة بالضبط على الذي قبله.

نسخة واحدة. نسخة واحدة فقط. أرخص ما يظلّ قاعدة بيانات. لا تحويل تلقائي عند العطل: إن تعطّل الجهاز الذي تعمل عليه، تصبح قاعدة البيانات غير قابلة للوصول حتى يعود. مناسبة للتطوير وبيئة staging، حيث الانقطاع إزعاج لا أكثر.

نسخة واحدة مع تجميع الاتصالات. النسخة الواحدة نفسها، وأمامها تجميع للاتصالات (connection pooling). تنجو من سيل من العملاء لكنها لا تنجو من فقدان جهازها. اخترها حين يفتح تطبيقك اتصالات كثيرة قصيرة العمر — وهذا ما تفعله معظم أطر عمل الويب — ولم تصل بعد إلى مرحلة الدفع مقابل التوافرية.

عالية التوافر. عدّة نسخ، إحداها الأساسية تقبل الكتابة بينما تتبعها البقية. إن تعطّلت الأساسية، تتولّى أخرى مكانها ويعيد تطبيقك الاتصال بالعنوان نفسه. هذا هو الترتيب الوحيد الذي ينجو من فقدان جهاز.

لماذا يكون عدد النسخ فرديًا

ثلاث أو خمس، لا اثنتان أو أربع أبدًا. تحديد النسخة المسؤولة يتطلّب اتّفاق أغلبية. والعدد الزوجي قد ينقسم نصفين فلا يتّفق على أحد — وهذا يجعل النسختين أقلّ توافرًا من نسخة واحدة، لأن تعطّل أيّ منهما لا يترك أغلبية، فتتوقّف قاعدة البيانات عن قبول الكتابة كي لا تُفسد نفسها.

الاتصال

تُعطى عنوانًا واحدًا. استخدمه ولا شيء غيره. يظلّ صحيحًا حين تنتقل النسخة الأساسية، وهذا هو المقصود كلّه: لا ينبغي لتطبيقك أن يعرف أبدًا أيّ نسخة هي المسؤولة، ولا أن يهتمّ بذلك.

تُعرض بيانات الاعتماد مرة واحدة، عند إنشاء قاعدة البيانات أو عند إضافة مستخدم. ولا يمكن استرجاعها بعد ذلك. إن أضعتها، فأنشئ بيانات اعتماد جديدة.

النسخ الاحتياطي ليس نسخًا متماثلًا

يستحقّ هذا عنوانًا خاصًا به لأنه أغلى سوء فهم في هذه الوثيقة.

النسخ المتماثل ينسخ كل عملية كتابة إلى كل نسخة، بأمانة وفورًا. وهذا يشمل الكتابة التي لم تقصدها. جدول محذوف، أو أمر DELETE بشرط خاطئ، أو ترحيل شُغّل على قاعدة البيانات الخطأ — كل ذلك يُنسخ على نحو مثالي إلى كل نسخة في غضون لحظات.

النسخ المتماثل يحميك من تعطّل العتاد. والنسخ الاحتياطية تحميك من خطأ البشر والبرمجيات. إنهما مشكلتان مختلفتان وتحتاجان إلى آليات مختلفة. وأنت تحتاج إلى الاثنتين.

النسخ الاحتياطي غير مفعّل افتراضيًا. فعّله، واختر الساعة، وتحقّق مرة واحدة من أن الاستعادة تعمل قبل أن تحتاج إليها.

حالات حدّية يحسن معرفتها قبل أن تصادفها

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

تُرفض الاتصالات تحت الضغط. تقبل قاعدة البيانات عددًا ثابتًا من الاتصالات. والتطبيق ذو النسخ الكثيرة، التي تفتح كل منها مجمّع اتصالاتها الخاص، سيستنفدها قبل أن تنشغل قاعدة البيانات فعلًا بوقت طويل. استخدم الترتيب المزوّد بتجميع الاتصالات، وخفّض حجم المجمّع في تطبيقك — فتطبيق الويب لا يحتاج تقريبًا أبدًا إلى القيمة الافتراضية التي يأتي بها إطار عمله.

حدث تحويل عند العطل ففشلت المعاملات الجارية. هذا صحيح. كل ما لم يُثبَّت حين تعطّلت النسخة الأساسية قد ضاع؛ والترقية لا تستطيع اختراع نتيجة معاملة لم يُكملها أحد. التطبيقات المهمّة ينبغي أن تعيد محاولة المعاملة الفاشلة بدل أن تفترض أنها نجحت.

حدث تحويل عند العطل وغابت عملية كتابة حديثة جدًا. تتبع النسخ النسخةَ الأساسية بتأخّر طفيف. إن تعطّلت الأساسية في تلك الفجوة، فقد لا تكون الكتابة التي أكّدتها قد وصلت إلى النسخة التي تولّت مكانها. الفجوة قصيرة لكنها ليست صفرًا. إن كان تطبيقك لا يحتمل ذلك إطلاقًا، فقل ذلك قبل الطلب — المقايضة كتابة أبطأ مقابل عدم الفقدان، ويجب اختيارها عن قصد.

نسخة متأخّرة كثيرًا. السبب عادةً استعلام طويل على تلك النسخة، أو دفعة من عمليات الكتابة أكبر ممّا يحتمله الرابط. تلحق بنفسها. والنسخة المتأخّرة أكثر من اللازم لا تُرقّى أثناء التحويل عند العطل، لأن ترقيتها ستُضيّع أكثر ممّا يُضيّعه البديل.

امتلأ القرص. يتوقّف كل شيء، بما في ذلك القدرة على حذف الصفوف — إذ يحتاج الحذف إلى الكتابة. راقب الحجم؛ ولا تنتظر امتلاءه.

حذفت قاعدة البيانات. لقد ذهبت، وذهب معها كل ما فيها. التأكيد مملّ عن قصد.

ماذا تقرأ بعد ذلك