إصدار رئيسي كل سنة، وخمس سنوات من الإصلاحات
يصدر PostgreSQL إصدارًا رئيسيًا مرة واحدة تقريبًا كل سنة ويصونه خمس سنوات. بعد ذلك يصدر إصدار فرعي أخير ويبلغ الفرع نهاية دعمه، دائمًا مع الإصدار الفرعي الصادر في نوفمبر: توقّف PostgreSQL 13 في 13 نوفمبر 2025، وسيتوقّف PostgreSQL 14 في 12 نوفمبر 2026. أمّا الفروع التي ما زالت مدعومة فتمتدّ من 14 إلى 18؛ ويتوفّر الإصدار 18 منذ 25 سبتمبر 2025، وأُعلن عن الإصدار 19 في سبتمبر 2026.
ما الذي تغيّره نهاية الدعم فعليًا
- لا مزيد من الإصلاحات — الثغرة التي تُنشر بعد نهاية الدعم لن تُصحَّح في فرعك: يبقى الكود كما هو إلى أجل غير مسمّى.
- الامتدادات تتخلّف — تتوقّف
PostGIS وpgvector وTimescaleDB عن نشر حزم لفرع ميت، فيصبح احتياجك التالي عائقًا. - حزم التوزيعة تختفي — لا تحديثات بعد اليوم عبر
apt، وإعادة تثبيت خادم VPS لا تستعيد بالضرورة الإصدار نفسه. - الامتثال يلاحظ ذلك — يرصد التدقيق أو استبيان العميل أو عقد التأمين مكوّنًا غير مصان قبل وقوع أي حادث بوقت طويل.
- العملاء وبرامج التشغيل تتقدّم — تفترض الأدوات الحديثة (
psql وpg_dump وبرامج تشغيل التطبيقات) إصدارات خادم مدعومة؛ وتنتهي الفجوة إلى أخطاء يصعب قراءتها.
كيف تعرف الإصدار الذي تعمل عليه فعلًا
الخادم هو المرجع، لا ملفّ النشر لديك. اتّصل ونفّذ SELECT version();، أو SHOW server_version; للقيمة المجرّدة. وعلى Debian وUbuntu، يسرد pg_lsclusters كل عنقود مع إصداره ومنفذه وحالته، بما في ذلك العناقيد المنسيّة من ترقية سابقة. وفي الحاويات يضلّل وسم الصورة: فاستبدال postgres:16 بوسم أحدث لا يحوّل الملفات المكتوبة سلفًا في وحدة التخزين.
تخطيط الترقية الكبرى
خذ نسخة احتياطية ثمّ تحقّق منها
صدّر الأدوار والإعدادات العامة باستخدام pg_dumpall --globals-only، ثمّ كل قاعدة بيانات باستخدام pg_dump -Fc. لا قيمة لنسخة احتياطية إلّا بعد استعادتها: أعد تشغيلها في عنقود قابل للإتلاف وقارن أعداد الصفوف في جداولك الرئيسية.
اختر بين التصدير المنطقي والتحويل في المكان
يعيد pg_dump متبوعًا بـ pg_restore بناء كل شيء في عنقود جديد: بسيط وقابل للتراجع، لكنّ زمن التوقّف يتبع حجم البيانات. أمّا pg_upgrade فيحوّل فهرس العنقود القائم في بضع دقائق، شريطة تثبيت ثنائيات الإصدارين جنبًا إلى جنب.
أعد تمثيل الترحيل على نسخة
لا تختبر على الآلة التي تخدم حركة المرور. جهّز خادم VPS ثانيًا، واستعد النسخة الاحتياطية عليه، ثمّ نفّذ pg_upgrade --check: فهو يتحقّق من التوافق دون كتابة أي شيء ويسرد التعديلات اليدوية المتوقّعة. وقِس زمن العملية: فهذا القياس يحدّد نافذتك.
نفّذ التبديل مع إيقاف عمليات الكتابة
أوقف التطبيق، ثمّ أطفئ الخادم بشكل سليم. شغّل التحويل أو الاستعادة، وأعد التشغيل على العنقود الجديد، وأعد حركة المرور بعد فحص أوّل. واختر الوضع عن دراية: يسرّع --link و--swap التبديل لكنّهما يجعلان العنقود القديم غير قابل للاستخدام.
افحص بعد التبديل
أكّد الإصدار بـ SELECT version();، وحدّث امتداداتك بـ ALTER EXTENSION ... UPDATE، ثمّ أعد توليد إحصاءات المحسّن بـ vacuumdb --all --analyze-in-stages. ولا تحذف دليل البيانات القديم إلّا بعد أيام عدّة من التشغيل الفعلي، مستعينًا بالسكربت الذي يشير إليه pg_upgrade.
استأنف دورة نسخ احتياطي كاملة
تصف أرشيفاتك السابقة للتبديل عنقودًا لم يعد موجودًا. خذ نسخة احتياطية كاملة على الإصدار الجديد واختبر استعادتها: يغطّي دليلنا حول النسخ الاحتياطية المشفّرة باستخدام restic التدوير وفحص السلامة. وعلى خادم VPS Cloud، يبقى هذا التقويم ملكك.
pg_dump/restore أم pg_upgrade: كيف تحسم الاختيار
| المعيار | pg_dump / pg_restore | pg_upgrade |
|---|---|---|
| المبدأ | تصدير منطقي ثمّ إعادة استيراد في عنقود جديد | تحويل فهرس العنقود القائم |
| زمن التوقّف | متناسب مع حجم البيانات | بضع دقائق، لا يتأثر كثيرًا بالحجم في وضع `--link` أو `--swap` |
| مساحة القرص | مساحة للأرشيف ثمّ للعنقودين معًا | لا ينسخ `--link` الملفات، لكنّه يفرض نظام الملفات نفسه |
| التراجع | يبقى العنقود القديم سليمًا ويبقى الأرشيف قابلًا لإعادة التشغيل | بعد `--link` أو `--swap`، لم يعد العنقود القديم قابلًا للتشغيل |
| الفحص المسبق | يظهر الفشل متأخّرًا أثناء الاستيراد | يتحقّق `pg_upgrade --check` قبل أي كتابة |
| إحصاءات المحسّن | يعاد بناؤها بالكامل بعد الاستيراد | تُنقل في معظمها منذ PostgreSQL 18، ويعاد بناؤها قبل ذلك |
| التوازي | `pg_dump -j` و`pg_restore -j` | `--jobs` لمعالجة عدّة قواعد بيانات على التوازي |
| الاستخدام النموذجي | الأحجام المتواضعة، تغيير الآلة، إعادة التنظيم | الأحجام الكبيرة، الترقية في المكان، النافذة القصيرة |
الفحص الحقيقي هو الاستعادة
لا يصدر الفرع المنتهي دعمه أي تنبيه، وكذلك النسخة الاحتياطية التي لم تُستعَد قط. قبل التبديل، اسرد الأرشيف بـ pg_restore --list، واستعده بالكامل على آلة منفصلة، وقارن أعداد الصفوف في جداولك الحسّاسة. ثمّ دوّن تاريخ نهاية دعم فرعك في التقويم الذي يحمل تجديداتك: موعد صامت يصير مهمّة مجدولة.
