Плавный переезд

[juks]

Такой, что дамп её занимает 1.1G.

[borsh]

Это в архиве?

[agentru]

Скорее всего в архиве. Столько информации…

[zxmd]

Я бы спросил подругому — это с логами?

[juks]

Я бы сказал, что с индексами, конечно больше :-)

clyde# du -h ./superhabr
2.8G ./superhabr

InnoDb базы хранятся в отдельных файлах (innodb_file_per_table = 1)

[juks]

не базы, а таблицы я хотел сказать

[Aist]

Нет, это без архива :) Кстати, смена движка позволила сократить объем базы в 5 раз.

[onthefly]

А за счёт чего был получен столь существенный выигрыш в объёме?

[Aist]

За счёт оптимизации схемы хранения данных и отказа от второстепенных данных, которые сейчас стали не нужны.

[glader]

Скажите, у вас в базе много ненормальзованных полей? Или вы храните их только в кэше? Точнее даже очень интересует ответ на этот вопрос, если не затруднит.

[Aist]

Вопрос, как я понимаю звучит так: «где вы обычно храните вычисляемые (избыточные) данные»?
У нас довольно много избыточного хранится в БД. Так же много хранится в мемкеше. Данные, которые меняются не часто и обсчитываются сложно/долго хранятся в БД, а то что можно посчитать быстро, то храним в кеше.

[glader]

Понятно, спасибо.

[juks]

Перенесли только всё самое дорогое сердцу

[w0lf]

Если не секрет — почему именно mysqldump а не hot копирование?

[juks]

Потому что InnoDB

[glader]

На innodb только часть таблиц, или все?

[w0lf]

Понятно. Просто у меня на одном из проектов дамп незапакованной БД около 5 Гб (таблицы MyISAM), mysqldump делается слишком медленно…

[Joka]

переезжали практически аналогично — самый удобный способ как мне кажется

[mgyk]

Для переноса большой базы удобно использовать LVM снапшоты.
Все аналогично, только после того как посмотрели запись о позиции в мастер логе
Выполняем lvcreate -L1G -s -nbackup /dev/serv/mydb. У нас появляется снапшот-раздел /dev/serv/backup
Разлочиваем таблички. На создание снапшота и разлочку уходит пара секунд всего.
Далее, монтируем /dev/serv/backup и копируем фаилы на наш slave, находящийся на другом хостинге
Аналогично переключаем на нужную позицию в логе.

[juks]

Спасибо, надо будет изучить

[juks]

www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/

Прям будто я оттуда сдул :-)

[mgyk]

Вот даже какая-то обертка есть mylvmbackup

[juks]

Да, только если на сервере perl просто присутствует, придётся потратить некоторое время на настройку CPAN и установку модулей.

[Pilat]

Если пользоваться только пакетными менеджерами, то настройка софта сервера быстро делается. Для дебиана, например, достаточно сохранить список используемых репозиториев и список пакетов, возвращаемый dpkg --get-selections. Проблемы начинаются, когда используются машины разных архитектур, например i386 и AMD64, поэтому стоит заранее ориентироваться только на одну архитектуру.

[Pilat]

Я бы переезд запланировал ещё при создании системы. А именно все сервисы системы держал бы в контейнерах virtuozzo или openvz. Тогда переезд заключается в копировании контейнера на новое место, тестирование его, остановке старой копии, уточнение копии rsync'ом, замена на старой копии конфигурации nginx, поднятие конрейнера на новом месте, с новыми ip адресами, и запуск старого контейнера, теперь уже только ради одного проксирующего nginx. Перерыв в работе определяется размером модифицированных файлов, например базы данных, и в худшем случае определяется временем сравнения контрольных сумм всех файлов на обоих машинах — то что делает rsync, и что не всегда имеет смысл делать. Плюсы — отсутствие неожиданностей на новом железе, ненужность конфигурирования софта.

[juks]

Такой подход чем-то похож на вариант для владельца сайта радикально оппозиционной настроенности: постоянно на колёсах :-)

[vp7]

При использовании собственных серверов OpenVZ будет огромным плюсом (даже если на сервере всего одна виртуальная VZ машина) — он позволит практически мгновенно мигрировать контейнеры с одной машины на другую.

Простой пример — есть два сервера. Один — application, второй — БД.
Понадобилось на сервере с БД добавить оперативки и заменить жесткие диски на более ёмкие/быстрые/перейти на RAID,…

В схеме без виртуальных машин такой апгрейд будет означать либо временную недоступность сервиса (при замене винтов недоступность может измеряться часами), либо — достаточно сложные операции по переносу СУБД на другой сервер (установка софта, его настройка,...).
При использовании виртуальных машин можно временно мигрировать БД на application сервер (и времени понадобится ровно столько сколько нужно для копирования образа по сети), неторопять проапгрейдить сервер для БД а позже — сделать отдельную миграцию.

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

[leave]

Вот только непонятно, почему при таком способе миграции мусклевой базы дата рождения в 00 ноября превратилась :)

[mx2000]

А вот Xen… позволяет переносить VPS с хоста на хост без остановки сервисов VPS'а. Имхо, удобный вариант ;-)

[Pilat]

OpenVZ тоже позволяет, есть только одно НО: это в пределах одного адресного пространства.
И есть неожиданная засада — скопировать несколько гигабайтов можно быстро только в пределах одного датацентра, так что живая миграция — это средство для кластеров серверов, не для переездов в другой ДЦ.

[BAHO]

Пользуясь случаем, хочу передать привет НЛО и поблагодарить за добавление названия блога в заголовок RSS-экспорта.

[mgyk]

Миграция OpenVZ достаточно быстрая, хотя и не на столько как XEN. Сервисы останавливать не надо.
Из OpenVZ Wiki «… during migration the VE “freezes” for some time, and after migration it continues to work as though nothing had happened.»
Была ситуация, нужно было обновить одну машинку. На ней висело около 10 openvz контейнеров. Для интереса запустил пинг и смотрел сколько пакетов потеряется пока VPS переезжает, пропало что-то около 3-5 пакетов.

[Pilat]

На гигабитной сети скорость миграции — 40 секунд на гигабайт (25 мегабайт в секунду). Три гигабайта — это стандартный таймаут, как получается что пакеты не теряются?