После того, как я наткнулся на истории о переносе информационной инфраструктуры компании с места на место, я подумал, что перенос среднестатистического контентного интернет-проекта с одной площадки на другую — тоже довольно интересная тема.
Особенно интересно, как это сделать с минимальными нарушениями.
Речь, конечно, идет не о мегапортале с двумя самосвалами железа, а о проекте среднего масштаба, когда серверов мало, все они арендуются, а не являются вашей собственностью, или у вас есть достаточный поставка ресурсов для переноса части серверов на новое место.
Наверняка есть способы сделать это лучше в определенных условиях, но я изложу свои мысли на эту тему.
Уверен, что, как это обычно бывает, кто-то к вышесказанному добавит свой ценный опыт. Рассказ рассчитан на подготовленную аудиторию и не является точным пошаговым руководством к действию.
Введение Итак, имеется типичный «джентльменский набор»:
- Nginx — это интерфейсный сервер, за которым следуют Apache или FastCGI.
- Сервер базы данных — MySQL
- Серверы в новом дата-центре — достойная замена серверам текущего хостера, который уже испытал ваше терпение до последнего предела.
В случае переезда между арендованными серверами договориться с новым хостером о тарифах чаще всего можно только с начала нового месяца, чтобы можно было ввести оборудование в эксплуатацию и перенести данные.
Таким образом, время простоя сервиса при миграции можно сократить как минимум до времени, необходимого для создания дампа базы данных.
Хорошо, если сервер базы данных уже настроен на репликацию; если нет, то вам тоже придется это сделать.
Весь процесс разделен на две части: первая — создание актуальной копии ресурса на новом сайте, вторая — плавное перенаправление трафика за счет постепенного обновления кеширующих DNS-серверов.
Код В хорошем случае код, шаблоны и т.п.
передаются простым действием: СВНКО svn://my.repository.ru/myproject/trunk .
База Итак, вам нужно открыть два подключения к рабочему серверу базы данных, написать в одной консоли очистить таблицы с блокировкой чтения , зайди в другой mysqldump с необходимыми параметрами.
Этот момент задуман как момент простоя, так как скорее всего в это время ваш проект может работать некорректно из-за блокировки чтения (только для чтения) всех таблиц, вам наверняка придется на это время повесить «заглушку» (Бонни создает полный дамп суперхаба примерно за 58 секунд).
После того как копия базы готова, в первой консоли пишем показать статус мастера и запомнить полученные значения (текущее имя файла бинарного журнала и позицию в нем) в какое-нибудь безопасное место.
Затем просто закрываем консоль, которая снимает блокировку таблицы, или выполняем разблокировать таблицы .
Архивируем полученный файл и переносим на новый сайт. Там, на новом сервере, который еще пахнет серверной фабрикой, мы создаем базу данных и восстанавливаем в нее данные.
Затем делаем этот сервер клиентом репликации базы данных со старого сайта и инициализируем репликацию из полученного ранее местоположения: измените мастер на master_log_file='server1-relay-bin.00025', master_log_pos=350384183; запустить раб; Если вы знакомы с репликацией и все сделали правильно, то через несколько минут у вас будет «живая» актуальная копия базы данных в новом месте.
В большинстве случаев трафик между разными сайтами передается с достаточной скоростью, чтобы все «написанные» запросы успевали дойти от сервера к серверу без очередей и задержек.
Примечание: этот пункт можно опустить, чтобы полностью исключить сбои в работе, если у вас уже есть подчиненный сервер, который вы можете переместить в новое место.
Пользовательские файлы Пользовательские файлы можно легко перемещать с помощью rsync (человек rsync).
При первоначальной подготовке вы можете скопировать полный набор хранилища, а при запуске запустить синхронизацию заново, чтобы синхронизировать изменения: обновить измененные файлы и перенести новые.
Перевод стрелок Сейчас решающий и самый интересный момент. Когда у вас уже есть две рабочие копии проекта, прежде чем вносить изменения в DNS, вам необходимо «привязать» один сайт к другому.
Это можно сделать, используя нативные возможности nginx, а именно его прокси-модуль.
То есть просто проксировать все запросы к новому серверу через старый (опять глупая тавтология, когда же это закончится?): proxy_pass http://new.server.ip:80/ .
Если все работает нормально, можно обновить файл зоны DNS (думаю, каждый может переместить DNS-серверы по-своему).
С этого момента одна часть запросов будет прозрачно обрабатываться старыми серверами, другая часть — новыми.
Разумеется, вторая часть будет расти по мере обновления записей кеширующих серверов, а первая часть исчезнет примерно через сутки.
Как только вы почувствуете, что старые сервера больше не нужны, вы можете отключить или перенастроить репликацию так, как вам нужно, и сообщить старому хостеру, что он больше не получит от вас ни рубля.
Теги: #переезд #очистить без потерь #Хабр
-
Лк Пишет Свою Операционную Систему?
19 Oct, 24 -
Заполнитель Входного Атрибута
19 Oct, 24
