Просто к сведению — не пытайтесь выполнять это обновление в часы пик.
Обновление версии 2.6.0b2 уже выполняется на нашем сервере более 40 минут, хотя обычно оно занимает всего пару минут и завершается, пока вы ещё не успели вернуться. Я начал беспокоиться, что что-то сломалось, но при входе в postgres увидел, что запущено масштабное обновление: похоже, оно обновляет данные поиска по постам для личных сообщений.
Надеюсь, что всё в порядке. Узнаю, как закончится. Очень не хочу останавливать процесс или перезапускать контейнер во время обновления.
Запущенный запрос:
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
Обновление оказалось довольно медленным даже для меня на быстром оборудовании в колокации. Не совсем понимаю, почему, но это определённо стоит иметь в виду.
Да, я предлагаю добавить примечание в список изменений, предупреждающее, что это обновление, скорее всего, займёт гораздо больше времени, чем большинство других, и что не стоит его прерывать или предпринимать какие-либо резкие действия, так как это нормально.
На моём локальном сайте не было так много постов, и он всё равно работал довольно медленно. Не 40 минут медленно, но заметно медленнее, чем при предыдущих обновлениях — возможно, в 3–4 раза?
Спасибо, @Wingtip, я думал, что это происходит только у нас!
На самом деле мне пришлось отменить пересборку и перезапустить приложение, потому что я подумал, что оно застряло на том запросе, о котором вы упоминаете. У нас 6 миллионов постов, и примерно через 45 минут процесс всё ещё не был завершён, так что, похоже, мне придётся быть готовым к как минимум часу пересборки и предупреждать наших пользователей об этом заранее.
Только что взял секундомер и протестировал пересборку (сайт с примерно 1 млн постов) с версии 2.6.0b1 на b2; с начала и до конца это заняло 170 секунд.
Я тоже не использую Docker-менеджер и предпочитаю пересборку через командную строку. Так лучше видно логи на случай, если что-то пойдет не так. Мне также кажется, что это быстрее.
У меня был большой сайт, который неоднократно не удавалось запустить. Это установка с двумя контейнерами, поэтому старый контейнер продолжал работать, пока происходила миграция при запуске. В конце концов я решил проблему, включив SKIP_POST_DEPLOYMENT_MIGRATIONS=1 для процесса запуска, а затем запустив миграции после того, как новый контейнер был поднят. С параметром SKIP_POST_DEPLOYMENT_MIGRATIONS=1 в секции ENV миграция прошла очень быстро, и сайт смог функционировать нормально (хотя, возможно, медленнее), пока выполнялись миграции, что заняло, по-моему, более 20 минут.
Я думаю, но ещё не проверил, что использование этого же приёма позволит минимизировать время простоя и при установке с одним контейнером. Если я прав, то нужно сделать следующее:
добавить SKIP_POST_DEPLOYMENT_MIGRATIONS=1 в ваш app.yml
./launcher rebuild app
./launcher enter app
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
отменить изменения в app.yml, если только вы не планируете помнить о необходимости выполнять миграции после каждого обновления
возможно, снова выполнить rebuild, чтобы убедиться, что у вас не возникнет проблем, пока вы ещё помните, что могло сломать ваш сайт. Иначе, например, через 4 месяца, когда вы снова попробуете, вы не будете знать, что случилось, и кому-то будет трудно догадаться, в чём проблема.
Если бы существовал способ передавать SKIP_POST_DEPLOYMENT_MIGRATIONS=1 через ./launcher без необходимости редактировать app.yml, это сделало бы процесс менее неудобным для тех, кто испытывает трудности с редактированием.
Если мне удастся выполнить эту работу, о которой я думаю, я создам новую тему и сообщу о своих находках. Хотя дым загнал меня в комнату, где у меня нет большого монитора. (Пандемии было недостаточно?! Нам ещё и дым нужен? И я даже не особенно близко к этому проклятому огню.)
Это замечательная новость! (Сегодня встало два других проекта, и somehow мой мультисайтовый инстанс перестал работать и корректно взаимодействовать с S3. ) Большое спасибо.
Существует ли техническая причина, по которой изменения в базе данных после обновления по умолчанию должны блокировать работу? Можно ли изменить это поведение, чтобы при будущих обновлениях сайт быстро возвращался в рабочее состояние, а затем выполнялись пост-обновляющие операции в фоновом режиме?
На мой взгляд, всё, что критически важно для функционирования обновлённого приложения, например DDL, должно быть частью самого обновления, а не находиться в скриптах пост-обновления.
Редактирование: тем временем я завершил процесс, чтобы снова запустить сайт для наших пользователей. Но должно быть более эффективное решение для этого обновления.
) Большое спасибо.