PostgreSQL 18.7 منتشر شد؛ راهنمای به‌روزرسانی امن نسخه‌های پایدار

PostgreSQL چیست و چرا به‌روزرسانی آن مهم است؟

PostgreSQL یک سامانهٔ مدیریت پایگاه‌دادهٔ رابطه‌ای متن‌باز است که برای نگهداری داده‌های تراکنشی، اجرای کوئری‌های پیچیده و ساخت سرویس‌های وب و سازمانی استفاده می‌شود. بسیاری از وب‌سایت‌ها، APIها و سامانه‌های داخلی به‌صورت مستقیم یا از طریق ابزارهایی مانند ORM به PostgreSQL متصل هستند؛ بنابراین نگهداری نسخهٔ پایگاه‌داده فقط یک کار فنی داخلی نیست و می‌تواند روی پایداری، امنیت و صحت داده اثر بگذارد.

نسخه‌های جدید PostgreSQL چه هستند؟

برای شاخهٔ ۱۸، PostgreSQL ۱۸.۷ جدیدترین minor اعلام‌شده است و باید در برنامهٔ نگهداری پایگاه‌دادهٔ تیم ثبت شود.

گروه توسعهٔ جهانی PostgreSQL در ۱۲ نوامبر ۲۰۲۶ نسخه‌های minor جدید شاخه‌های پشتیبانی‌شده را اعلام کرد: PostgreSQL ۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ و ۱۴.۲۵. هم‌زمان، نسخهٔ Release Candidate ۲ از PostgreSQL ۱۹ نیز منتشر شده است؛ بنابراین PostgreSQL ۱۹ هنوز یک انتشار نهایی پایدار نیست و نباید با نسخه‌های minor پایدار اشتباه گرفته شود.

انتشارهای minor معمولاً برای رفع باگ‌های پرتکرار، مشکلات امنیتی، خطاهای کم‌ریسک و مواردی که ممکن است به خرابی داده منجر شوند ارائه می‌شوند. به همین دلیل، پروژه توصیه می‌کند هر سامانه از جدیدترین نسخهٔ minor شاخهٔ اصلی خود استفاده کند. فهرست رسمی فعلی نشان می‌دهد شاخهٔ ۱۸ تا نوامبر ۲۰۳۰، شاخهٔ ۱۷ تا نوامبر ۲۰۲۹، شاخهٔ ۱۶ تا نوامبر ۲۰۲۸ و شاخهٔ ۱۵ تا نوامبر ۲۰۲۷ پشتیبانی می‌شوند. PostgreSQL ۱۴.۲۵ آخرین minor در پایان دورهٔ پنج‌سالهٔ پشتیبانی این شاخه است و مدیرانی که هنوز از PostgreSQL ۱۴ استفاده می‌کنند باید برنامهٔ مهاجرت به شاخهٔ جدیدتر را جدی بگیرند.

منبع رسمی، جزئیات اصلاحیه‌های هر نسخه را در release notes جداگانه ارائه می‌کند. پیش از اجرای به‌روزرسانی، release notes همان شاخه، وابستگی‌های سیستم‌عامل و وضعیت ابزارهای پشتیبان‌گیری و مانیتورینگ را بررسی کنید. برای مطالعهٔ سیاست نسخه‌بندی و جدول پشتیبانی، به صفحهٔ رسمی Versioning Policy در PostgreSQL مراجعه کنید.

تفاوت ارتقای minor و major

ارتقای minor مانند رفتن از PostgreSQL ۱۸.۶ به ۱۸.۷ با ارتقای major مانند رفتن از PostgreSQL ۱۷ به ۱۸ یکسان نیست. در ارتقای minor، ساختار کلی data directory حفظ می‌شود و مسیر معمول شامل توقف سرویس، نصب باینری‌های جدید و راه‌اندازی دوبارهٔ PostgreSQL است. بااین‌حال، این فرایند را بدون خواندن release notes و بررسی وضعیت replication اجرا نکنید؛ بعضی محیط‌ها به تغییر در زمان‌بندی restart یا کنترل سرویس نیاز دارند.

