استرجاع النقطة الزمنية (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، واضبط:
wal_level = replica # Ensures sufficient logging for recovery
archive_mode = on # Enables WAL archiving
archive_command = 'cp %p /path/to/wal_archive/%f' # Command to archive WALs
max_wal_senders = 3 # Allows replication and archiving
ثم، بعد ضبط معلمات التكوين، أعد تشغيل خادم PostgreSQL:
sudo systemctl restart postgresql
تحقق من حالة أرشفة WAL باستخدام الأمر التالي:
SELECT * FROM pg_stat_archiver;
ابحث عن أي أخطاء في عرض pg_stat_archiver
أو سجلات PostgreSQL.
2. قم بأخذ نسخة احتياطية أساسية
قم بأخذ نسخة احتياطية أساسية لاستخدامها كنقطة انطلاق لـ PITR؛ باستخدام pg_basebackup، الأمر يكون على الشكل التالي:
pg_basebackup -D /path/to/backup_directory -Fp -Xs -P
هذا ينشئ لقطة قاعدة بيانات متسقة ويضمن أرشفة ملفات WAL لاستعادتها.
3. تحقق من سلامة النسخة الاحتياطية
استخدم pg_verifybackup
للتحقق من سلامة النسخة الاحتياطية الخاصة بك:
pg_verifybackup /path/to/backup_directory
4. محاكاة فشل
لأغراض العرض، يمكنك محاكاة فشل. على سبيل المثال، احذف البيانات عن طريق الخطأ:
DELETE FROM critical_table WHERE id = 123;
5. استعادة النسخة الاحتياطية الأساسية
قبل استعادة النسخة الاحتياطية الأساسية، أوقف خادم PostgreSQL:
sudo systemctl stop postgresql
ثم، استخدم الأمر التالي لتغيير اسم دليل البيانات الحالي:
mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old
ثم، استبدل دليل البيانات بالنسخة الاحتياطية الأساسية:
cp -r /path/to/backup_directory /var/lib/pgsql/17/data
قم بتحديث الأذونات على دليل البيانات:
chown -R postgres:postgres /var/lib/pgsql/17/data
6. تكوين الاستعادة
لتمكين وضع الاستعادة، تحتاج أولاً إلى إنشاء ملف recovery.signal
في دليل بيانات PostgreSQL:
touch /var/lib/pgsql/17/data/recovery.signal
ثم، قم بتحديث postgresql.conf، بإضافة المعلمات التالية:
restore_command = 'cp /path/to/wal_archive/%f "%p"' # Restore archived WALs
recovery_target_time = '2024-11-19 12:00:00' # Specify target time
Alternatively, use recovery_target_lsn or recovery_target_name for more advanced scenarios.
7. بدء PostgreSQL في وضع الاستعادة
أعد تشغيل خادم PostgreSQL باستخدام الأمر:
sudo systemctl start postgresql
راقب السجلات لتقدم الاستعادة:
tail -f /var/lib/pgsql/17/pg_log/postgresql.log
سيخرج PostgreSQL تلقائيًا من وضع الاسترداد ويصبح قابلاً للتشغيل عندما يكتمل الاسترداد.
8. تحقق من الاسترداد
بعد الاسترداد، تحقق من حالة قاعدة البيانات:
SELECT * FROM critical_table WHERE id = 123;
معالجة المشكلات المحتملة
ملفات 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
- أتمتة النسخ الاحتياطية: استخدم أدوات مثل pgBackRest أو Barman للنسخ الاحتياطي المجدول وأرشفة WAL.
- مراقبة أرشفة WAL: تحقق بانتظام من
pg_stat_archiver
لرصد المشاكل. - التحقق من النسخ الاحتياطية: تحقق دائمًا من سلامة النسخ الاحتياطية باستخدام
pg_verifybackup
. - اختبار إجراءات الاسترداد: قم بمحاكاة سيناريوهات الاسترداد بانتظام لضمان الجاهزية.
- تأمين أرشيفات WAL: بالنسبة لأرشيفات WAL، استخدم تخزينًا آمنًا ومتكررًا، مثل خدمات السحابة أو الأقراص المهيأة بنظام RAID.
الخاتمة
الاسترداد في الوقت المحدد (PITR) أمر حاسم للحفاظ على موثوقية قاعدة البيانات والتخفيف من فقدان البيانات في حالة وقوع حادث. تعمل تحسينات pgEdge و PostgreSQL 17 على جعل PITR أسرع وأكثر كفاءة وأسهل في الإدارة، خاصةً للأنظمة ذات النطاق الكبير أو العالي التوفر.
سيساعدك اتباع خطوات هذا الدليل وأفضل الممارسات في تنفيذ وإدارة PITR بشكل فعال في بيئات PostgreSQL الخاصة بك. إن الاختبار والمراقبة المنتظمة أمران ضروريان لضمان توفر عمليات الاسترداد عندما تحتاج إليها أكثر.
Source:
https://dzone.com/articles/point-in-time-recovery-pitr-in-postgresql