الوصول إلى قاعدة البيانات

أنا أحاول الوصول إلى قاعدة البيانات الخاصة بي عبر واجهة رسومية (Psequel).

لقد قمت بتحويل إعداد المنفذ من الحاوية الخاصة بي على النحو التالي:

app.yml:

expose:
  <التعاريف القياسية>
  - "15432:5432" # PostgreSQL

كما قمت بتغيير كلمة المرور الخاصة بي على النحو التالي:

./launcher enter app
su - postgres
psql
ALTER ROLE postgres WITH PASSWORD '<كلمة المرور الخاصة بك>';

ولا أستطيع الوصول إلى قاعدة البيانات. هل لديك أي اقتراحات؟

إذا كنت تحتاج فقط إلى لقطة ثابتة لقاعدة البيانات، فقم بتنزيل نسخة احتياطية من https://<الموقع>/admin/backups. يجب أن يكون الملف بصيغة *.tar.gz، وعند فك ضغطه سيصبح ملفًا بصيغة *.sql. قم بإنشاء قاعدة بيانات PostgreSQL على جهاز آخر، وقد يكون ذلك حتى حاسوبك المحمول، ثم استورد ملف *.sql.

الآن يجب أن تتمكن من الوصول إلى البيانات كما تشاء باستخدام أي أداة يمكنها الاتصال بقاعدة بيانات PostgreSQL.

أنا أستخدم الطريقة المذكورة أعلاه ولكنني أتعامل مع قاعدة بيانات Discourse في PostgreSQL عبر ODBC.

أتمنى أن يكون ذلك مفيدًا.

حسنًا، فكرة جيدة.
في الواقع، لقد اكتشفت الأمر. إنه يعمل على المنفذ 5432 أيضًا داخل الحاوية.
يجب أن يكون النص كالتالي:
expose:
<التعريفات القياسية>

  • “5432:5432” # PostgreSQL

شكرًا لك

مرحباً بالجميع،

أنا قادر على الوصول إلى قاعدة بيانات postgres الخاصة بي عبر pgadmin باستخدام الخطوات التالية:

  • قم بإزالة كود منفذ الكشف من ملف app.yml الخاص بك وأعد بناء التطبيق.
  • انتقل إلى بوابة إدارة الخادم الخاصة بك (مثل Digital Ocean، AWS، إلخ). قم بإنشاء قاعدة جدار ناري تفتح المنفذ 5432.
  • باستخدام علامة تبويب SSH في pgadmin: قم بتسجيل الدخول إلى الخادم الخاص بك باستخدام عنوان الخادم وبيانات الاعتماد.

أخبرني إذا كان هذا يعمل معك.

مع خالص التقدير،
كيمبرلي

@EricGT لم أفكر في ذلك قط! شكرا لك!! :slight_smile:

أهلاً!

أردت التحقق معك مرة أخرى من فضلك. عندما أقوم بتصدير ملف dump.sql إلى قاعدة بيانات postgresql، تنتهي بي الحال بجداول فارغة. ليس من الواضح لماذا. إليك الخطوات التي أتبعها بعد تنزيل ملف النسخ الاحتياطي:

  1. افتح pgAdmin
  2. أنشئ قاعدة بيانات جديدة
  3. افتح أداة الاستعلام
  4. استخدم ‘فتح’ في أداة الاستعلام وحدد ملف dump.sql
  5. نفّذ نص النسخ الاحتياطي

يقول إن كل شيء كان ناجحًا ولكن عندما أقوم بـ “عرض البيانات” في الجداول، تكون فارغة.

بالإضافة إلى ذلك، من المحتمل أن تكون كيفية إدارة المثيل هي السبب، ولكن يبدو أن جدول المستخدمين غير مدرج أيضًا، ولكني بحاجة إلى هذا الجدول لمعرفة من فعل ماذا.

هل فاتني أي شيء هنا؟ شكراً!

ما هو حجم الملف dump.sql؟ يجب أن يكون كبيرًا (بضعة ميغابايت على الأقل). هل يمكنك إلقاء نظرة داخل الملف؟ على سبيل المثال:

