آموزش نصب PostgreSQL روی اوبونتو

PostgreSQL یکی از قدرتمندترین و قابل‌اعتمادترین پایگاه‌های داده‌ی رابطه‌ای متن‌باز است و برای پروژه‌هایی که به یکپارچگی داده، تراکنش‌های پیچیده و انواع داده‌ی پیشرفته نیاز دارند انتخاب اول به شمار می‌رود. در این راهنما گام‌به‌گام نصب PostgreSQL روی اوبونتو را از مخزن رسمی PGDG انجام می‌دهیم تا به‌جای نسخه‌ی قدیمیِ مخزن پیش‌فرض سیستم، آخرین نسخه‌ی پایدار را داشته باشید.

چرا PostgreSQL را روی سرور خودتان نصب کنیم؟ کنترل کامل روی نسخه، پیکربندی و منابع؛ داده‌هایی که روی زیرساخت خودتان می‌مانند؛ و نبودِ هزینه‌های پلکانیِ سرویس‌های پایگاه‌داده‌ی مدیریت‌شده. با یک سرور ابری معمولی می‌توانید دیتابیسی راه بیندازید که هم برنامه‌های تولیدی را سرویس بدهد و هم زیر کنترل کامل شما باشد.

در این مقاله PostgreSQL نسخه ۱۸ را از مخزن رسمی روی Ubuntu 24.04 / 26.04 نصب می‌کنیم، یک کاربر و دیتابیس اختصاصی می‌سازیم، دسترسی امن از راه دور را با pg_hba.conf تنظیم می‌کنیم، فایروال را می‌بندیم و در پایان سراغ تیونینگ پایه و بک‌آپ می‌رویم.

پیش‌نیازها

• یک سرور ابری با Ubuntu 24.04 یا 26.04 و دسترسی root.
• برای شروع، ۱ هسته پردازنده و ۲ گیگابایت حافظه کافی است؛ اما کارایی PostgreSQL به‌شدت به حافظه وابسته است، پس برای بار تولیدی حافظه را بالاتر ببرید.
• اگر قرار است از یک سرور دیگر (سرور برنامه) به دیتابیس وصل شوید، آی‌پی آن سرور را آماده داشته باشید؛ در گام دسترسی از راه دور به آن نیاز داریم.

تمام دستورهای این راهنما با کاربر root اجرا می‌شوند.

گام ۱: افزودن مخزن رسمی PGDG

مخزن پیش‌فرض اوبونتو معمولاً نسخه‌ای قدیمی از PostgreSQL دارد. برای دریافت آخرین نسخه‌ی پایدار، از مخزن رسمی پروژه (PGDG) استفاده می‌کنیم. ابتدا بسته‌ی مدیریت مخزن را نصب می‌کنیم:

apt update
apt install -y postgresql-common

سپس اسکریپت رسمی افزودن مخزن را اجرا می‌کنیم:

/usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y

این اسکریپت کلید GPG مخزن را اضافه می‌کند و فایل مخزن مناسب نسخه‌ی اوبونتوی شما را (با تشخیص خودکار نام کد سیستم، مثل noble برای ۲۴.۰۴ یا resolute برای ۲۶.۰۴) می‌سازد. سوییچ -y باعث می‌شود بدون پرسش تعاملی اجرا شود. اگر بدون این اسکریپت مخزن را دستی اضافه می‌کردید، باید نام کد را خودتان درست انتخاب می‌کردید و یک اشتباه همان‌جا نصب را خراب می‌کرد.

گام ۲: نصب PostgreSQL

حالا فهرست بسته‌ها را به‌روز و نسخه‌ی مورد نظر را نصب می‌کنیم:

apt update
apt install -y postgresql-18

با نصب بسته، PostgreSQL به‌صورت خودکار یک کلاستر داده پیش‌فرض به نام main می‌سازد، سرویس آن را فعال می‌کند و راه می‌اندازد. برای اطمینان:

systemctl status postgresql --no-pager
sudo -u postgres psql -c "SELECT version();"

خط آخر با کاربر سیستمی postgres وارد پایگاه داده می‌شود و نسخه را چاپ می‌کند. اگر نسخه‌ی ۱۸ را دیدید، نصب درست انجام شده است.

گام ۳: ساخت کاربر و دیتابیس اختصاصی

استفاده از کاربر ابرمدیر postgres برای برنامه‌ها توصیه نمی‌شود. برای هر برنامه یک کاربر و دیتابیس جداگانه بسازید تا دسترسی‌ها محدود و ایزوله بمانند. وارد محیط psql می‌شویم:

sudo -u postgres psql

و داخل آن، کاربر و دیتابیس را می‌سازیم (رمز قوی بگذارید):

CREATE USER appuser WITH PASSWORD 'your-strong-password';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
\q

اینجا appuser مالک appdb می‌شود و کنترل کامل روی همان دیتابیس را دارد، اما به دیتابیس‌های دیگر یا تنظیمات کل سرور دسترسی ندارد. این جداسازی یعنی اگر اعتبارنامه‌ی یک برنامه لو برود، دامنه‌ی خسارت به همان دیتابیس محدود می‌ماند.

