Итак, первый шаг для создания «горячей копии» виртуальной машины, физически расположенной на другом сервере — файловая синхронизация сделана (5 раз в сутки думаю достаточно) — см. предыдущий пост.
Второй шаг для достижения цели — онлайн репликация MYSQL баз данных.
(преследуемая цель: если первый сервер умирает — перебиваем IP в запасной виртуалке, выключаем slave в MYSQL и вуаля — с минимальными затратами во времени и без потерь поднимаем рабочий сервер).

Сразу оговорюсь, что физические сервера у меня находятся в одной физической сети — соответственно я назначил каждой виртуалке свой IP адрес сети класса С/24 192.168.100.ххх
Практически всю информацию для репликации я взял из статьи

НА МАСТЕРЕ добавляем в конфиг my.cnf секция mysqld и рестартим mysql

server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb

Далее, несколько запросов в БД (сбрасываем кэш, блокируем таблицы)
flush logs;
reset master;
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
show master status;
Бэкапим данные для переноса на слейв + переписываем название файла и циферку (то, что show master status выдал)
Разблокируем таблицы
SET GLOBAL read_only = OFF;
UNLOCK TABLES;

НА СЛЕЙВЕ правим конфиг и рестартим mysqld
server-id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

Выполняем MYSQL запросы (название файла и позицию берём из show master status на мастере)
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000003 «, MASTER_LOG_POS = 98;
start slave;

Проверяем как пошло
show slave status;

Лично у меня какие то дубликаты всплыли при первой синхронизации, что недавало дальше синхронизировать
для решения проблемы добавил slave-skip-errors = 1062 в конфиг

Если нужно заново стартануть — делаем всё тоже самое, но на слейве сначала нужно выполнить
stop slave;
flush logs;
CHANGE MASTER TO ….
start slave;

Проверим «руками» — правим значение в какой нить таблице на мастере, смотрим изменилось ли на слейве.

P.S.
Немного о ‘подводных’ камнях:
Настраивал на виртуалках с 2мя разными средами (FreeBSD, CentOS) — на каждой столкнулся с проблемой видимости порта 3306 извне, поэтому некоторые моменты:
* iptables
* для диагностики на мастере netstat -ln | grep mysql
* для диагностики со слейва на мастер telnet master 3306
* комментируем bind-address на мастере
* комментируем skip-networking на мастере
* ну и следим за синтаксисом, логинами и паролями 🙂 (ошибся в пароле в CHANGE MASTER TO … — долго парился пока заметил)

P.P.S
О контроле размера бинарных файлов тут http://forum.hostdvor.com/viewtopic.php?p=132
я поставил SET GLOBAL expire_logs_days =2

Итак, развивая поставленную перед собой задачу по созданию горячей резервной копии виртуальной машины я начал с файловой синхронизации.
Сначала решил задачу в лоб — ищем изменённые через find -mtime — пакуем, закидываем на фтп, в нужном месте разворачиваем.
Но, потом обратил внимание на специализированный для этих задач софт — утилита rsync.
На серверах с сайтами, для которых необходимы горячие резервные копии устанавливаем rsync в качестве демона через xinetd, не забыв поставить его в автозагрузку.
Настраиваем конфигурационные файлы, запускаем, проверяем слушает ли демон 873й порт ‘netstat -lnpt |grep 873‘
Вносим его в iptables (я делаю это интерактивно webmin-ом) — проверяем удалённо либо телнетом ‘telnet x.x.x.x 873‘, либо сразу запросив rsync-ом список ресурсов ‘rsync x.x.x.x::‘
Для настройки всего этого дела я использовал две отличные статьи
http://likeunix.ru/centos-rsync-backup/
http://www.stableit.ru/2010/04/rsync.html

Повторяться с настройками не буду, лишь хочу обратить внимание на некоторые настройки:
в настройки демона, файлы не подлежащие сжатию я добавил jpg картинки, т.к. они и так сжаты по формату
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.jpg *.JPG *.jpeg

в скрипте для исключения «мусора» использовал опции —exclude «*/temp/*» —exclude «*cache/*» —exclude «sess_*» —exclude «*.log» —exclude «*.gz» —exclude «*.zip»
для синхронизации удалённых файлов —delete —delete-after

Одной из целей преследуемых мной при установке в одном Дата Центре двух физических серверов с установленными на них ESXi — это быстрое копирование виртуальной машины с одного физического сервака на другой, с дальнейшей репликацией файлов и базы данных (пока не реализовано — мои записи о настройке такой задумки ещё впереди) для того, чтобы постоянно была актуальная копия виртуальной машины в рабочем состоянии на другом физическом сервере (ценность такой копии имхо трудно переоценить).
Собственно, сервера в ДЦ — гипервизоры работают, запускаю штатный конвертер для переноса ВМ (виртуальной машины) и ужасаюсь — скорость копирования в районе 1.5 мб/c! хотя физика 100 мегабитной сети позволяет гораздо больше!
Лечится это дело отключением шифрования ssl
Ищем файл converter-worker.xml тут
Windows 7, Windows Vista, Windows 2008 (R2) — C:\ProgramData\VMware\VMware vCenter Converter Standalone
Windows XP, Windows 2003, Windows 2000 — C:\Documents and Settings\All Users\Application Data\VMware\VMware vCenter Converter Standalone
В нём ищем параметр useSsl выставленный в true и меняем на false

120000
true