Мы используем PostgreSQL v12, так как обновление до v13 требует слишком много места на диске. Похоже, совместимость с v12 могла быть нарушена? Это сделано намеренно? Если да, то это означает, что мы больше никогда не сможем обновить Discourse.
Запуск ./launcher start app вернул нас в онлайн, так что в данный момент это не проблема в продакшене, но невозможность обновляться даже в случае проблем с безопасностью и т. д. для нас будет очень плохой новостью.
Из app.yml:
- "templates/postgres.12.template.yml"
Запуск ./launcher rebuild app:
FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** FAILED TO BOOTSTRAP ** пожалуйста, прокрутите вверх и поищите более ранние сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь диагностировать проблему.
В настоящее время используется версия 2.8.0.beta4 75b0d6df93.
Почему бы вам не создать резервную копию, развернуть совершенно новый экземпляр Discourse (который по умолчанию будет использовать PostgreSQL 13), восстановить из резервной копии и перенастроить сервер в DNS?
Это менее страшно, чем неприятная работа, которой я хотел бы избежать, плюс сообщение моему форуму о том, что они потеряют день или два постов. В идеале, хотелось бы, чтобы разработчики Discourse сказали: «Конечно, мы всё ещё работаем над PG12, это просто ошибка, мы исправим это».
А, я понял, это ошибка, появившаяся из-за pull-запроса от сообщества. Так как мы нигде не используем PG12, она осталась незамеченной. Дайте мне пару минут.
@Wingtip, не могли бы вы попробовать собрать заново?
При этом мы больше не используем PG12, поэтому в ядре в любой момент может появиться синтаксис SQL, доступный только для PG13 и выше. Поэтому было бы неплохо запланировать обновление когда-нибудь.
Я проверю это сразу после создания еще одного снимка моей виртуальной машины.
Действительно раздражает, что PG требует огромного количества дискового пространства для обновления. С Oracle или MySQL такой проблемы нет — они обновляются на месте.
pg_upgrade предоставляет единственную опцию --link для выполнения обновления на месте.
Мы решили не использовать её в нашем «простом для новичков» скрипте обновления лаунчера, так как 99% установок работают на облачных ВМ, где можно легко и недорого увеличить размер диска.
Однако эта опция остаётся доступной для тех, кто предпочитает выполнять обновление вручную, чтобы сэкономить место на диске в процессе.
Было предложено 2 решения; насколько я помню, одно требовало утроения размера всей базы данных, а другое — примерно двойного. Если это можно сделать без перемещения данных, документирование этого факта было бы очень полезным.
