مشكلة غريبة في قاعدة بيانات Postgres مع تثبيت جديد

إليك واحدة لم أستطع حلها رغم العديد من عمليات تثبيت Discourse والهجرة الناجحة تمامًا.

الخلفية:

كان Discourse يعمل بشكل جيد داخل حاوية Docker وكنا نعمل على بعض الفروق الدقيقة في قاعدة بيانات PostgreSQL.

حدثت المشكلة عندما لم نكن راضين عن نتائج إعادة بناء المنشورات الخام (re-baking raw posts)، ولم يعد أي شيء يعمل كما هو مخطط له، لذا قررنا حذف قاعدة بيانات postgres وإعادة إنشائها؛ لكن التطبيق استمر في إظهار أخطاء صلاحيات مختلفة، إلخ.

ثم قررنا “الذهاب بقوة” وقررنا تدميرها بأسلوب “ما الذي يحدث”؛ وذهبنا ببساطة إلى postgres (مع علمنا بأن هذا لن ينتهي بشكل جيد، لكننا أردنا التجربة) وحذفنا جميع المواضيع و المنشورات من قاعدة البيانات (DELETE FROM topics; DELETE FROM posts;). هذا ساعد إلى حد ما؛ لكننا لم نكن راضين عن النتائج (انتهت التجربة)، لذا قررنا إعادة بناء Discourse من الصفر، مع نقل /var/discourse القديم بعيدًا، وسحب نسخة جديدة من git للبدء من جديد.

المشكلة

عندما قمنا بالبناء جديد تمامًا من سحب git، سار الأمر بسلاسة (عملية البناء) حتى الوصول إلى الجزء الذي نذهب فيه إلى الموقع لإنشاء تسجيل الدخول للمسؤول.

عندما ذهبنا إلى تسجيل الدخول للمسؤول لتثبيت جديد، كان الموقع القديم الذي دمرناه! كان هذا مفاجئًا.

لذا قررنا الدخول إلى هذا التطبيق الجديد ومحاولة حذف جميع جداول Discourse من قاعدة البيانات، وهو ما قمنا به؛ لكن، المفاجأة، عند إعادة بناء التطبيق مرة أخرى، لم يكن موقعًا جديدًا، بل نفس الموقع المعطل المذكور أعلاه.