گام ۴: فعال‌سازی دسترسی از راه دور

به‌صورت پیش‌فرض PostgreSQL فقط به اتصال‌های محلی (localhost) گوش می‌دهد. اگر سرور برنامه و سرور دیتابیس یکی هستند، همین امن‌ترین حالت است و می‌توانید از این گام بگذرید. اما اگر می‌خواهید از یک سرور دیگر وصل شوید، باید دو فایل را ویرایش کنیم.

نخست فایل پیکربندی اصلی را باز می‌کنیم (به مسیر نسخه ۱۸ دقت کنید):

nano /etc/postgresql/18/main/postgresql.conf

خط listen_addresses را پیدا و آن را به آی‌پی داخلی سرور محدود می‌کنیم؛ از مقدار '*' که روی همه‌ی رابط‌ها گوش می‌دهد پرهیز کنید مگر اینکه واقعاً لازم باشد:

listen_addresses = 'localhost,10.0.0.5'

سپس فایل کنترل دسترسی را باز می‌کنیم:

nano /etc/postgresql/18/main/pg_hba.conf

و در انتهای آن یک قاعده اضافه می‌کنیم که فقط به appuser، فقط روی appdb و فقط از آی‌پی سرور برنامه اجازه‌ی اتصال بدهد:

host    appdb    appuser    203.0.113.10/32    scram-sha-256

معنای این خط مهم است:

• 203.0.113.10/32 یعنی فقط همین یک آی‌پی مجاز است. هرگز اینجا 0.0.0.0/0 نگذارید؛ آن یعنی هر کسی روی اینترنت می‌تواند تلاش کند وصل شود.
• scram-sha-256 روش احراز هویت مدرن و امن PostgreSQL است. از trust (که رمز نمی‌خواهد) و password (که رمز را ساده می‌فرستد) استفاده نکنید.

پس از ذخیره‌ی هر دو فایل، سرویس را بازخوانی می‌کنیم تا تغییرها اعمال شوند:

systemctl restart postgresql

ترکیب listen_addresses = '*' با یک قاعده‌ی باز در pg_hba.conf رایج‌ترین اشتباهی است که یک دیتابیس را روی کل اینترنت افشا می‌کند. همیشه هم دسترسی را به آی‌پی مشخص محدود کنید و هم در گام بعد فایروال را ببندید؛ این دو لایه مکمل یکدیگرند.

گام ۵: تنظیم فایروال

فایروال UFW را نصب می‌کنیم و پورت PostgreSQL (۵۴۳۲) را فقط برای آی‌پی سرور برنامه باز می‌کنیم، نه برای همه:

apt install -y ufw
ufw allow OpenSSH
ufw allow from 203.0.113.10 to any port 5432 proto tcp
ufw enable

قاعده‌ی from ... to any port 5432 یعنی تنها همان سرور برنامه می‌تواند به پورت دیتابیس برسد؛ برای بقیه‌ی دنیا این پورت بسته است. اگر دیتابیس و برنامه روی یک سرور هستند، اصلاً نیازی به باز کردن ۵۴۳۲ ندارید.

پیش از اجرای ufw enable مطمئن شوید قاعده‌ی OpenSSH را اضافه کرده‌اید، وگرنه ارتباط SSH فعلی شما قطع می‌شود. اگر این اتفاق افتاد، از کنسول تحت وب کنترل پنل ابر سپهر وارد سرور شوید و قاعده را اضافه کنید.

گام ۶: تیونینگ پایه برای کارایی بهتر

مقادیر پیش‌فرض PostgreSQL محافظه‌کارانه‌اند تا روی کوچک‌ترین سیستم‌ها هم اجرا شوند. با چند تنظیم ساده متناسب با حافظه‌ی سرور، کارایی را به‌طور محسوس بالا می‌بریم. این مقادیر را می‌توان با ALTER SYSTEM تعریف کرد که در فایل جداگانه‌ای ذخیره می‌شوند:

ALTER SYSTEM SET shared_buffers = '512MB';
ALTER SYSTEM SET effective_cache_size = '1536MB';
ALTER SYSTEM SET maintenance_work_mem = '128MB';
ALTER SYSTEM SET work_mem = '16MB';

نکته‌ها برای یک سرور با ۲ گیگابایت حافظه:

• shared_buffers حافظه‌ای است که PostgreSQL برای کش داده‌ها نگه می‌دارد؛ حدود ۲۵٪ کل RAM نقطه‌ی شروع خوبی است.
• effective_cache_size تخمینی از کل حافظه‌ی در دسترس برای کش (شامل کش سیستم‌عامل) است؛ حدود ۷۵٪ RAM. این مقدار حافظه مصرف نمی‌کند، فقط به بهینه‌ساز کوئری کمک می‌کند تصمیم بهتری بگیرد.
• work_mem حافظه‌ی هر عملیات مرتب‌سازی/هش است؛ آن را محتاطانه بالا ببرید، چون در هر کوئری چند بار می‌تواند مصرف شود.

