Панель управления Literate Computing успешно обновила два автономных узла и один узел с двумя контейнерами без каких-либо инцидентов. В основном всё сводилось к изменению целевой версии Postgres в переменной, так что, как и обещалось, процесс такой же, как и в нескольких последних обновлениях.
На самом деле этот метод довольно хорошо поддерживается, и он намного безопаснее, чем обновление основной версии базы данных. Если что-то пойдёт не так, вы просто не переключитесь на новый сервер. Если вы близки к необходимости обновления операционной системы и/или хотите минимизировать время простоя, это хороший вариант. Во время сборки нового сервера доступ будет только для чтения, а затем вы переключитесь на него. В простом случае у вас будет время простоя только на финальной пересборке, либо нулевое время простоя, если вы скопируете сертификаты со старого сервера).
Если при обновлении базы данных что-то пойдёт не так, создание нового сервера и восстановление из резервной копии — это простое решение.
Обязательно сделайте резервную копию перед началом. Я делаю резервную копию только базы данных, поскольку ваши загрузки вы всё равно не потеряете.
Просто чтобы уточнить, я не использую PostgreSQL, предоставляемый Discourse, и сам Discourse пока не требует PG18, верно? Значит, мне (пока) не обязательно обновляться до PG18.
Верное замечание. Но другая причина в том, что LTS-релизы выходят раз в пару лет, поэтому не такая уж плохая идея сделать это одновременно.
У вас definitely есть время. Они довольно быстро после обновления настояли на… э-э, каком-то релизе из-за какой-то необходимой функции, но вы, скорее всего, можете подождать до года. Я слежу за репозиторием discourse_docker. В какой-то момент они начнут говорить об удалении поддержки PG15; это не особенно шумно и является простым способом следить за обновлениями внутренних компонентов.
Это могло бы подтолкнуть других скорее последовать нашим смелым шагам.
Мой бесплатный ИИ для веб-поиска говорит мне:
Для типичного Rails-приложения переход с PostgreSQL 15 на 18 может обеспечить ~10–25% более высокую производительность запросов без изменений в коде, а до 40% — для определённых паттернов запросов, если использовать новые возможности индексации и планировщика.
Если это правда, то это довольно значительное улучшение!
Верно, но мы стремимся к простому и прозрачному механизму обновления. Есть преимущества в обоих подходах.
Я бы сказал, делайте то, что вам кажется удобным, и не бойтесь настраивать шаблоны в discourse_docker по мере необходимости. Очевидно, главное — сначала протестировать и иметь план отката.
На нашей хостинговой платформе мы планируем провести больше тестов и бенчмарков перед их включением, поэтому я также отключил их в discourse_docker, чтобы согласовать конфигурацию. Однако отключать их не обязательно (внутри мы используем только часть discourse_docker для веб-контейнера), и я не против их включения.
Один потенциальный подвох заключается в том, что pg_upgrade не будет работать, если в старых и новых каталогах данных будут разные настройки контрольных сумм. Процесс должен выглядеть так: остановить сервер PG15, запустить pg_upgrade для конвертации в PG18 без контрольных сумм, запустить pg_checksums для включения контрольных сумм, а затем запустить PG18. Это не является проблемой при использовании дампа и восстановления (как в этом обновлении), но об этом стоит помнить.
Обратите внимание, что контрольные суммы данных доступны с версии Postgres 9.3, но до сих пор были отключены по умолчанию. В Postgres 19 также появится возможность включать/отключать их на лету.
На данный момент — нет. Большинство функций Discourse использует адаптер Rails для PostgreSQL для взаимодействия с БД, но для резервного копирования/восстановления используются pg_dump и psql в веб-контейнере. Сейчас мы устанавливаем клиенты как PG15, так и PG18, чтобы обеспечить резервное копирование/восстановление для обеих этих версий, но в какой-то момент в будущем мы удалим PG15.
Главным фактором было переключение на новый встроенный поставщик локалей. Мы работаем над обновлением ОС на нашей хостинговой платформе и хотим разорвать зависимость от glibc.
e7f1201 добавил клиент PG18 в веб-образ для обеспечения совместимости резервных копий. Если вы не используете ни один из компонентов сервера Postgres в discourse_docker, то это самая ранняя ревизия, которую следует использовать для PG18.
Я говорил об обновлении, которое было одно или два назад.
Согласен. Моя мысль заключалась лишь в том, что возможность восстановления старой резервной копии PostgreSQL на более новой версии ничуть не менее поддерживается. Механизм обновления на месте работает удивительно хорошо для подавляющего большинства пользователей, но когда что-то идёт не так, трудно понять, что делать (во многом потому, что это происходит крайне редко).