لذلك، حذفنا جميع مجلدات /var/*discourse*؛ وأزلنا جميع صور Docker، ظانين أن هذا سيجعلها نظيفة تمامًا، وبدأنا من جديد بسحب git إلى /var/discourse مرة أخرى والبناء مما اعتقدنا أنه من الصفر تمامًا؛ لكن المفاجأة.. الموقع القديم لا يزال موجودًا.

متسائلين: “كيف يمكن أن يكون هذا”…؟

قمنا بتشغيل ps aux | grep postgres خارج حاوية Docker ولاحظنا أن postgres موجود خارج الحاوية (وهو أمر مفاجئ، حيث اعتقدنا خطأً أن تثبيت Discourse عبر Docker كان كله داخل حاوية Docker)؛ ثم حاولنا العثور على مكان للتنظيف، لكن دون جدوى.

بحثنا حتى تحولت روابط Google إلى اللون الأرجواني، وجربنا الكثير… لكننا لا نستطيع الحصول على تثبيت نظيف لـ Discourse.

ظانين أننا نغفل شيئًا، انتقلنا إلى خادم جديد، لم يتم تثبيت Discourse عليه من قبل، وقمنا بتثبيت Discourse من الصفر، وعمل بسلاسة كما هو معتاد (خادم آخر).

السؤال

سؤالي، أعتقد… عندما يخرج التثبيت تمامًا عن السيطرة (بأي طريقة كانت)، كيف يمكننا إعادة الخادم، بما في ذلك PostgreSQL، إلى نقطة الصفر حتى يختفي هذه المشكلة ونتمكن من الحصول على تثبيت جديد تمامًا؟

آسف على هذا المنشور الطويل، بينما قد يكون السؤال وحده كافيًا للحصول على المساعدة.

شكرًا لكم.

بدلاً من حذف الجداول أو إفراغها، قم ببساطة بحذف قاعدة البيانات.

شكرًا لك. سأجرب ذلك وأشارك النتائج لاحقًا.

حاولت حذف قاعدة البيانات، لكني ما زلت أحصل على خطأ الصلاحيات هذا:

/var/discourse# ./launcher enter neo
/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
اكتب "help" للمساعدة.
postgres=# drop database discourse;
ERROR: database "discourse" is being accessed by other users
DETAIL: There are 3 other sessions using the database.

هل لديك أي تلميحات؟

أقوى تخمين لي هو أنك لم تحذف حاوية Docker قيد التشغيل، لكنك تدّعي أنك حذفت الصور. ويبدو أنه كان يجب أن تحصل على مؤشر آخر.

أم أنك تستخدم PostgreSQL خارجيًا بدلاً من الموجود داخل الحاوية؟

عادةً ما يكون حذف /var/discourse/shared وإعادة البناء هو الحل.

شكرًا.

لقد أنهينا جميع جلسات قاعدة بيانات discourse السابقة، مما سمح لنا بحذف قاعدة بيانات discourse.

الآن نقوم مرة أخرى بخطوات ./launcher rebuild app. وسنقوم بنشر النتائج لاحقًا.

لم ينجح الأمر ./launch rebuild app؛ لذا إليك ما فعلناه بعد ذلك:

ثم:

Building app

WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
2.0.20200220-2221: Pulling from discourse/base
bc51dd8edc1b: Pulling fs layer
27ae5d171719: Pulling fs layer
bc51dd8edc1b: Download complete
bc51dd8edc1b: Pull complete
27ae5d171719: Verifying Checksum
27ae5d171719: Download complete
27ae5d171719: Pull complete
blah blah…
blah blah…
blah blah…


ما زال الأمر لا يعمل بعد إعادة البناء والإطلاق بدون أخطاء.

لذا، جربنا مرة أخرى مع تعطيل خيار LETSENCRYPT:

* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF

وما زال البناء يُنشئ النسخة السابقة المدمرة (من قبل ساعات) لأنه في تلك النسخة، قمنا بتثبيت عدد من السمات (themes)، وهي لا تزال موجودة في هذا البناء حتى بعد أن قمنا بـ ```إسقاط``` قاعدة بيانات ```discourse```:

Start compiling CSS: 2020-03-15 10:16:20 UTC
Compiling css for default 2020-03-15 10:16:20 UTC
precompile target: desktop Dark
precompile target: mobile Dark
precompile target: desktop_rtl Dark
precompile target: mobile_rtl Dark
precompile target: desktop_theme Dark
precompile target: mobile_theme Dark
precompile target: admin Dark
precompile target: desktop Light
precompile target: mobile Light
precompile target: desktop_rtl Light
precompile target: mobile_rtl Light
precompile target: desktop_theme Light
precompile target: mobile_theme Light
precompile target: admin Light
precompile target: desktop
precompile target: mobile
precompile target: desktop_rtl
precompile target: mobile_rtl
precompile target: desktop_theme
precompile target: mobile_theme
precompile target: admin
Done compiling CSS: 2020-03-15 10:16:27 UTC


كيف يمكن أن يكون ذلك ممكنًا بعد إسقاط قاعدة بيانات ```discourse``` بالكامل، وحذف جميع صور Docker وحاوياتها، وحذف ```rm -rf /var/discourse```، وإعادة البناء من الصفر؛ وما زلنا نرى جميع السمات المثبتة من البناء القديم الذي حاولنا تدميره بالكامل منذ ساعات؟

هذا لا معنى له في تثبيت جديد.

حسنًا، بدأنا من جديد وقمنا بتعليق قوالب LETSENCRYPT وخيار البريد الإلكتروني، وتمكنا من إعادة البناء بشكل صحيح والحصول على صفحة تسجيل دخول مشرف الاحتفال.

تقدّم!

الآن سنقوم بتحرير app.yml وسنحاول تفعيل SSL مرة أخرى.

حسناً. هذا مثير للاهتمام…

إذا أعيدت بناء التطبيق مع تفعيل SSL (LETS ENCRYPT), أحصل على موقعين مختلفين…

  • HTTP: موقع جديد كما هو متوقع
  • HTTPS: الموقع القديم المعطل

هاه. هذا محير حقاً!

ما الذي يعرضه الأمر

 docker ps

؟

قبل كل عملية بناء، قمنا بحذف جميع صور Docker القديمة وما إلى ذلك، على النحو التالي:

docker system prune -a

لذلك، ليست المشكلة متعلقة بصورة Docker.

نعتقد أن المشكلة مرتبطة بشهادة SSL الخاصة بـ LETSENCRYPT؛ لأنه عند تغيير النطاق الفرعي وتوليد شهادة SSL جديدة في عملية البناء على نفس عنوان IP للخادم، تعمل كما ينبغي؛ ولكن عند العودة إلى النطاق الفرعي الأصلي، تظل المشكلة قائمة.

لذلك، توقفنا عن استخدام النطاق الفرعي المثير للمشاكل مؤقتًا (كان نطاقًا تجريبيًا على أي حال)؛ وانتقلنا إلى ما بعد ذلك.

شكرًا على الأفكار.

ابقوا آمنين.

لكن هذا يحذف الصور غير المستخدمة فقط. هل أنت متأكد من عدم وجود حاويات قيد التشغيل؟

يبدو أن لديك أكثر من حاوية واحدة - هل يوجد أكثر من ملف app.yml في مجلد الحاويات؟

docker ps يُظهر حاوية واحدة فقط قيد التشغيل، وهناك ملف app.yml واحد فقط في /var/discourse/containers

شكرًا على جميع الأفكار الممتازة!

مقدر جدًا.