Чтобы добавлять сообщения и комментарии, .

@Balancer:
Balancer

Своеобразное первое крещение огнём. 6 дней назад отвалилась master-master MySQL репликация на вторичный сервер. Посколько он не используется, а я на выходных мотался на свадьбу к родственникам, то заметил это только вчера. Отставание от мастера превышало 400000+ секунд (5 суток), а время хранения бин-логов на сервере — 3 суток. Классическое решение в этом случае — mysqldump (или percona xtrabackup, что не сильно лучше и много сложнее) и возобновление репликации.

Поступил иначе. Возобновил репликацию с начала первого доступного файла бинлога, и провёл синхронизацию проблемных (по целостности внешних ключей) данных через pt-table-sync. Всё решилось онлайн, без простоев :)

@goodic:
goodic

есть мускул на Windows Server c кучей баз которые добавляются по мере работы (расширения системы). Есть желание реплецировать это дело для сохранности. Беглый гуглинг породил несколько вопросов:
— в винде бинарный лог мускулом ротируется?
— можно в настройках репликации не перечислять все базы, а указать что-то вроде all-databases?
— оно умеет не по IP машинки видеть, а по hostname или из DNS?

@Balancer:
Balancer

Как при репликации в MySQL может вылезать Duplicate entry ошибка на запрос REPLACE? Оно же, млин, по определению должно удалять нафиг старое значение, если таковое найдётся. Ничего не понимаю. Но синхронизация баз данных на этом каждые несколько часов обламывается и требует ручного разруливания.

@Balancer:
Balancer

Всем хороша двухсторонняя репликация на lsyncd. Только стоит отмонтировать один двусторонне реплицируемый каталог, как lsync считает, что все файлы были грохнуты и удалят их на реплике. Стоит вернуть монтирование, как реплика, увидев удаление у себя, удаляет файлы и на мастере. umount, mount... И два синхронизированных каталога пусты. Сейчас приходится восстанавливать данные по кусочкам из бэкапов. Дело осложняется тем, что сама система реплицирования задумывалась как основной бэкап, планировалось только к этому ещё ежесуточный unison прикрутить для версионного бэкапа. Не успел :)

@Balancer:
Balancer

Запустил на АвиаПорте master-master репликацию между основным и резервным сервером. Пока всё работает :)

А позавчера ещё запустил файловую двустороннюю синхронизацию через lsyncd. Не так оперативно работает, как через gluster, но зато читается на полной скорости.

@Balancer:
Balancer

Никогда, блин, при процессе безостановочного переноса живой БД с одного сервера на другой через репликацию не дропайте таблицу на мастере, предварительно не отключив репликацию :)

Итог — около получаса потерянных на форуме сообщений и час на восстановление из дампа при переносе…

@Balancer:
Balancer

«Seconds_Behind_Master: 1545832»
Нормально так. Интересно, за сколько нагонит? :)
И пора делать систему мониторинга, чтобы проверяла актуальность реплики.

@Balancer:
Balancer

На всякий случай делюсь граблями. Не используйте при репликации изменение имени БД (replicate-rewrite-db). MySQL не подменяет имя БД во многих запросах (я, например, наступил на грабли ALTER TABLE ... ADD CONSTRAINT REFERENCES `DB-NAME`.`TABLE-NAME` ...) — вот на этом REFERENCES слейв и вылетал. Учитывая 2Гб объём и то, что с целью экспериментов репликацию с нуля пришлось поднимать трижды, сегодня часа два убил, пока разобрался. Пришлось на реплике имя БД делать такое же, как на мастере. Сейчас поднимается в 4-й раз :)

@Balancer:
Balancer

Есть. Боевой mysql-5.1 реплицируется на бэкапный mysql-5.6 в LXC-контейнере. Теперь с последнего можно будет попробовать гнать отложенную репликацию домой, для бэкапа и разработки :) Правда я, кажется, перемудрил. mysql-5.6 достаточно было дома поставить, ибо параметр задержки репликации задаётся на слейве. Пойду, что ли, домашнюю машину обновлять…

@Balancer:
Balancer

Захотел в MySQL отложенную репликацию. Ткнулся в поиск. Есть такое! Хорошая новость. Но есть и плохая. Оно только в 5.6.2 появилось. А в Gentoo пока последняя версия (и то ~arch) — mysql-5.5.28

Наверное, буду думать на тему костылей.
~~~

@r00d1k:
r00d1k

странно, но репликация не отваливалась вот уже целые сутки.

@r00d1k:
r00d1k


INSERT INTO `stgetposition`(`id`,`rDateTime`,`unitId`,`pDateTime`,`longitude`,`latitude`,`speed`,`heading`,`altitude`,`satellite`,`reportId`,`inputs`,`outputs`,`peopIn`,`peopOut`,`run`) VALUES ( DEFAULT, NAME_CONST('rDT',_latin1'2009-11-03 10:16:41'), NAME_CONST('uid',_latin1'1010911781'), NAME_CONST('pDT',_latin1'20091103081440'), NAME_CONST('lon',_latin1'36.1751'), NAME_CONST('lat',_latin1'50.0069'), NAME_CONST('spd',17), NAME_CONST('head',209), NAME_CONST('alt',577), NAME_CONST('sat',8), NAME_CONST('rId',2), NAME_CONST('ins',31), NAME_CONST('outs',0), NAME_CONST('pIn',0.000), NAME_CONST('pOut',0.000), NAME_CONST('rn',0));
ERROR 1172 (42000): Result consisted of more than one row

ЛОЛШТО?

@r00d1k:
r00d1k

чувствую в будущем мне будут сниться кошмары в которых у меня конфигурация из 200-300 серверов бд на мухле в режиме мастер-масетр и отвалившейся репликацией на них.