Проблемы доступа к базе данных после обновления с v3.5.2 до v3.6.0.beta2

  • v3.5.2 → v3.5.2
  • v3.6.0.beta2 → v3.6.0.beta2

Эта тема привела меня к следующему: Upgrade failed. Database stopped. (multisite install)

Теперь у меня возникли проблемы с доступом к базе данных:


2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse LOG:  предоставленное имя пользователя (postgres) и аутентифицированное имя пользователя (discourse) не совпадают 
2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse FATAL:  Ошибка аутентификации по пиру для пользователя "postgres" 
2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse DETAIL:  Подключение соответствует строке 89 файла pg_hba.conf: "local   all             postgres       
                        peer"
postgres=# \l
Список баз данных
Имя     | Владелец   | Кодировка | Провайдер локали | Сортировка   |    Ctype    | Локаль ICU | Правила ICU |   Привилегии доступа
-------------±---------±---------±----------------±------------±------------±-----------±----------±-----------------------
b_discourse | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
c_discourse | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
discourse   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
postgres    | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
template0   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres           +
|          |          |                 |             |             |            |           | postgres=CTc/postgres
template1   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres           +
|          |          |                 |             |             |            |           | postgres=CTc/postgres
(6 строк)


Файл multisite.yaml изменился между этими версиями.

Оригинал:
secondsite:
adapter: postgresql
database: b_discourse
pool: 25
timeout: 5000
db_id: 2
host_names:
- ``forum.domain.com

Новый:
mlp:
adapter: postgresql
database: discourse_mlp
username: discourse_mlp
password: applejack
host: dbhost
pool: 5
timeout: 5000
host_names:
- discourse.nudderdomain.com
- discourse.nudderdomain.internal

Я никогда не задавал пароли или пользователей для мультисайта, так как это не требовалось и не указывалось в исходном шаблоне при его настройке.

Изначально я не мог выполнить обновление, потому что мультисайт не работал из-за проблем с правами доступа для двух сайтов, перечисленных в multisite.yml. Добавление пользователя postgres в multisite.yml не помогло для миграции. Теперь я понимаю, возможно, мне стоило попробовать пользователя discourse?

Просто изменение владельца на discourse исправит ситуацию? Нужно ли мне добавить пользователей и пароли для мультисайта, чтобы он соответствовал текущей конфигурации?

Какое лучшее долгосрочное решение здесь?"}

Ваш пост очень трудно читать, поэтому я снял его с публикации. Пожалуйста, исправьте форматирование, и я снова его опубликую.

К сожалению, я приложил много усилий, чтобы сделать это максимально понятным и связным.

Я знаю, что имею в виду. :wink:

РЕДАКТИРОВАНИЕ: OK, понял. Другой форум, которым я пользуюсь, немного отличается. Я использую три обратных апострофа на строке перед блоком и после него. Теперь я вижу, что происходит. Здесь первый набор апострофов вставляет окно для вставки. Я не мог понять, почему тройные апострофы не работали и </> не давали мне того, что я действительно хотел.

Вы можете переключиться на редактор Markdown, если вам нужно много работать с разметкой в вашем посте.

Проблемы с паролем к вашей базе данных выглядят странно. Вы думали о переезде на новый сервер? Это может быть быстрее и проще, чем бороться с этой проблемой.

Вы следовали этим инструкциям? (Кажется, что нет?)

Это довольно вероятный вариант, но убедитесь, что у вас есть всё необходимое, как описано в теме о мульти-сайтовой установке.

Если ваши сайты сейчас работают, я тоже рекомендую выполнить чистую мульти-сайтовую установку и перенести базы данных через резервное копирование и восстановление. Вы можете скопировать все остальные файлы, как описано в Перенос сайта Discourse на другой VPS с помощью rsync

Я задавался вопросом, почему назвал свои базы данных b_discourse и c_discourse. Теперь я знаю почему. :wink:

## Сюда помещаются плагины
## подробности см. по адресу https://meta.discourse.org/t/19157
hooks:
  after_postgres:
     - exec: sudo -u postgres createdb b_discourse || exit 0
     - exec:
          stdin: |
            grant all privileges on database b_discourse to discourse;
          cmd: sudo -u postgres psql b_discourse
          raise_on_fail: false
            
     - exec: sudo -u postgres createdb c_discourse || exit 0
     - exec:
          stdin: |
            grant all privileges on database c_discourse to discourse;
          cmd: sudo -u postgres psql c_discourse
          raise_on_fail: false

     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<< "alter schema public owner to discourse;"'
     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<< "create extension if not exists hstore;"'
     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<< "create extension if not exists pg_trgm;"'

Я не до конца понимаю, как предоставляются привилегии, поэтому и задавался вопросом об этом. (Скриншот выше для двух проблемных баз данных):

Ну, хорошие и плохие новости. :frowning:
Теперь мы хотим :frowning:

2025-11-07 18:05:41.555 UTC [4724] discourse@b_discourse ERROR:  must be owner of extension vector
2025-11-07 18:05:41.555 UTC [4724] discourse@b_discourse STATEMENT:  ALTER EXTENSION vector UPDATE TO '0.8.0';
2025-11-07 18:05:41.752 UTC [4725] discourse@c_discourse ERROR:  must be owner of extension vector
2025-11-07 18:05:41.752 UTC [4725] discourse@c_discourse STATEMENT:  ALTER EXTENSION vector UPDATE TO '0.8.0';

вместо

ALTER EXTENSION vector UPDATE TO '0.7.0';

Но:

b_discourse=# ALTER EXTENSION vector UPDATE TO '0.8.0';
ERROR:  extension "vector" has no update path from version "0.7.4" to version "0.8.0"

Я с опаской относился к простой смене владельцев баз данных, но, похоже, это следующий шаг.

РЕДАКТИРОВАНИЕ: ОК. Это не сработало. Похоже, ключевым здесь является владелец расширения, а не владелец базы данных. На данный момент версия 0.8.0 отсутствует в моём контейнере. Максимальная доступная версия — 0.7.4 :frowning: Похоже, «базовая» версия обновилась во время попытки установки версии 15.

Можно ли настроить ./launcher для подключения от имени пользователя postgres? Похоже, это решило бы все мои проблемы с обновлением.

b_discourse=# select e.extname, u.usename 
             from pg_extension e 
             join pg_user u on e.extowner = u.usesysid;
 extname  |  usename  
----------+-----------
 plpgsql  | postgres
 hstore   | postgres
 pg_trgm  | postgres
 unaccent | discourse
 vector   | postgres
(5 rows)

Кажется, есть «проблемы» даже при попытке изменить владельца расширения. Первая найденная ссылка относится к 2017 году, и в 2022 году эта функция всё ещё не реализована.

Я использовал apt для установки нового расширения, и оно заработало. Ну вот. Теперь нужно сделать правильные резервные копии и обновиться до PostgreSQL 15. Но не сегодня вечером. :wink:

Похоже, моя история была очищена, поэтому я не могу точно сказать, как я это сделал, но будьте осторожны. Для этого требуется PostgreSQL 13, и система попытается переустановить его.

P.S.: Оказалось, что я включил автоматическое резервное копирование, но забыл об этом. Хотя я и не знал, где они находятся. Я настрою процесс rsync, чтобы переносить их в ту же директорию, где я делаю резервные копии других серверов.