استعادة النقطة الزمنية (PITR) في PostgreSQL

استرجاع النقطة الزمنية (PITR) هو ميزة قوية في PostgreSQL التي أصبحت أكثر كفاءة وسهولة في الاستخدام مع ظهور PostgreSQL. تتيح للمسؤولين استعادة قاعدة بيانات PostgreSQL إلى لحظة معينة في الماضي. هذه الميزة مفيدة بشكل خاص إذا كنت تدير استعادة الكوارث لنظام كبير الحجم مع حمولة معاملات كبيرة.

ستستكشف هذه المدونة PITR وتزودك بالمعرفة حول المخاطر المحتملة وحلولها، مما يضمن تنفيذًا سلسًا وناجحًا. سنشارك أيضًا فوائدها الرئيسية ونفصل تنفيذًا خطوة بخطوة لـ PostgreSQL.

المكونات الرئيسية

يتضمن تنفيذ PITR مكونين رئيسيين:

1. النسخة الاحتياطية الأساسية

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

2. سجلات الكتابة المسبقة (WAL)

تسجل ملفات WAL كل تغيير يتم إجراؤه على قاعدة البيانات. تخزن هذه السجلات التغييرات المطلوبة لاستعادة قاعدة البيانات إلى حالتها في وقت معين. عند تنفيذ PITR، تقوم بإعادة تشغيل ملفات WAL بشكل متسلسل لإعادة إنشاء حالة قاعدة البيانات المطلوبة.

لماذا تستخدم PITR؟

PITR مفيدة في عدة سيناريوهات:

التراجع عن التغييرات غير المقصودة

يمكن أن تؤدي العمليات غير المقصودة، مثل جملة DELETE أو DROP بدون جملة WHERE، إلى فقدان كبير للبيانات. مع استعادة البيانات من نقطة زمنية (PITR)، يمكنك استعادة قاعدة البيانات إلى حالة كانت قبل الخطأ، مما يحافظ على البيانات الحيوية.

استعادة من تلف البيانات

يمكن أن تتسبب أخطاء التطبيقات، أو أعطال الأجهزة، أو تلف القرص في عدم تناسق البيانات. يسمح لك PITR باستعادة لقطة نظيفة من قاعدة البيانات وإعادة تشغيل التغييرات الصحيحة فقط، مما يقلل من وقت التوقف وفقدان البيانات.

استعادة للاختبار أو التصحيح

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

استعادة الكوارث

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

الاستخدام الفعال للموارد

من خلال دمج النسخ الاحتياطية الأساسية الدورية مع ملفات WAL، يقلل PITR من الحاجة إلى النسخ الاحتياطية الكاملة المتكررة، مما يوفر مساحة التخزين ويقلل من أوقات النسخ الاحتياطي. كما أن PITR هو طريقة استرداد دقيقة، مما يسمح لك بالاسترداد إلى ثانية معينة ويقلل من خطر فقدان البيانات أثناء الحادث. وهو مرن بما يكفي للتعامل مع سيناريوهات استرداد متنوعة، من التراجع عن معاملة واحدة إلى استعادة قاعدة بيانات كاملة بكفاءة.

ما الجديد في PostgreSQL 17 لـ PITR؟

يقدم PostgreSQL 17 العديد من التحسينات لـ PITR، مع التركيز على الأداء وسهولة الاستخدام والتوافق:

تزامن فتحة الفشل

تدعم الآن فتحات النسخ المتماثل المنطقية التزامن أثناء حالات الفشل. وهذا يضمن الاحتفاظ بـ WALs المطلوبة لـ PITR حتى بعد حدوث فشل، مما يقلل من التدخل اليدوي.

تحسين ضغط WAL

تم تحديث خوارزمية ضغط WAL لتحسين كفاءة التخزين، مما يقلل من المساحة المطلوبة لأرشفة WALs. هذا مفيد بشكل خاص للأنظمة الكبيرة ذات معدلات المعاملات العالية.

سرعات استرداد أسرع

تحسينات في عملية إعادة تشغيل WAL تؤدي إلى أوقات استرداد أسرع، خاصةً لمجموعات البيانات الكبيرة.

تحسين التوافق مع النسخ المتماثل المنطقي

الآن يتكامل PITR بشكل أفضل مع إعدادات النسخ المتماثل المنطقي، مما يسهل استرداد الكتل التي تستخدم النسخ المتماثل الفيزيائي والمنطقي.

تحكم دقيق في أرشفة WAL

يقدم PostgreSQL 17 المزيد من التحكم في أرشفة WAL، مما يسمح لك بضبط سياسات الاحتفاظ لتتناسب مع متطلبات الاسترداد.

خطوات مفصلة لتنفيذ PITR في PostgreSQL

اتبع هذه الخطوات لإعداد وتنفيذ PITR. قبل استخدام PITR، ستحتاج إلى:

  • أرشفة WAL: قم بتمكين وتكوين أرشفة WAL.
  • نسخة احتياطية أساسية: قم بأخذ نسخة احتياطية كاملة باستخدام pg_basebackup أو pgBackRest.
  • تخزين آمن: تأكد من تخزين النسخ الاحتياطية وملفات WAL بشكل آمن، ويفضل أن يكون ذلك في موقع خارجي.

1. تكوين أرشفة WAL

تعتبر أرشفة WAL ضرورية لـ PITR لأنها تخزن التغييرات التدريجية بين النسخ الاحتياطية. لتكوين أرشفة WAL، قم بتحديث ملف postgresql.conf، واضبط:

Shell

 

ثم، بعد ضبط معلمات التكوين، أعد تشغيل خادم PostgreSQL:

