Комментарии 34
НЛО прилетело и опубликовало эту надпись здесь
Такой, что дамп её занимает 1.1G.
Это в архиве?
Скорее всего в архиве. Столько информации…
Я бы спросил подругому — это с логами?
Нет, это без архива :) Кстати, смена движка позволила сократить объем базы в 5 раз.
А за счёт чего был получен столь существенный выигрыш в объёме?
За счёт оптимизации схемы хранения данных и отказа от второстепенных данных, которые сейчас стали не нужны.
Скажите, у вас в базе много ненормальзованных полей? Или вы храните их только в кэше? Точнее даже очень интересует ответ на этот вопрос, если не затруднит.
Вопрос, как я понимаю звучит так: «где вы обычно храните вычисляемые (избыточные) данные»?
У нас довольно много избыточного хранится в БД. Так же много хранится в мемкеше. Данные, которые меняются не часто и обсчитываются сложно/долго хранятся в БД, а то что можно посчитать быстро, то храним в кеше.
У нас довольно много избыточного хранится в БД. Так же много хранится в мемкеше. Данные, которые меняются не часто и обсчитываются сложно/долго хранятся в БД, а то что можно посчитать быстро, то храним в кеше.
Перенесли только всё самое дорогое сердцу
Если не секрет — почему именно mysqldump а не hot копирование?
переезжали практически аналогично — самый удобный способ как мне кажется
Для переноса большой базы удобно использовать LVM снапшоты.
Все аналогично, только после того как посмотрели запись о позиции в мастер логе
Выполняем lvcreate -L1G -s -nbackup /dev/serv/mydb. У нас появляется снапшот-раздел /dev/serv/backup
Разлочиваем таблички. На создание снапшота и разлочку уходит пара секунд всего.
Далее, монтируем /dev/serv/backup и копируем фаилы на наш slave, находящийся на другом хостинге
Аналогично переключаем на нужную позицию в логе.
Все аналогично, только после того как посмотрели запись о позиции в мастер логе
Выполняем lvcreate -L1G -s -nbackup /dev/serv/mydb. У нас появляется снапшот-раздел /dev/serv/backup
Разлочиваем таблички. На создание снапшота и разлочку уходит пара секунд всего.
Далее, монтируем /dev/serv/backup и копируем фаилы на наш slave, находящийся на другом хостинге
Аналогично переключаем на нужную позицию в логе.
Спасибо, надо будет изучить
www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/
Прям будто я оттуда сдул :-)
Прям будто я оттуда сдул :-)
Вот даже какая-то обертка есть mylvmbackup
Да, только если на сервере perl просто присутствует, придётся потратить некоторое время на настройку CPAN и установку модулей.
Если пользоваться только пакетными менеджерами, то настройка софта сервера быстро делается. Для дебиана, например, достаточно сохранить список используемых репозиториев и список пакетов, возвращаемый dpkg --get-selections. Проблемы начинаются, когда используются машины разных архитектур, например i386 и AMD64, поэтому стоит заранее ориентироваться только на одну архитектуру.
Я бы переезд запланировал ещё при создании системы. А именно все сервисы системы держал бы в контейнерах virtuozzo или openvz. Тогда переезд заключается в копировании контейнера на новое место, тестирование его, остановке старой копии, уточнение копии rsync'ом, замена на старой копии конфигурации nginx, поднятие конрейнера на новом месте, с новыми ip адресами, и запуск старого контейнера, теперь уже только ради одного проксирующего nginx. Перерыв в работе определяется размером модифицированных файлов, например базы данных, и в худшем случае определяется временем сравнения контрольных сумм всех файлов на обоих машинах — то что делает rsync, и что не всегда имеет смысл делать. Плюсы — отсутствие неожиданностей на новом железе, ненужность конфигурирования софта.
Такой подход чем-то похож на вариант для владельца сайта радикально оппозиционной настроенности: постоянно на колёсах :-)
При использовании собственных серверов OpenVZ будет огромным плюсом (даже если на сервере всего одна виртуальная VZ машина) — он позволит практически мгновенно мигрировать контейнеры с одной машины на другую.
Простой пример — есть два сервера. Один — application, второй — БД.
Понадобилось на сервере с БД добавить оперативки и заменить жесткие диски на более ёмкие/быстрые/перейти на RAID,…
В схеме без виртуальных машин такой апгрейд будет означать либо временную недоступность сервиса (при замене винтов недоступность может измеряться часами), либо — достаточно сложные операции по переносу СУБД на другой сервер (установка софта, его настройка,...).
При использовании виртуальных машин можно временно мигрировать БД на application сервер (и времени понадобится ровно столько сколько нужно для копирования образа по сети), неторопять проапгрейдить сервер для БД а позже — сделать отдельную миграцию.
Причём некоторые решения позволяют делать live миграцию, когда прерывания сервиса как такового вообще не будет.
Простой пример — есть два сервера. Один — application, второй — БД.
Понадобилось на сервере с БД добавить оперативки и заменить жесткие диски на более ёмкие/быстрые/перейти на RAID,…
В схеме без виртуальных машин такой апгрейд будет означать либо временную недоступность сервиса (при замене винтов недоступность может измеряться часами), либо — достаточно сложные операции по переносу СУБД на другой сервер (установка софта, его настройка,...).
При использовании виртуальных машин можно временно мигрировать БД на application сервер (и времени понадобится ровно столько сколько нужно для копирования образа по сети), неторопять проапгрейдить сервер для БД а позже — сделать отдельную миграцию.
Причём некоторые решения позволяют делать live миграцию, когда прерывания сервиса как такового вообще не будет.
Вот только непонятно, почему при таком способе миграции мусклевой базы дата рождения в 00 ноября превратилась :)
А вот Xen… позволяет переносить VPS с хоста на хост без остановки сервисов VPS'а. Имхо, удобный вариант ;-)
Пользуясь случаем, хочу передать привет НЛО и поблагодарить за добавление названия блога в заголовок RSS-экспорта.
Миграция 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 пакетов.
Из 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 пакетов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Плавный переезд