$ zgrep -i "CREATE TABLE public.users" dump.sql.gz
# يجب أن يكون الناتج
> CREATE TABLE public.users (

إذا لم ترَ هذا، فإن التفريغ يبدو خاطئًا.

أيضًا، إذا شاركت خطواتك حول كيفية تصدير التفريغ أو لصقت مخرجات وحدة التحكم الخاصة بك هنا، فيمكننا فهم مشكلتك بشكل أفضل.

شكراً جزيلاً! :slight_smile:

6.34 جيجابايت!

The image shows a line of SQL code on a terminal, attempting to use a file named "dump.sql" to express a CREATE TABLE statement. (Captioned by AI)

لتنزيل النسخة الاحتياطية، اتبعت الخطوات التي اقترحها @EricGT أعلاه:

بعد ذلك اتبعت هذه الخطوات:

ثم عندما أريد عرض البيانات، يظهر:

لقد أعدت هذا للتو للتحقق.

  1. باستخدام صفحة المسؤول https://<site>/admin/backup، طلبت تنزيلًا واتبعت الخطوات، كانت هناك عدة خطوات تضمنت التحقق عبر البريد الإلكتروني وتنزيل ملف.
  2. الملف الذي تم تنزيله كان ملف gz على سبيل المثال abc-2025-01-23-095947-v20250122131007.sql.gz. على نظام ويندوز، قمت بفك ضغط الملف باستخدام 7-zip والذي أنشأ مجلدًا بنفس الاسم مع إزالة .gz من النهاية.
C:\Users\Groot\Downloads>dir *.sql.gz
23/01/2025  05:04 صباحًا       407,213,170 abc-2025-01-23-095947-v20250122131007.sql.gz

C:\Users\Groot\Downloads>dir *.sql

23/01/2025  05:04 صباحًا    <DIR>          abc-2025-01-23-095947-v20250122131007.sql
  1. باستخدام موجه أوامر ويندوز مفتوحًا على المجلد الذي يحتوي على ملف sql للتحقق من وجود ملف sql
C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>dir

23/01/2025  05:04 صباحًا     1,572,346,154 abc-2025-01-23-095947-v20250122131007.sql
               1 File(s)  1,572,346,154 bytes
  1. باستخدام نفس موجه أوامر ويندوز المستخدم لكتابة الأمر لسرد بداية ملف sql.

type <file> /a | more

C:\Users\Groot\Downloads\abc-2025-01-23-095947-v20250122131007.sql>type "abc-2025-01-23-095947-v20250122131007.sql" /a | more

abc-2025-01-23-095947-v20250122131007.sql


--
-- PostgreSQL database dump
--

-- Dumped from database version 15.8 (Debian 15.8-1.pgdg110+1)
-- Dumped by pg_dump version 15.10 (Debian 15.10-1.pgdg120+1)

-- Started on 2025-01-23 09:59:47 UTC

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';

نأمل أن يوصلك هذا إلى النقطة التي يمكنك فيها استخدام ملف SQL مع PGAdmin لاستيراد البيانات.


ملاحظة:
عندما قمت بنشر حول هذا الأمر قبل حوالي 5 سنوات، كان نوع ملف التنزيل هو tar.gz، وهو الآن sql.gz. الفرق الوحيد هو أنه الآن يلزم خطوة فك ضغط أقل.

مرحباً @EricGT

شكراً جزيلاً على مساعدتك! لقد اتبعت نفس الخطوات (مع خطوة إضافية بما أن ملفي لا يزال يحتوي على tar.gz). لقد وصلت إلى نفس النتيجة مع ملف sql:

--
-- PostgreSQL database dump
--
.........
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';

ومع ذلك، فإن المشكلة هي أنه عندما أستخدم PgAdmin للحصول على البيانات، تكون جميع الجداول فارغة ويفتقد جدول المستخدمين.

عذرًا، لا يمكنني المساعدة بخصوص PgAdmin. أنا لا أستخدم PgAdmin وسيتعين علي تثبيته للتجربة. تثبيت PgAdmin ليس خطوة أهتم بها.

في المرة الوحيدة التي وصلت فيها إلى قاعدة بيانات Discourse مُصدّرة، كان ذلك لتثبيت PostgreSQL و odbc-postgresql واستخدام iusql كما هو مذكور هنا.

شكراً جزيلاً على كل مساعدتكم! أقدر ذلك حقًا. اتضح أنني كنت أحاول استخدام أحدث إصدار من postgresql بينما كان dump.sql من إصدار سابق. اكتشفت ذلك أثناء محاولة اتباع الدليل الذي استخدمته. شكرًا لك!