Проблема с пересборкой из-за медленного завершения работы базы данных

Спасибо. То есть нужно использовать ./launcher rebuild web_only (или rebuild data) вместо ./launcher rebuild app, и мне придётся внимательно следить за обновлениями, чтобы вручную обновлять PostgreSQL или Redis, когда они обновляются. Главное преимущество перед standalone-версией в том, что при пересборке не нужно ждать, пока база данных закроется и снова запустится, откатывая транзакции в случае принудительного завершения.

Однако благодаря последним изменениям в Falco база данных должна завершаться корректно, если только на это не уходит более 10 минут, что точно не произойдёт, если только у нас не появится на несколько порядков больше пользователей. Поэтому обновления не будут завершаться неудачей из-за этой проблемы, а основной эффект — лишь увеличение времени обновления на пару минут.

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

На всякий случай, для контекста: такое изменение должно давать существенные преимущества, чтобы оправдать эти издержки, поскольку всё это делается мной как бесплатная услуга (уже более 15 лет, но тем не менее), а не как моя работа. Здесь, как говорится, YMMV (результаты могут отличаться).

Верно.

Многие разделяют это мнение, что меня продолжает удивлять. Обновления Postgres выходят реже одного раза в год, и обычно задержка их установки на несколько месяцев после первоначального релиза не влечёт никаких негативных последствий. Наличие двухконтейнерной конфигурации позволяет откладывать обновление Postgres проще, чем в случае с одним контейнером, что, на мой взгляд, является ещё одним преимуществом.

В двухконтейнерной конфигурации вы можете выполнить:

 ./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only

и получить (как правило) менее минуты простоя.

Но если вы этого не хотите, то и не делайте.

Исторически откладывание обновлений PostgreSQL означало простое изменение конфигурационного файла YAML, если только вы не планируете прекратить его поддержку. Мы можем выдержать несколько дополнительных минут простоя при обновлениях, и, на мой взгляд, это менее рискованно, чем полагаться на одного человека (это я!), чтобы он правильно поддерживал нестандартную и более сложную конфигурацию.

С моей точки зрения, главное преимущество использования двух контейнеров — это сокращение времени простоя. Как и вы, я считаю, что 20–30 минут простоя раз в несколько месяцев вполне приемлемо. Однако легко понять, что для некоторых форумов это слишком много.

Согласен. Даже если бы речь шла о 90 минутах непрерывного простоя против 5 минут с перерывами, я всё равно, вероятно, не считал бы такие изменения стоящими, хотя, если бы они занимали так много времени, я бы, скорее всего, проводил обновления поздно ночью, а не в удобный полдень. Мы не платформа для реальной торговли акциями, мы — бесплатный форум о видеоиграх.

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

Однако я почти 35 лет провёл, работая в командной строке.

А теперь у меня есть панель управления, которая автоматизирует эти обновления через командную строку (включая обновления PostgreSQL и множество других задач).

Но не чини то, что не сломано, и я понимаю, что перемещение компонентов и потенциальный риск что-то сломать пугает.

Я сам начинал с Slackware, но я просто не считаю поддержку форума увлекательным занятием и хочу, чтобы она прекратилась, чтобы я мог снова биться головой о стену, пытаясь интегрировать Google Home с Home Assistant (или с чем-то ещё, что на этой неделе привлечёт моё внимание).