Как правильно перенести сайт на новый сервер?

Question

[WeReng]

Здравствуйте!
Есть сайт, на котором пользователи каждый день оставляют комментарии к записям, т.е. в базу данных постоянно записываются какие-то данные. Стоит задача перенести сайт с одного сервера на другой.
Если бы сайт был статичный, то никаких вопросов бы не было. Переносим файлы и базу на новый сервер и обновляем DNS записи. Таким образом трафик через некоторое время со старого сервера пойдет на новый, после того как DNS полностью обновится.
Однако у меня есть подозрения, что DNS обновится не у всех пользователей разом, поэтому часть будет попадать на старый сервер, а часть на новый. Если база данных постоянно обновляется, такого допустить нельзя, все посетители должны сразу попадать на новый сервер.
Поэтому вопрос, как сделать так, чтобы после переноса всех файлов и базы данных, пользователи, которые все еще попадают на старый сервер были автоматически перенаправлены на новый. Есть мысли, что нужно в nginx в конфиге прописать какое-то перенаправление по ip на новый сервер, но к сожалению, опыта в правке nginx конфигов недостаточно.
Каков верный путь решения моей проблемы?
Спасибо!

Comments

[spotifi]

> Однако у меня есть подозрения, что DNS обновится не у всех пользователей разом

Ага. У кого то может обновиться за час. А у кого-то только после перезагрузки его домашего говнороутера через неделю.

[landergate]

Что именно подключается к БД? На чём работает сам сайт?

[landergate]

Перед сайтом есть nginx?

[WeReng]

landergate: Сайт работает на WordPress, но хотелось бы получить общий ответ, который в целом подходит для динамических сайтов. Хочется понять как правильно это сделать.

[WeReng]

landergate: на сервере nginx + php-fpm + mysql

Answer 1

[Андрей]

Если сайт не сильно серьёзный и бд небольшая и не хочется сильно париться. То:
1. Создаем базу на новом сервере
2. Заливаем движок на новый сервер
3. Отрубаем сайт на тех работы и быстренько делаем перенос базы через ssh перед этим сделав удалённое соединение. и быстренько меняем конфиг (подключение к бд) на удалённое соединение через айпи xxx.xxx.xx.xx:3306
4. Открываем сайт
5. На новом сервачке только конфиг где будет идти локальное подключение к бд.
6. Файлы аватары музыку или чё там ещё у вас льёться на старом сервачке в движке дописываете чтобы заливались ассинхронно на оба сервака!
7. Через денька 3 наверочку сносим старый сайт.

Comments

[spotifi]

Асинхронно на 2 сервера сразу - слишком много геммора.

[Андрей]

spotifi: нормально. Я сам так переезжал.

[spotifi]

Андрей:
Я не говорю что так нельзя.
Я говорю, что можно проще - редиректом. См. рядом.

> Если сайт не сильно серьёзный и бд небольшая и не хочется сильно париться.

Вот для "небольших" и "не хочется париться" - ваш метод как раз перебор по сложности.
Для гораздо более серьезных ситуаций - согласен, нужно что-то подобное вашему предложению.
Но не для "небольших" и "не хочется париться"

Answer 2

[landergate]

1. Обеспечьте общую внутреннюю сеть между 1 и 2 сервером.
   
2. Поставьте nginx на 1 сервер, указав в качестве бэкенда ваше веб-приложение на 127.0.0.1.
   
3. Разверните копию nginx, файлов сайта и структуру БД на втором сервере.
   
4. Убедитесь, что с первого сервера есть связь к вашему веб-приложению (ему самому, а не nginx) через внутреннюю сеть.
   
5. Однажды ночью, проведите короткую профилактику, остановив первый сайт.
   
6. Перенесите данные БД с первого сервера на второй.
   
7. Настройте на первом сервере у nginx в качестве бэкенда второй сервер.
   
8. Смените DNS с первого сервера на второй.
   

Теперь ваше веб-приложение работает на втором сервере, а при подключении к первому, пользователь получит результат работы второго сервера.

Первый сервер можно оставить в эфире до тех пор, пока к нему не прекратятся соединения.

--
P.S. Чтобы не морочиться с внутренними сетями (хотя это несложно сегодняшними средствами), вот альтернатива первому пункту:
Откройте в фаерволе на втором сервере возможность первому серверу подключиться прямиком к веб-приложению по его порту. В 7 пункте, nginx можно будет настроить на публичный адрес и порт приложения. Учтите, что трафик между двумя серверами в этом случае шифроваться не будет. Рисков в связи с этим не очень много, но, при желании, соседи или ЦОД смогут "подслушивать" ваш трафик между серверами.

Comments

[spotifi]

Насчет соседей по ЦОДу громко сказано. Кому нужно хакать внутри датацентра таким образом. Влезь на сам сервер и его взломать - это запросто. А слушать трафик в надежде поймать подобное межсайтовое соединение, которое является большой редкость..... Навряд ли соседи этим занимаются.

[landergate]

spotifi: Я тоже считаю, что рисков в связи с этим мало. Должно многое совпасть.
Но технически сделать это возможно.

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

Я бы перестраховался, но лишь потому, что я смогу это быстро настроить. =)

[littleguga]

landergate: а как бы Вы делали внутреннюю сеть? Не совсем понял, что Вы под эти имеете ввиду.

[landergate]

littleguga: Софтовый VPN между серверами, выглядящий, как просто ещё один сетевой интерфейс, по которому все сервера доступны между собой, словно если бы они находились в одной локальной сети.

[littleguga]

landergate: понял, спасибо.

Answer 3

[spotifi]

Делаешь поддомен третьего уровня. Настраиваешь на нем новый сайт. В том числе и переносишь БД.
Все проверяешь.
Должно работать как при заходе от имени основного домена так и от имени временного домена третьего уровня.

Быстрая операция из двух пунктов:

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

2. Включаешь на старом сайте переадресацию на новый поддомен - т.н. http переадресация "временно см. по такому-то адресу"

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

Когда на старый сайт более заходить не будут, убиваешь его. Обычно это дня 3.

P.S:
Обслуживание поддомен убиваешь не сразу. Можешь сразу сделать 301 редирект с поддомена на основной сайт.

Comments

[WeReng]

Спасибо! Подскажите, а нет ли варианта обойтись без поддомена? Мои мысли изначально ошибочные, что на уровне nginx можно попытаться как-то перенаправлять на другой сервер?

[spotifi]

WeReng:
Можно и nginx.
Но это более геморнее по по-моему. Плюс будет задержка дополнительная: от пользователя на сервер, оттуда на другой сервер, обратно на первый сервер, обратно пользователю.