ارتقای major تغییرات پیچیده‌تری در ساختار داخلی ایجاد می‌کند. برای چنین ارتقایی باید از dump و restore یا ابزار pg_upgrade استفاده شود. امکان عبور مستقیم از یک major به major بعدی وجود دارد، اما تیم PostgreSQL توصیه می‌کند release notes همهٔ نسخه‌های میانی خوانده شوند تا تغییرات SQL، تنظیمات، افزونه‌ها و رفتار planner غافلگیرکننده نباشد. در راه‌اندازی‌های وب، بررسی تجربهٔ کاربر پس از ارتقا نیز مهم است؛ برای نمونه، تغییرات رابط کاربری را می‌توان با روش‌هایی مانند View Transition API در سایت‌های چندصفحه‌ای جداگانه ارزیابی کرد.

چک‌لیست به‌روزرسانی PostgreSQL در production

۱. نسخهٔ فعلی هر سرور، replica و محیط staging را ثبت کنید و مشخص کنید هر سرویس به کدام شاخهٔ major وابسته است. اگر سامانه روی شاخهٔ ۱۸ قرار دارد، مقصد معمول این بررسی PostgreSQL ۱۸.۷ خواهد بود.

۲. release notes نسخهٔ هدف را بخوانید و افزونه‌ها، درایورها، poolerها، ابزارهای backup و سیستم مانیتورینگ را با آن تطبیق دهید.

۳. از backup معتبر و قابل‌بازگردانی اطمینان بگیرید. فقط موفقیت ساخت فایل backup کافی نیست؛ یک restore آزمایشی یا دست‌کم بررسی صحت آرشیو را انجام دهید.

۴. در staging، نصب باینری جدید، restart سرویس، اتصال برنامه، migrationها، jobهای زمان‌بندی‌شده و queryهای پرتکرار را آزمایش کنید.

۵. در محیط production، پنجرهٔ نگهداری تعیین کنید، replicaها و نقش primary را بررسی کنید و پیش از توقف سرویس، وضعیت replication lag و فضای دیسک را ثبت کنید.

۶. پس از راه‌اندازی، لاگ PostgreSQL، خطاهای اتصال، زمان پاسخ queryها، وضعیت replication و مصرف CPU، حافظه و دیسک را پایش کنید. در PostgreSQL ۱۸.۷ نیز مانند هر minor دیگر، rollback را فقط بر اساس دادهٔ واقعی و runbook آزمایش‌شده انجام دهید.

جمع‌بندی

به‌روزرسانی PostgreSQL ۱۸.۷ برای مدیرانی که روی شاخهٔ ۱۸ هستند، باید بخشی از برنامهٔ منظم نگهداری و وصله‌کردن باشد، نه اقدامی بدون آزمون.

PostgreSQL ۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ و ۱۴.۲۵ به‌روزرسانی‌های minor پایدار هستند و نصب نسخهٔ جدید شاخهٔ مورد استفاده معمولاً از ادامهٔ کار با یک minor قدیمی کم‌ریسک‌تر است. در مقابل، PostgreSQL ۱۹ RC ۲ هنوز برای ارزیابی و تست است و نباید بدون برنامهٔ مهاجرت و بررسی سازگاری وارد production شود. بهترین مسیر این است که ابتدا release notes و backup را کنترل کنید، سپس به‌روزرسانی minor را در staging تمرین کنید و بعد با پایش دقیق در پنجرهٔ نگهداری اجرا کنید.

برای تیم‌هایی که روی شاخهٔ ۱۸ هستند، PostgreSQL ۱۸.۷ نقطهٔ شروع مناسب بررسی این چرخهٔ نگهداری است؛ اما اجرای آن باید با backup قابل‌بازگردانی و تست staging همراه باشد.

منبع: PostgreSQL Global Development Group — Versioning Policy