برای اعمال این تغییرها، یک بار سرویس را ری‌استارت کنید:

systemctl restart postgresql

مقادیر بالا را متناسب با حافظه‌ی واقعی سرور تنظیم کنید. اگر بعداً منابع سرور را از کنترل پنل ابر سپهر ارتقا دادید، این اعداد را هم دوباره متناسب کنید.

گام ۷: آزمودن اتصال و فعال‌سازی افزونه‌ها

پیش از اینکه برنامه را به دیتابیس وصل کنید، از سرور برنامه اتصال را می‌آزماییم تا مطمئن شویم قواعد pg_hba.conf و فایروال درست کار می‌کنند. روی سرور برنامه کلاینت PostgreSQL را نصب و اتصال را تست کنید:

apt install -y postgresql-client
psql "postgresql://appuser:your-strong-password@203.0.113.5:5432/appdb" -c "\conninfo"

اگر پیام اتصال موفق را دیدید، مسیر از سرور برنامه تا دیتابیس کامل و امن است. اگر اتصال با تایم‌اوت رد شد، معمولاً فایروال یا listen_addresses را باید بازبینی کنید؛ و اگر خطای احراز هویت گرفتید، قاعده‌ی pg_hba.conf یا رمز کاربر را دوباره بررسی کنید.

بسیاری از برنامه‌ها به افزونه‌های PostgreSQL نیاز دارند؛ مثلاً uuid-ossp برای تولید شناسه‌های یکتا یا pg_trgm برای جست‌وجوی متنی سریع. افزونه را داخل همان دیتابیس فعال کنید:

sudo -u postgres psql -d appdb -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"

افزونه‌ها روی هر دیتابیس جداگانه فعال می‌شوند، پس اگر چند دیتابیس دارید باید این کار را برای هرکدام که نیاز دارد تکرار کنید.

نگهداری: به‌روزرسانی و بک‌آپ

به‌روزرسانی‌های جزئی (مثل ۱۸.۱ به ۱۸.۲) که فقط رفع اشکال و وصله‌ی امنیتی‌اند، از همان مسیر عادی سیستم می‌آیند و امن هستند:

apt update && apt upgrade -y

ارتقای نسخه‌ی اصلی (مثل ۱۸ به ۱۹) داستان جداگانه‌ای است و فرمت داده‌ها را تغییر می‌دهد. برای این کار نسخه‌ی جدید را نصب کنید و کلاستر را با ابزار رسمی مهاجرت دهید:

pg_upgradecluster 18 main

این ابزار داده‌ها را از کلاستر نسخه‌ی قبل به نسخه‌ی جدید منتقل می‌کند. پیش از اجرای آن حتماً بک‌آپ کامل بگیرید؛ ارتقای نسخه‌ی اصلی تنها تغییری است که اگر نیمه‌کاره بماند می‌تواند دیتابیس را در وضعیت ناسازگار رها کند.

بک‌آپ ستون فقرات هر دیتابیس تولیدی است. ساده‌ترین راه، گرفتن یک خروجی منطقی با pg_dump است که می‌توان آن را بازیابی یا منتقل کرد:

sudo -u postgres pg_dump appdb | gzip > /root/appdb-backup.sql.gz

برای بازیابی از همین فایل:

gunzip -c /root/appdb-backup.sql.gz | sudo -u postgres psql appdb

بهتر است این دستور را با یک کران‌جاب زمان‌بندی کنید تا بک‌آپ روزانه به‌صورت خودکار گرفته شود. در کنار آن، گرفتن اسنپ‌شات از کل سرور از کنترل پنل ابر سپهر پیش از هر تغییر پرخطر (مثل ارتقای نسخه‌ی اصلی) سریع‌ترین راه بازگشت به وضعیت سالم است.

جمع‌بندی

با این راهنما، نصب PostgreSQL روی اوبونتو از مخزن رسمی را انجام دادید، یک کاربر و دیتابیس ایزوله ساختید و دسترسی از راه دور را به‌صورت امن محدود کردید. سه تصمیمی که بیشترین تفاوت را در امنیت و پایداری می‌سازند: استفاده از scram-sha-256 به‌جای روش‌های ضعیف احراز هویت، محدودکردن دسترسی به آی‌پی مشخص در هر دو لایه‌ی pg_hba.conf و فایروال، و زمان‌بندی بک‌آپ منظم با pg_dump.

اگر می‌خواهید بدون درگیری با پیکربندی دستی، PostgreSQL و برنامه‌هایتان را با چند کلیک مدیریت کنید، می‌توانید آن را از داخل Coolify هم راه‌اندازی کنید. و اگر هنوز سروری برای دیتابیس‌تان ندارید، از صفحه خرید سرور ابری با منابع مناسب شروع کنید و هر زمان بار کاری بیشتر شد، حافظه و پردازنده را ارتقا دهید.