Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
Полезненько, добавляем в избранное полюбому пригодится. Спасибо!
Интересно было бы ещё посмотреть на рабочие примеры таких переносов, с использованием другой БД, например PostgreSQL или даже MSSQL, если хост по Windows…
Кстати, натыкались на особенность MySQL недавно — при переносе бд с Windows на Linux JDBC драйвер вдруг стал регистро чувствительным и пришлось править структуры базы и код, чтобы названия колонок таблиц были везде в верхнем регистре, может сталкивались подскажете ворк эраунд или кто-нибудь подсажет?
Кстати, натыкались на особенность MySQL недавно — при переносе бд с Windows на Linux JDBC драйвер вдруг стал регистро чувствительным и пришлось править структуры базы и код, чтобы названия колонок таблиц были везде в верхнем регистре, может сталкивались подскажете ворк эраунд или кто-нибудь подсажет?
Я думал что классическое решение — это настроить алиасом на новом сервере www2.* и со старого сервера перекидывать на него с помощью того же htaccess, пока DNS просасывается…
А редактировать .so файлы — это за гранью добра и зла… Я думаю, что так не стоит советовать
А редактировать .so файлы — это за гранью добра и зла… Я думаю, что так не стоит советовать
Почему? Редактировать надо только на старом серваке.
Почему бинарники не стоит редактировать? Потому что это адский костыль, и Вы не сможете гарантировать его последующую нормальную работу.
Если уж у нас сервер в полном контроле, лучше TTL у DNS поставить в 5 минут, и то лучше будет
Если уж у нас сервер в полном контроле, лучше TTL у DNS поставить в 5 минут, и то лучше будет
Ну можно еще пересобрать mysql… это все долго, а эффект тот же. И опять же, костыль этот на пару дней, на старой машине.
Можно! Хорошо, когда программисты используют один /config/connect.php, можно и поправить, а вот когда таких больше 10-30 или 100? Или когда ты просто не знаешь структуру сайта, выискивать все коннекты еще тот кайф, а потом менять. У того же РНР есть десяток названий функций для коннекта, попробуй все найди. Сколько это займет времени?
Не могли бы вы подделиться ссылочкой на такое классическое решение? Или просто немного более развёрнуто описать. С такими задачами просто не часто сталкивался, а нужно иногда.
Конечно.
Простое решение:
Разворачиваем на новом сервере полную версию сайта с БД и кодом, у веб сервера настраиваем адрес host и алиас www2.host
Заранее(за неделю до переезда) в DNS настраиваем, чтобы www2.host отзывался на новый ИПшник.
На старом сайте в htaccess прописываем редирект на www2.host
переключаем DNS.
Люди у которых DNS уже обновился — идут сразу на новый сервер, люди у которых DNS не обновился придут на старый, и их редиректнет на новый.
Гдето через неделю, как на старом сервере в access log перестанут появляться записи отключаем редирект. Все.
Сложный вариант — если в БД идет много записи — надо мудрить с бинлогами, чтобы получить БД без потерь, про это на хабре уже писали…
Плюс редирект через nginx хорошо сюда впишется, как Вы и писали
Простое решение:
Разворачиваем на новом сервере полную версию сайта с БД и кодом, у веб сервера настраиваем адрес host и алиас www2.host
Заранее(за неделю до переезда) в DNS настраиваем, чтобы www2.host отзывался на новый ИПшник.
На старом сайте в htaccess прописываем редирект на www2.host
переключаем DNS.
Люди у которых DNS уже обновился — идут сразу на новый сервер, люди у которых DNS не обновился придут на старый, и их редиректнет на новый.
Гдето через неделю, как на старом сервере в access log перестанут появляться записи отключаем редирект. Все.
Сложный вариант — если в БД идет много записи — надо мудрить с бинлогами, чтобы получить БД без потерь, про это на хабре уже писали…
Плюс редирект через nginx хорошо сюда впишется, как Вы и писали
Спасибо.
Хочется конфиг, который будет проксировать все домены, а не только явно указанные.
Про репликацию не понял тут.
Про репликацию не понял тут.
> люди у которых DNS не обновился придут на старый, и их редиректнет на новый.
www2.host они ещё ни разу не запрашивали — следовательно он будет запрошен с вашего ДНСа (и только после этого заботливо закеширован), разве не так?
www2.host они ещё ни разу не запрашивали — следовательно он будет запрошен с вашего ДНСа (и только после этого заботливо закеширован), разве не так?
Кстати финт с www2 мне нравится, но как на такое отреагируют поисковики?
вот что пишет про редиректы яндекс help.yandex.ru/webmaster/?id=1079306
т.е. 302 ставите, потом убираете. все чикипуки. вроде как.
т.е. 302 ставите, потом убираете. все чикипуки. вроде как.
По-моему, отвратительное решение. Если дело стоит только за тем, чтобы дождаться распространения DNS, то proxy_pass в помощь. wiki.nginx.org/HttpProxyModule
Пока вы этим скриптом будете переносить даные БД, потом пока остановите старый MySQL, потом пока настроите сайты ходить на новую машину… в старую БД будут все еще писаться данные, которые Вы, да, потеряете.
Скидывал БД в 500МБ в Великобританию — минут 5, стопим Mysql и поднимаем туннель — две команды.
Я не говорю, что мой вариант идеален. Написал сюда в поисках лучшего. Что предлагаете?
Я не говорю, что мой вариант идеален. Написал сюда в поисках лучшего. Что предлагаете?
Я бы использовал следующий алгоритм:
1. Заранее (зависит от текущего TTL) делаем маленький TTL (до часа)
2. Двусторонняя репликация базы.
3. rsync либо всего сразу либо посайтово
4. настраиваем прозрачное проксирование через nginx всех запросов со старого на новый сервер
5. еще раз rsync без удаления
6. меняем DNS
1. Заранее (зависит от текущего TTL) делаем маленький TTL (до часа)
2. Двусторонняя репликация базы.
3. rsync либо всего сразу либо посайтово
4. настраиваем прозрачное проксирование через nginx всех запросов со старого на новый сервер
5. еще раз rsync без удаления
6. меняем DNS
2. Репликация. Разве не нужно остановить сервер на запись во время дампа и разворачивания реплики?
4. Если делаем nginx проксю, зачем тогда заморочки с БД?
Что-то вы не то пишете!
А вот про ttl спасибо, не знал.
4. Если делаем nginx проксю, зачем тогда заморочки с БД?
Что-то вы не то пишете!
А вот про ttl спасибо, не знал.
2. Репликация позволяет не потерять данные, а во время снятия дампа будет лок, а не останов. При снятии дампа у вас будет master status, который даст возможность долить все транзации которые были после копирования дампа.
А в вашем случае ваши 500 МБ пока перельются у вас уже может миллион транзакций произойти.
4. вы же пафосно написали "без простоя и потери данных", вот для этого самого
а то что вы написали и с простоем и с потерей данных
или Вы потерю данных БД за 5,10,15 минут и т.д. потерей не считаете?
А в вашем случае ваши 500 МБ пока перельются у вас уже может миллион транзакций произойти.
4. вы же пафосно написали "без простоя и потери данных", вот для этого самого
а то что вы написали и с простоем и с потерей данных
или Вы потерю данных БД за 5,10,15 минут и т.д. потерей не считаете?
Да, есть пробел в моих знаниях по репликации. Но хочется как-то без репликации. Пробовал сделать одностороннюю репликацию, вроде что проще? но не завелась! Я так и не понял почему.
Slave_IO_Running Yes
Slave_SQL_Running Yes
И ничего не работает. Поэтому сразу слил это в «ненадежное»
Slave_IO_Running Yes
Slave_SQL_Running Yes
И ничего не работает. Поэтому сразу слил это в «ненадежное»
строил реплику мастер-мастер — работает на ура… правда если база большая и записей много — придется изрядно подождать синхронизации.
А если у вас база дампится час, копируется два часа и разворачивается из дампа полсуток?
В этом случае выход — только репликация.
Механизм довольно надежный, правда не без ограничений. Там не так все сложно, как кажется.
Надо просто разобраться, и хорошо понимать, что делаете.
Дамп, кстати, практически безболезненно снимается при помощи xtrabackup. Надо лишь чтобы MyISAM-таблиц не было в базе. Либо чтобы данных в них было немного,
В этом случае выход — только репликация.
Механизм довольно надежный, правда не без ограничений. Там не так все сложно, как кажется.
Надо просто разобраться, и хорошо понимать, что делаете.
Дамп, кстати, практически безболезненно снимается при помощи xtrabackup. Надо лишь чтобы MyISAM-таблиц не было в базе. Либо чтобы данных в них было немного,
Да вы, батенька, эстет :) «Отриньте же MyIsam как класс таблиц! Да пользуйтесь исключительно INNODB!!!!!»
Бред :)
Бред :)
Оговорку про MyISAM я указал для случая снятия дампа при помощи xtrabackup.
Никто не заставляет отказываться от MyISAM. Но если в MyISAM данных много — метод снятия дампа xtrabackup-ом не подходит, только и всего.
Никто не заставляет отказываться от MyISAM. Но если в MyISAM данных много — метод снятия дампа xtrabackup-ом не подходит, только и всего.
Так я ж и не против… :) Это такой тонкий троллинг!
Percona Xtrabackup, прекрасно дампит MyISAM, wrapper innobackupex. Так же есть параметры для сжатия и копирования дампа.
www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
для дампа мускуля для реплики я лично использую табле блок, сброс статуса мастера в какой-то файлик, потом тарю без сжатия каталоги бд и ни в коем случае не мускульдамп, потому как бд размером в 12-15Гб вырастает в размере архива в 2-3 раза, к тому же времени на подобный дамп уйдет туева хуча!
Апосля тара отпускаю лок, если нужен меньший размер для передачи — гзипаю тар отдельно, после «scp -c arcfour src dst» и вперед!
На приемнике стоп мускуль, антар бд, старт мускуль, чек таблиц, пут мастер позицию в настройки реплики, старт слейв реплика. Занавес :)
Апосля тара отпускаю лок, если нужен меньший размер для передачи — гзипаю тар отдельно, после «scp -c arcfour src dst» и вперед!
На приемнике стоп мускуль, антар бд, старт мускуль, чек таблиц, пут мастер позицию в настройки реплики, старт слейв реплика. Занавес :)
По поводу редактирования бинарников. Есть более изящный способ: packages.debian.org/ru/squeeze/socat
Создаст двухсторонний релей между unix и tcp сокетами.
su mysql -s /bin/sh -c 'umask 0000; socat UNIX-LISTEN:/var/run/mysqld/mysqld.sock,fork TCP4:localhost:3306'Создаст двухсторонний релей между unix и tcp сокетами.
В общем материал интересный, но с мускулем костыль ужасный…
Мускуль решать надо репликой:
На мастере ставим настройки для реплики, рестартуем сервер, дампим основной сервер со скидкой статуса мастера в куда-нить.
Разворачиваем удаленный мускуль и настраиваем реплику мастер-мастер.
Вот уже после этого можно править днс, а файлики рсинком можно таскать туда сюда хоть 2 недели к ряду, и закронить это дело с интервалом в 1 минуту.
Правда во всей этой чепухе есть одно но: оба сервера должны иметь доступ рута к себе :) иначе все это филькина грамота.
Мускуль решать надо репликой:
На мастере ставим настройки для реплики, рестартуем сервер, дампим основной сервер со скидкой статуса мастера в куда-нить.
Разворачиваем удаленный мускуль и настраиваем реплику мастер-мастер.
Вот уже после этого можно править днс, а файлики рсинком можно таскать туда сюда хоть 2 недели к ряду, и закронить это дело с интервалом в 1 минуту.
Правда во всей этой чепухе есть одно но: оба сервера должны иметь доступ рута к себе :) иначе все это филькина грамота.
p.s. Так же пришла в голову идея проксировать запросы с старого сервера на новый через nginx. Кто-нибудь делал так?
Я всегда так делаю. Если честно, то это первое что пришло мне в голову при переезде.
Причём это решение на порядок лучше, чем описанный автор адский костыль, да и настраивается элементарно :).
nginx не решает проблемы переноса БД
Тут тоже всё очевидно — если устраивает наличие существенного downtime, просто заливается дамп.
Если не устраивает — настраиваетя репликация, после завершения синхронизации сначала тушится мастер и потом включается перенаправление в nginx на новый сервер. В промежутке между выключением мастера и включением перенаправления все запросы будут потеряны, но такое переключение можно выполнить в течение нескольких секунд.
Вот и весь ваш топик :)).
Если не устраивает — настраиваетя репликация, после завершения синхронизации сначала тушится мастер и потом включается перенаправление в nginx на новый сервер. В промежутке между выключением мастера и включением перенаправления все запросы будут потеряны, но такое переключение можно выполнить в течение нескольких секунд.
Вот и весь ваш топик :)).
Уже выяснили, что репликация нужна мастер мастер, тогда нет потерь вообще. Читать надо было топик.
Вот у меня сейчас реальная ситуация, надо перенести пачку сайтов (45гиг) и небольшую бд к ним (30мб), но с устаревшего дистрибутива, с старой версией mysql, где нет nginx и прочих фитюлек.
Сколько потрачу времени на установку нужных сервисов? Чтобы репликация работала.., а еще там из мира только 80 порт доступен. Не проще ли мой костыль?
В реальных условиях рабочее решение — лучшее.
Сколько потрачу времени на установку нужных сервисов? Чтобы репликация работала.., а еще там из мира только 80 порт доступен. Не проще ли мой костыль?
В реальных условиях рабочее решение — лучшее.
Вы мастер-мастер репликацию хоть раз пробовали использовать-то :)? Master-master требует того, чтобы в разные мастеры не вставляли одновременно записи с теми же ключами (здравствуй, автоинкремент...), что требует значительной переделки скриптов. Остановка сервиса на несколько секунд — это при переезде не страшно. Даже downtime в 1 час ночью для большинства сайтов — это ок.
nginx не решает проблемы переноса БД
кстати, а что будет происходить с сайтом пока ты будешь разворачивать базу на новом сервере и включать коннект в базу через туннель?
Лучшим решением вижу сделать бд на read only сразу после снятия дампа, копируем бд, разворачиваем:
Выключаем бд, поднимаем туннель — несколько секунд.
Итого нет потерь, но некоторое время (минут 10 если бд не весит несколько гигабайт) сайты read only
Пока это лучшее быстрое решение, без заморочек репликации, настройки файрволов, софта и п.р. что смог придумать.
ls -l | awk '{print $9 " " $9}' | sed 's/\.sql\.gz$//' | awk '{print "zcat " $1 " | mysql -p -u root " $2}'
Выключаем бд, поднимаем туннель — несколько секунд.
Итого нет потерь, но некоторое время (минут 10 если бд не весит несколько гигабайт) сайты read only
Пока это лучшее быстрое решение, без заморочек репликации, настройки файрволов, софта и п.р. что смог придумать.
тогда скорее в ro перед снятием дампа, а не после.
я так понимаю вся идея заключается в ssh-туннеле на локальный порт, чтобы подменить локальную базу удаленной, а все остальное это танцы с бубном. но разве не нашлось более простого решения, чем грязно хачить бинарники?
я так понимаю вся идея заключается в ssh-туннеле на локальный порт, чтобы подменить локальную базу удаленной, а все остальное это танцы с бубном. но разве не нашлось более простого решения, чем грязно хачить бинарники?
Да, точно, сначала ro!
Да, это пока лучшее простое решение. Следующий вариант — это пересобрать mysql или вот как тут предлагают.
Да, это пока лучшее простое решение. Следующий вариант — это пересобрать mysql или вот как тут предлагают.
а кстати что на счет haproxy? если его поставить на локальный порт mysql-a и перенаправить на локальный порт туннеля, то может прокатить. но это надо проверить, потому что может возникнуть ситуация как с ssh, к сожалению, не знаю как там устроены сокеты. а пересобрать пакет с mysql по мойму не сложнее, чем ковырять бинарники.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перенос сайта(ов) без простоя и потери данных между выделенными серверами