لماذا الاستضافة الذاتية لـ PostgreSQL على خادم VPS
تفرض قواعد البيانات المُدارة (RDS وCloud SQL) رسوماً بحسب الجيجابايت المخزّن وبحسب IOPS وبحسب الاتصال، وغالباً ما تحدّ من الامتدادات المتاحة. بنشر PostgreSQL على خادم VPS خاص بك، تُفعّل pg_stat_statements وPostGIS وpgvector أو TimescaleDB دون قيود، وتختار إصدارك المحدّد (15 و16 و17) وتُبقي بيانات"ك في نطاق قضائي تتحكّم فيه. يوفّر خادم VPS بقرص SSD أزمنة كمون I/O منخفضة جداً، مثالية لأحمال العمل المعاملاتية لتطبيق في بيئة الإنتاج. تدفع اشتراكاً ثابتاً وقابلاً للتوقّع، وتقرّر وحدك استراتيجيتك في التماثل والتشفير والاحتفاظ بالنسخ الاحتياطية.
الفوائد الملموسة لـ PostgreSQL مستضاف ذاتياً
- تكلفة ثابتة وقابلة للتوقّع: لا فوترة بحسب الجيجابايت أو IOPS أو عدد الاتصالات النشطة.
- امتدادات حرّة:
pgvectorللذكاء الاصطناعي، وPostGISللبيانات الجغرافية المكانية، وTimescaleDBللسلاسل الزمنية. - تحكّم كامل في النسخ الاحتياطية:
pg_dumpمجدول، أوpg_basebackup، أو تماثل فيزيائي نحو خادم VPS ثانٍ. - ضبط دقيق لـ
postgresql.conf(shared_buffers وwork_mem وWAL) مستحيل لدى معظم العروض المُدارة. - سيادة البيانات: تبقى بيانات"ك على بنية تحتية تختارها أنت.
- وصول فعلي بصلاحيات المستخدم الأعلى (superuser) للتدقيق والتنمية والتحسين دون تذكرة دعم.
المتطلّبات العتادية والبرمجية
لنسخة PostgreSQL للتطوير أو لمشروع إنتاج صغير، جهّز خادم VPS بمعالجين افتراضيين (2 vCPU) و4 جيجابايت من الذاكرة و40 جيجابايت من قرص SSD بنوع NVMe: يحبّ PostgreSQL الذاكرة لتخزين صفحاته المؤقّت. أمّا لحمل أكثر كثافةً (عدّة مئات من الاتصالات أو مجموعات بيانات بعشرات الجيجابايتات)، فاستهدف 4 vCPU و8 جيجابايت من الذاكرة. أمّا من جهة البرمجيات: Ubuntu 22.04 أو 24.04 LTS، وDocker Engine وإضافة Docker Compose v2، واسم نطاق يشير إلى خادم VPS إذا كشفت الوصول عن بُعد، وجدار حماية ufw مُعدّ للسماح بمرور الحدّ الأدنى الصارم فقط. احجز أيضاً وحدة تخزين Docker مخصّصة لـ PGDATA لفصل البيانات عن الحاوية.
نشر PostgreSQL باستخدام Docker في بيئة الإنتاج
تجهيز خادم VPS وجدار الحماية
اتّصل عبر SSH، وحدّث النظام باستخدام
apt update && apt upgrade -y، وثبّت Docker عبرcurl -fsSL https://get.docker.com | sh. احظر المنفذ 5432 من الخارج باستخدامufw deny 5432: يجب ألّا تُكشف قاعدة البيانات مباشرةً للإنترنت أبداً.كتابة ملفّ docker-compose.yml
أنشئ خدمة
postgres:17، وركّب وحدة تخزين مُسمّاة على/var/lib/postgresql/data، وعرّفPOSTGRES_PASSWORDوPOSTGRES_DBوPOSTGRES_USERعبر ملفّ.envلا يُودَع (commit) أبداً. أضفshm_size: 256mbلعمليات الفرز الكبيرة وhealthcheckباستخدامpg_isready.تشغيل قاعدة البيانات وتهيئتها
ابدأ بـ
docker compose up -d، وتحقّق من السجلّات عبرdocker compose logs -f postgres، ثمّ اتّصل باستخدامdocker compose exec postgres psql -U app -d mabase. أنشئ أدوار التطبيقية بصلاحيات دنيا بدلاً من استخدام المستخدم الأعلى.كشف الوصول عبر نفق أو وكيل TLS
للوصول الآمن عن بُعد، لا تفتح المنفذ 5432 بنصّ صريح أبداً: استخدم نفق SSH (
ssh -L 5432:localhost:5432) أو ضعpgbouncerخلف وكيل عكسي. فعّل SSL من جهة PostgreSQL بشهادة Let's Encrypt مُركّبة في الحاوية (ssl = onفيpostgresql.conf).ضبط الإعدادات
اضبط
shared_buffersعند نحو 25% من الذاكرة، وeffective_cache_sizeعند 50-75%، وwork_memبحسب استعلاماتك. فعّلpg_stat_statementsلتحديد الاستعلامات البطيئة. استخدم أداة PGTune كنقطة انطلاق.أتمتة النسخ الاحتياطية
جدول
pg_dumpيومياً عبر مهمّة cron على المضيف، واضغط بتنسيق.dumpالمخصّص، وانسخ الأرشيفات إلى تخزين خارجي. اختبر الاستعادة بانتظام باستخدامpg_restore: النسخة الاحتياطية غير المختبرة غير موجودة.أول تسجيل دخول
لا يُنشر pgAdmin على الإنترنت: افتح نفقاً من جهازك بالأمر ssh -L 5050:127.0.0.1:5050 root@<IP> ثم انتقل إلى http://127.0.0.1:5050 وسجّل الدخول بالبريد [email protected] وكلمة المرور المزوّدة. بعد ذلك أضف خادمك عبر «Add New Server» مع المضيف db والمنفذ 5432 والمستخدم postgres وكلمة المرور نفسها.
ضبط postgresql.conf للإنتاج
work_mem وmax_connections
اضبط
work_memبناءً على استعلامات الفرز والضمّ: 4 إلى 16 ميجابايت معقول لأعباء العمل المختلطة. انتبه: يمكن لكل اتصال تخصيصwork_memعدة مرات في وقت واحد، لذا اضرب فيmax_connectionsلتقدير ذروة استهلاك الذاكرة. لـ 100 اتصال تطبيقي، يكفيmax_connections = 150؛ وما فوق ذلك استخدمpgbouncerفي وضع المعاملات لتوحيد الاتصالات.التسجيل واكتشاف الاستعلامات البطيئة
فعّل
logging_collector = onوlog_min_duration_statement = <seuil_ms>(ms) لتسجيل جميع الاستعلامات التي تتجاوز 200 مللي ثانية. يرفق ربط هذا الإعداد بـpg_stat_statements(امتداد يُفعَّل فيshared_preload_libraries) عرضاً مجمّعاً للاستعلامات الأكثر تكلفةً دون فحص كل ملفّ سجلّ.WAL ونقاط التفتيش
زد
wal_buffersإلى 16 ميجابايت واضبطcheckpoint_completion_targetعلى 0.9 لتوزيع كتابات نقاط التفتيش على مدار الوقت. على SSD بواجهة NVMe، يشجّعrandom_page_cost = 1.1(عوضاً عن الافتراضي 4.0) المخطّط على اختيار فحص الفهارس بدلاً من المسح التسلسلي.
النسخ الاحتياطية التلقائية واستراتيجية الاستعادة
النسخة الاحتياطية غير المختبرة غير موجودة. ثلاثة نُهُج تكميلية تغطّي احتياجات مختلفة.
pg_dump + cron هو نقطة البداية: سهل الإعداد، ينتج ملفاً منطقياً بصيغة SQL قابلاً للاستعادة على أي إصدار متوافق. جدوله في الساعة الثالثة صباحاً، اضغط باستخدام --format=custom، وانسخ الأرشيف إلى تخزين خارجي باستخدام rclone أو scp. احتفظ بـ 7 أيام محلياً و30 يوماً عن بُعد.
pgBackRest يذهب أبعد: يدعم النسخ الاحتياطية التزايدية والتفاضلية والاستعادة في الوقت المحدّد (PITR) من أرشيفات WAL. وهو الحلّ الموصى به متى تجاوزت قاعدة بياناتك بضعة جيجابايتات أو احتجت إلى الرجوع إلى دقيقة بعينها بعد حذف عرضي.
اختبار الاستعادة الشهري: نفّذ pg_restore -d test_restore <dump> بانتظام على خادم VPS اختباري للتحقّق من سلامة الأرشيفات.
التوافر العالي الخفيف بدون Kubernetes
لا يستلزم التوافر العالي لـ PostgreSQL على خادم VPS بالضرورة Patroni أو مجموعة Pacemaker معقّدة. تغطّي التماثل بالبثّ الأصلي معظم الاحتياجات بأدنى قدر من الإعداد.
التماثل بالبثّ اليدوي: على خادم VPS الأساسي، فعّل wal_level = replica، أضف مستخدماً مخصّصاً replicator في pg_hba.conf، واضبط max_wal_senders = 3. على خادم VPS الثانوي (standby)، شغّل pg_basebackup لتهيئة نسخة فيزيائية، أنشئ ملفّ standby.signal، وعدّل primary_conninfo في postgresql.conf. يبدأ التماثل تلقائياً عند إعادة التشغيل. مع hot_standby = on، يقبل الخادم الاحتياطي استعلامات القراءة فقط.
Patroni يضيف التحويل التلقائي للفشل: يراقب الخادم الأساسي عبر مفتاح في etcd أو Consul، ويرقّي الخادم الاحتياطي تلقائياً إذا أصبح الأساسي غير متاح لأكثر من 30 ثانية.
مراقبة تأخّر التماثل: SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS lag_bytes FROM pg_stat_replication على الخادم الأساسي يُعطيك التأخّر الفوري بالبايت.
PostgreSQL المستضاف ذاتياً مقابل RDS مقابل Supabase مقابل Neon
مرّر الجدول أفقيًا
| المعيار | VPS ServOrbit (مستضاف ذاتياً) | AWS RDS PostgreSQL | Supabase (سحابي) | Neon (بدون خادم) |
|---|---|---|---|---|
| التكلفة الشهرية (صغير) | 99 درهم/شهر (سعر ثابت) | ~35-70 $/شهر (db.t3.medium) | ~25 $/شهر (Pro) | ~19 $/شهر (Launch) |
| التحكّم في postgresql.conf | كامل | جزئي (مجموعات المعاملات) | محدود | الحدّ الأدنى |
| الامتدادات المخصّصة | الكلّ (pgvector وPostGIS…) | قائمة مقيّدة | pgvector وPostGIS | محدودة |
| PITR | نعم مع pgBackRest | نعم (أصلي) | نعم (Pro+) | نعم (أصلي) |
| التوافر العالي | تماثل يدوي أو Patroni | Multi-AZ أصلي | أصلي | متعدّد المناطق أصلي |
| عبء الصيانة | مرتفع (يتطلّب DBA) | منخفض | منخفض جداً | منخفض جداً |
| البيانات خارج الولايات المتحدة | نعم (VPS مغربي) | حسب المنطقة | حسب المنطقة | الولايات المتحدة/أوروبا فقط |
| Superuser / الامتدادات | نعم | لا | لا | لا |
استكشاف أخطاء الإنتاج الشائعة
قاتل OOM يوقف PostgreSQL: إشارة OOM في /var/log/syslog تعني نفاد الذاكرة. الأسباب الرئيسية: shared_buffers مرتفع جداً، أو work_mem مُعايَر بشكل سيئ مقارنةً بعدد الاتصالات. التشخيص: cat /proc/meminfo | grep -E 'MemFree|Cached|Buffers'. الحلّ: تقليل work_mem، تفعيل huge_pages = try في postgresql.conf، أو ترقية خادم VPS.
نفاد الاتصالات (FATAL: sorry, too many clients already): وُصل إلى max_connections. على المدى القصير: SELECT count(*), state FROM pg_stat_activity GROUP BY state لتحديد الاتصالات الخاملة. على المدى البعيد: انشر pgbouncer في وضع المعاملات أمام PostgreSQL.
تشبّع الـ autovacuum: الجداول التي تحتوي على عمليات UPDATE أو DELETE كثيرة تراكم صفوفاً ميتة. SELECT relname, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10 يكشف الجداول الإشكالية. سرّع autovacuum بتقليل autovacuum_vacuum_scale_factor إلى 0.01 للجداول الحرجة.
نقاط تفتيش متكرّرة جداً (LOG: checkpoint occurring too frequently): زد max_wal_size إلى 2-4 جيجابايت وcheckpoint_timeout إلى 15-30 دقيقة لتوزيع نقاط التفتيش.
لتحقيق التوافر العالي، انشر خادم VPS ثانياً في تماثل فيزيائي بالبثّ (primary_conninfo + فتحة تماثل). تحصل على نسخة احتياطية ساخنة (standby) جاهزة للتبديل، ويمكنك تحويل استعلامات القراءة الثقيلة إليها (hot_standby = on) لتخفيف العبء عن الخادم الأساسي. واختزنه مع pgBackRest لنسخ احتياطية تزايدية تفاضلية، تبلغ نقطة هدف الاستعادة (RPO) قدره بضع دقائق دون الاعتماد على خدمة مُدارة.
الوثائق الرسمية
للإعداد المتقدّم والخيارات الخاصة بالأداة وتغييرات الإصدار، ارجع إلى الوثائق الرسمية لـ PostgreSQL. يغطّي هذا الدليل النشر المباشر على خادم VPS من ServOrbit؛ وتبقى وثائق الناشر المرجع للضبط الدقيق.
