LINUX.ORG.RU
ФорумAdmin

Переключение версии сайта со staging на production с 0 downtime, как?

 ,


1

3

Есть сайт, работающий на одном хосте/машине, больше хостов нет (используется VPS/VDS). Сайт работает на базе php-fpm + mysqld + nginx, используется только одна база MySQL. PHP-исходники, которые обрабатывают текущие запросы лежат в папке /site/production. На хост была залита др. папка - /site/staging с новой версией исходников.

Теперь нужно:
1. Применить апдейт для БД в виде .sql-скриптов, которые могут поменять структуру таблиц базы.
2. Переключить nginx на новую версию исходников, т.е. с /site/production на /site/staging.

Эти два пункта нужно сделать одновременно, так, чтобы юзеры это вообще не заметили, ниодного HTTP-запроса не прервалось, т.е. с 0 downtime и connection draining.

Переключить root можно с помощью команды nginx reload и таким образом переключиться с /site/production на /site/staging. Проблема в том, что /site/staging зависит от скриптов апдейта БД - нужно вначале применить их, иначе .php-скрипты в /site/staging не будут работать. Если же вначале применить скрипты апдейта БД, то сайт некоторое время будет недоступен, потому как Nginx будет использовать старые исходники /site/production какое-то время, до полного переключения на /site/staging.

Как это можно сделать? Можно ли это сделать без введения второго хоста в строй? Если нет, как это делается в случае с двумя или более хостами? Можно ли обойтись без репликации MySQL?

Я полагаю, что для 0 downtime и connection draining нужна репликация MySQL: на slave применяются апдейты, нужные для /site/staging и затем переключаются через DNS, так ли это?

В общем, кто уже строил HA кластеры или имеет опыт для одного хоста переключения с 0 downtime сайта как вы это делаете или это можно сделать? Хотелось бы обойтись без введения второго хоста, если возможно.

Перемещено leave из web-development


Ответ на: комментарий от blackst0ne

При таком подходе в копии БД не будет записей, которые появятся в оригинальной БД пока будет вестись тестирование.

ProtoH
() автор топика
Ответ на: комментарий от ProtoH

Можно повесить триггеры на оригинальные таблицы, которые будут соответствующим образом вставлять(менять) данные в новой базе. Поверхностный гуглеж говорит о том, что можно сделать триггер на другую БД.

swelf
()
Последнее исправление: swelf (всего исправлений: 1)
Ответ на: комментарий от swelf

Судя по описанию, там монолитный кусок гомна на пыхе. Что-то я очень сомневаюсь, что эти люди осилят написать эти триггеры. А потом их придется переписывать под каждую новую версию приложения, в которой есть миграции.

Короче, это все костыли, здесь надо менять подходы к разработке и деплою.

leave ★★★★★
()
Ответ на: комментарий от ProtoH

для этой проблемы, очевидно, нет универсального решения 8)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.