Комментарии 8
А по Вашему опыту есть разница что переносить в начале, бд или сервисы приложения?
Насчёт того, что пользователи не заметили — а в вашем случае далеко машинки друг от друга стояли? Латенси возросшая на все запросы в бд не критична была?
Кстати, учитывая, что в большинстве продакшен веб приложений бутылочное горлышко по ресурсам это чаще любые операции с реляционной бд, возможно как раз имеет смысл начать и закончить мастер-слейв репликацией БД на новую тачку, чтобы у нас было «всё отлично». :)
Все упирается в контекст кейса. У меня никаким хайлоадом особо и не пахнет, никакого бутылочного горлышка у бд нет.
Про порядок: я осознанно оставил БД на старой машине и перевозил сначала stateless. Все очень легко и просто - приложение легко откатить, а базу нет. Пока новое приложение не подтвердило стабильность, я не хочу трогать данные.
Попробуйте docker swarm, он требует больше труда на установку, зато можно перемещать сервисы одной командой без даунтайма.
Если у вас при разрыве активного http/https соединения разваливаются данные, то как вы работаете? У вас все клиенты физичекски подключены по оптике к вашему 1 серверу и все оборудование на UPS и подобное? Врятли))
Если не разваливаются, то принудительное переключение между 2-мя nginx серверами ничего не испортит и ждать закрытия сессии не нужно.
И в эту же странную структуру вашего сервиса: вы говорите о недопустимости какого-либо даунтайма (что само по себе нонсенс) и при этом добавляете еще одну сетевую связаность в виде внешенй БД. Или это временное решение было?
Статья больше как туториал, скорее у кого-то есть активные ws или sse соединения - graceful reload nginx позволяет не обрывать их без необходимости
На счет бд - да временное, я это несколько раз повторил в статье. В заключении даже отметил отдельным абзацем, вы разве не заметили?

Как перенести Docker Compose на новую VPS без даунтайма