هل جربت تثبيتًا جديدًا بدون استعادة ولكن مع الاتصال بقاعدة بيانات الواجهة الخلفية الحالية لديك؟
أعتقد أن هذا يعني احتمال فقدان أي إعدادات تم إجراؤها في واجهة المستخدم ولم يتم حفظها في قاعدة البيانات؟ لست متأكدًا مما هو آخر تم نسخه احتياطيًا واستعادته.
ربما يجب أن تفكر في الابتعاد عن bitnami إلى تثبيت قياسي فعلي. مشاكلك لا تنتج عن “أخطاء في ترحيل قاعدة البيانات”، بل هي خاصة بـ bitnami.
هل يوجد تثبيت قياسي لـ Kubernetes حتى الآن؟
هل تسمح كوبيرنيتيس بالتثبيت اليدوي؟ إذا كان الأمر كذلك، يمكنك إجراء تثبيت قياسي بهذه الطريقة. (لم أجرب ذلك قط، لذلك لا أعرف كيف تعمل كوبيرنيتيس)
أسمعك بوضوح بشأن مزايا التثبيت القياسي والطبيعة المستقلة وغير المصرح بها لمخطط Bitnami Helm. لم أقصد التلميح إلى أن الخطأ يكمن في Discourse نفسه. استمر اختياري لاستخدام Bitnami في الاعتماد على حساب يقارن تكلفة استكشاف الأخطاء وإصلاحها مع مخطط Bitnami وتكلفة تطوير مخطط Helm الخاص بي المكافئ بناءً على التثبيت المدعوم رسميًا ثم استكشاف الأخطاء وإصلاحها معه.
لقد نظرت في ذلك، لكنني أحاول تجنب التعديلات على إعدادات المخطط الافتراضي للبقاء “على المسار الرئيسي”. ومع ذلك، حاولت ترقية خادم Discourse فقط إلى الإصدار 3.2.0 عن طريق تجاوز علامة صورة النشر (Deployment image tag)، مع الاحتفاظ بقاعدة البيانات الحالية، لمعرفة ما إذا كانت عملية الترحيل ستنجح؛ إلا أنها فشلت.
لقد حاولت إسقاط قاعدة البيانات واستعادتها يدويًا عبر kubectl exec إلى حاوية postgres باستخدام ملف تفريغ SQL الذي أنشأه Discourse نفسه، ولكن هذا يفشل مع الخطأ المتعلق بجدول sidebar_sections. في الآونة الأخيرة، قمت بإنشاء جهاز افتراضي جديد واتبعت طريقة التثبيت القياسية لتثبيت Discourse الإصدار 3.3.0. عندما حاولت استعادة النسخة الاحتياطية، حدث نفس الخطأ.
خلاصتي هي أنه على الرغم من أن أرشيف النسخ الاحتياطي للإنتاج تم إنشاؤه بواسطة Discourse نفسه، فإن بنية قاعدة البيانات لتثبيتي الإنتاجي الإصدار 3.0.6 تختلف بطريقة ما عما يتوقعه Discourse، مما يتسبب في فشل عمليات الترحيل. إذا كان هذا هو الحال، فأنا متشائم بشأن خياراتي. الفكرة الوحيدة التي لدي في الوقت الحالي هي البدء في تعديل ملف تفريغ SQL في أرشيف النسخ الاحتياطي لإزالة الجداول التي تسبب أخطاء DuplicateTable التي تحدث في مرحلة ترحيل قاعدة البيانات لعملية الاستعادة.
إذا كنت ترغب في استخدام مخططات Bitnami Helm، فستحتاج إلى استخدام دعمهم.
على أمل أن ينقذ هذا شخصًا من التخبط لساعات عديدة كما فعلت أنا في هذا الموقف، إليك العملية التي سمحت لي أخيرًا بالترقية من Discourse v3.0.6 إلى v3.2.0 في سياق استخدام Bitnami Helm chart (v11 إلى v12). بينما لا ينبغي أن تكون هناك حاجة لمزيد من إخلاء المسؤولية بناءً على التعليقات أعلاه، فإن هذه المشكلة ناتجة عن خطأ في Bitnami Helm chart وصوره المخصصة؛ المشكلة لا تؤثر على إصدارات Discourse الرسمية.
توضح التعليمات أدناه كيفية التنقل في الترقية. يشير “موقع الإنتاج” إلى إصدار Helm chart لموقع Discourse الذي تتم ترقيته، ويشير “موقع الترحيل” إلى إصدار chart مؤقت تم نشره بالتوازي في مساحة الاسم discourse-dev.
قم بتثبيت نسخة جديدة من Bitnami chart v12.6.2 (Discourse v3.2.0). قم بتوسيع نشر خادم Discourse إلى الصفر.
$ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled
قم بإنشاء ملف SQL db_init.sql:
cat > /tmp/db_init.sql << EOF
DROP DATABASE bitnami_application;
CREATE DATABASE bitnami_application;
GRANT ALL PRIVILEGES ON DATABASE bitnami_application TO bn_discourse;
CREATE EXTENSION hstore;
CREATE EXTENSION pg_trgm;
ALTER database bitnami_application owner to bn_discourse ;
EOF
انسخ إلى pod قاعدة البيانات وقم بالتنفيذ:
$ kubectl cp -n discourse-dev db_init.sql discourse-dev-postgresql-0:/tmp/
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U postgres \
< /tmp/db_init.sql'
DROP DATABASE
CREATE DATABASE
GRANT
ERROR: extension "hstore" already exists
ERROR: extension "pg_trgm" already exists
ALTER DATABASE
قم بفك ضغط أرشيف النسخ الاحتياطي، وانسخ ملف dump SQL إلى pod قاعدة البيانات، وقم بالتطبيق:
$ ls
discourse-2024-03-04-143102-v20230119094939.tar.gz
$ tar xvf discourse-2024-03-04-143102-v20230119094939.tar.gz
$ gunzip dump.sql.gz
$ kubectl cp -n discourse-dev dump.sql discourse-dev-postgresql-0:/tmp/
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse \
--dbname bitnami_application \
< /tmp/dump.sql'
قم بتشغيل pod Discourse.
$ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled
راقب السجلات وقم بإسقاط الجداول التي تمنع الترقية:
$ kubectl logs --prefix -f -n discourse-dev -c discourse -l app.kubernetes.io/name=discourse
$ kubectl logs --prefix -f -n discourse-dev -l app.kubernetes.io/name=postgresql
راقب أثناء فشل ترحيلات قاعدة البيانات وقم يدويًا بحذف الجداول ذات الصلة حتى تنجح الترحيلات:
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse --dbname bitnami_application -c "\
DROP TABLE sidebar_sections; \
DROP TABLE sidebar_urls; \
DROP TABLE chat_threads; \
DROP TABLE form_templates; \
DROP TABLE category_settings; \
DROP TABLE category_form_templates; \
DROP TABLE theme_svg_sprites; \
DROP TABLE user_chat_thread_memberships; \
DROP TABLE summary_sections; \
"'
استعادة النسخ الاحتياطي لمجلد التحميلات:
$ PODNAME=$(kubectl get pod -n discourse-dev -l app.kubernetes.io/name=discourse --output=jsonpath={.items..metadata.name} | cut -f1 -d' ')
$ kubectl cp -n discourse-dev -c discourse uploads $PODNAME:/bitnami/discourse/public/
$ kubectl exec -n discourse-dev -c discourse $PODNAME -- bash -c 'chown -R 999:0 /bitnami/discourse/public/uploads/'
لسبب ما، لم يتم تنزيل المكونات الإضافية وتثبيتها تلقائيًا. قم بذلك يدويًا وتحقق من وظائف المكونات الإضافية.
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-oauth2-basic
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-math
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ chown -R 999:0 discourse-oauth2-basic discourse-math
قم بإنشاء نسخة احتياطية للموقع الذي تم استعادته حديثًا باستخدام لوحة تحكم النسخ الاحتياطي للمسؤول.
https://$BASE_URL/u/admin-login لتسجيل الدخول عبر رابط البريد الإلكتروني.