Shell

 

تحقق من حالة أرشفة WAL باستخدام الأمر التالي:

SQL

 

ابحث عن أي أخطاء في عرض pg_stat_archiver أو سجلات PostgreSQL.

2. قم بأخذ نسخة احتياطية أساسية

قم بأخذ نسخة احتياطية أساسية لاستخدامها كنقطة انطلاق لـ PITR؛ باستخدام pg_basebackup، الأمر يكون على الشكل التالي:

Shell

 

هذا ينشئ لقطة قاعدة بيانات متسقة ويضمن أرشفة ملفات WAL لاستعادتها.

3. تحقق من سلامة النسخة الاحتياطية

استخدم pg_verifybackup للتحقق من سلامة النسخة الاحتياطية الخاصة بك:

Shell

 

4. محاكاة فشل

لأغراض العرض، يمكنك محاكاة فشل. على سبيل المثال، احذف البيانات عن طريق الخطأ:

Shell

 

5. استعادة النسخة الاحتياطية الأساسية

قبل استعادة النسخة الاحتياطية الأساسية، أوقف خادم PostgreSQL:

Shell

 

ثم، استخدم الأمر التالي لتغيير اسم دليل البيانات الحالي:

Shell

 

ثم، استبدل دليل البيانات بالنسخة الاحتياطية الأساسية:

Shell

 

قم بتحديث الأذونات على دليل البيانات:

Shell

 

6. تكوين الاستعادة

لتمكين وضع الاستعادة، تحتاج أولاً إلى إنشاء ملف recovery.signal في دليل بيانات PostgreSQL:

Shell

 

ثم، قم بتحديث postgresql.conf، بإضافة المعلمات التالية:

Shell

 

7. بدء PostgreSQL في وضع الاستعادة

أعد تشغيل خادم PostgreSQL باستخدام الأمر:

Shell

 

راقب السجلات لتقدم الاستعادة:

Shell

 

سيخرج PostgreSQL تلقائيًا من وضع الاسترداد ويصبح قابلاً للتشغيل عندما يكتمل الاسترداد.

8. تحقق من الاسترداد

بعد الاسترداد، تحقق من حالة قاعدة البيانات:

SQL

 

معالجة المشكلات المحتملة

ملفات WAL المفقودة أو التالفة

المشكلة

ملفات WAL المطلوبة للاسترداد مفقودة أو تالفة.

الحل

  • تأكد من التحقق من النسخ الاحتياطية وأرشيفات WAL بانتظام باستخدام أدوات مثل pg_verifybackup.
  • استخدم تخزينًا احتياطيًا لأرشيفات WAL.

هدف استرداد غير صحيح

المشكلة

يتوقف الاسترداد عند حالة غير مقصودة.

الحل

  • تحقق مرتين من recovery_target_time، recovery_target_lsn، أو recovery_target_name.
  • استخدم pg_waldump لفحص ملفات WAL لأحداث الهدف.

اختناقات الأداء أثناء الاسترداد

المشكلة

يستغرق الاسترداد وقتًا طويلاً بسبب ملفات WAL الكبيرة.

الحل

  • قم بتحسين أداء الاسترداد عن طريق زيادة maintenance_work_mem و max_parallel_workers.
  • استخدم ضغط WAL لتقليل حجم الملف.

مشكلات انحراف الساعة

المشكلة

تحتاج طوابع الاسترداد الزمنية إلى أن تتماشى بسبب اختلافات الساعة.

الحل

قم بمزامنة ساعات الخادم باستخدام أدوات مثل NTP.

أرشفة WAL غير المكونة بشكل صحيح

المشكلة

تسبب archive_command غير الصحيح في فشل أرشفة WAL.

الحل

  • اختبر archive_command يدويًا: cp /path/to/test_wal /path/to/wal_archive/.
  • تأكد من وجود أذونات كافية لدليل الأرشيف.

أفضل الممارسات لـ PITR

  1. أتمتة النسخ الاحتياطية: استخدم أدوات مثل pgBackRest أو Barman للنسخ الاحتياطي المجدول وأرشفة WAL.
  2. مراقبة أرشفة WAL: تحقق بانتظام من pg_stat_archiver لرصد المشاكل.
  3. التحقق من النسخ الاحتياطية: تحقق دائمًا من سلامة النسخ الاحتياطية باستخدام pg_verifybackup.
  4. اختبار إجراءات الاسترداد: قم بمحاكاة سيناريوهات الاسترداد بانتظام لضمان الجاهزية.
  5. تأمين أرشيفات WAL: بالنسبة لأرشيفات WAL، استخدم تخزينًا آمنًا ومتكررًا، مثل خدمات السحابة أو الأقراص المهيأة بنظام RAID.

الخاتمة

الاسترداد في الوقت المحدد (PITR) أمر حاسم للحفاظ على موثوقية قاعدة البيانات والتخفيف من فقدان البيانات في حالة وقوع حادث. تعمل تحسينات pgEdge و PostgreSQL 17 على جعل PITR أسرع وأكثر كفاءة وأسهل في الإدارة، خاصةً للأنظمة ذات النطاق الكبير أو العالي التوفر.

سيساعدك اتباع خطوات هذا الدليل وأفضل الممارسات في تنفيذ وإدارة PITR بشكل فعال في بيئات PostgreSQL الخاصة بك. إن الاختبار والمراقبة المنتظمة أمران ضروريان لضمان توفر عمليات الاسترداد عندما تحتاج إليها أكثر.

Source:
https://dzone.com/articles/point-in-time-recovery-pitr-in-postgresql