PostgreSQL عالق أثناء إعادة البناء

تثبيت
1

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

أواجه مشكلة في بدء تشغيل PostgreSQL عند محاولة إعادة بناء تطبيقي، وآمل أن أحصل على بعض المساعدة.

هذا هو السجل، وقد ظل عالقًا في هذه الحالة لأكثر من 30 دقيقة.

Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1]  INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.362740 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.367767 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.372845 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377501 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377876 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres & && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-08-26T17:16:15.453058 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1]  INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG:  database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG:  redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG:  invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG:  redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG:  database system is ready to accept connections```
2

لم يتم إيقافه بشكل سليم وحاول إصلاح الأشياء، ويعتقد أنه فعل ذلك.

ربما قم بإيقافه باستخدام control-c وحاول تشغيل الحاوية القديمة مرة أخرى باستخدام ./launcher start app.

إذا نجح ذلك، يمكنك المحاولة مرة أخرى لإيقاف الحاوية باستخدام ./launcher stop app ثم إعادة بنائها.

3 إعجابات
3

لقد كنت أواجه نفس الشيء في محاولة إعادة البناء في الأيام القليلة الماضية. لا يمكنني تشغيل Discourse أو إعادة بنائه دون مشاكل.

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

4

لم ينجح Control-C وحاولت العديد من الأشياء المختلفة، بما في ذلك العودة إلى الإصدارات القديمة، ولكن بمجرد أن حاولت إعادة البناء، علقت في نفس المكان بالضبط.

5

ما مقدار ذاكرة الوصول العشوائي لديك؟ هل اتصال شبكتك بطيء؟

6

بالنسبة لمشكلتي… لدي ذاكرة وصول عشوائي وفيرة… 8 جيجابايت. الشبكة على ما يرام

7

4 جيجابايت من ذاكرة الوصول العشوائي، لقد تحققت من الشبكة، استخدام القرص، استخدام وحدة المعالجة المركزية، استخدام ذاكرة الوصول العشوائي، كل شيء يبدو على ما يرام.

8

تمكنت من إحراز المزيد من التقدم. في /var/discourse/ على خادمي، قمت بسحب الالتزام b1108913820edd27f869634d0fc654639758889a. هذا الالتزام يعود إلى بضعة أيام مضت، ولا يحتوي على هذه الالتزامات الثلاثة (1، 2، 3 في سجل discourse_docker. أشك في أن أحد هذه التغييرات هو سبب مشكلة تعليق postgres.

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

3 إعجابات
11

نفس المشكلة هنا عند الترقية من 3.3.0 إلى 3.3.1. الترقية عالقة عند نفس سطر السجل (نظام قاعدة البيانات جاهز لقبول الاتصالات).

إعادة التشغيل تساعد أو مجرد إنهاء عملية الترقية وتشغيل ./launcher start app. الإصدار الجديد 3.3.1. يظهر. لكن لست متأكدًا مما إذا كانت هذه إجراءات سليمة.

13

إذًا هناك أربعة أشخاص لديهم مشكلة، أعتقد.

هل واجه من واجهوا مشكلة مشكلة على ARM أم على Intel؟

إعجاب واحد (1)
14

هذا سؤال رائع.

لقد قمت للتو بتثبيت جديد على جهاز افتراضي جديد من Digital Ocean ثم قمت بإعادة البناء وعمل بشكل جيد.

15

أنا أستخدم Intel.
الطريقة التي قمت بها بحل المشكلة هي أنني اضطررت إلى بدء قطرة جديدة وإجراء تثبيت نظيف، واستعادة النسخة الاحتياطية، ثم يعمل إعادة البناء بشكل جيد.
لدي أيضًا نسخة احتياطية من إصدار يعمل (وهو على إصدار أقدم قليلاً)، ولكن بمجرد أن قمت بالترقية إلى أحدث إصدار عبر إعادة البناء، واجهت نفس المشكلة، لذلك أشك في أن هناك شيئًا تم تقديمه مع التزام حديث ويكسر فقط التحديث من الإصدار القديم إلى الجديد.

إعجاب واحد (1)
16

تباً.

هممم. سأرى ما إذا كان لدي موقع لا أهتم إذا تعطل.

أعتقد أن لديك تثبيتًا قياسيًا قياسيًا يحتوي على حاوية واحدة. سأرى ما إذا كان بإمكاني العثور على واحد من هؤلاء.

17

مجرد رفع هذا الموضوع حيث أنني واجهت هذه المشكلة أيضًا منذ الالتزام المذكور أعلاه. جربت كل ما سبق لحل المشكلة.

إعجابَين (2)
18

x86. أنا على نظام Ubuntu Bionic لنظام التشغيل المضيف… ربما يكون لذلك عواقب. لست متأكدًا من نظام تشغيل الآخرين

19

لقد مر أكثر من عام على نهاية الدعم. https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices.

ليس من المبكر جدًا تشغيل جهاز افتراضي جديد والانتقال إليه.

4 إعجابات
20

مزيد من المعلومات للمساعدة في التحقيق في المشكلة.

يظهر هذا على مضيف واحد يعمل بنظام Ubuntu 18.04.6، ولكن تم تحديث مضيف آخر اليوم بنفس إصدار Ubuntu وتقدمت إعادة بناء Discourse بشكل طبيعي.

سأقوم بترقية Ubuntu على المضيف المتأثر لمعرفة ما إذا كان هذا سيساعد. سأبقي الجميع على اطلاع.

إعجابَين (2)
21

بالنسبة للمتأثرين، هل يمكنك تشغيل الأمر ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" وإخباري إذا كان الناتج يختلف عن الناتج أدناه؟

drwxr-xr-x  2  101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19  101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x  3  101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 01:38 redis_data
إعجاب واحد (1)
22 
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dec 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data
إعجابَين (2)
23

مخرجات من جهاز افتراضي يواجه مشكلة إعادة بناء:

drwxr-xr-x  2  101 104 4.0K Jun 15  2020 postgres_backup
drwx------ 19  101 104 4.0K May  3  2022 postgres_data
drwxrwsr-x  5  101 104 4.0K May  3  2022 postgres_run
drwxr-xr-x  2  103 106 4.0K May  3  2022 redis_data

ملاحظة فقط، شيء مختلف قليلاً في حالتي.
تعثرت عملية إعادة البناء عند نظام قاعدة البيانات جاهز لقبول الاتصالات كما رآها الآخرون. اضطررت إلى إعادة تشغيل الجهاز الافتراضي وتشغيل ./launcher start app لبدء المنتديات. ومع ذلك، عندما عاد Discourse، ظل إصدار Discourse عند الإصدار السابق 3.3.0.beta4-dev.

أنا غير قادر على إجراء ترقية Ubuntu اليوم، ولكن سأبقي الجميع على اطلاع عندما أتمكن من ذلك وما إذا كانت إعادة البناء ناجحة.

لقد قمت بترقية مثيل التطوير الخاص بنا إلى Ubuntu 20.6 اليوم وكانت إعادة البناء / الترقية ناجحة إلى Discourse 3.4.0.beta2-dev. ومع ذلك، كان هذا هو المضيف الذي تم إعادة بنائه أيضًا دون مشاكل على Ubuntu 18.4 بالأمس.