LINUX.ORG.RU
Форум — Admin  

[mysql] Кто как реализует репликацию и доступность mysql?

 , ,


0

1

Встала задача организовать неприрывную доступность MYSQL базы. Сразу же в голову лезут такие вещи как репликация, mysql + drbd. Как работает репликация мне известно, но вот никак не могу сообразить как лучше сделать в случае когда появляется необходимость положить один из хостов (банальный апдейт ядра например требует ребута) - в этом случае происходит рассинхронизация между master-slave (или даже master-master, читал и про такое) и для востановления репликации необходимо заново настраивать репликацию (указывать позиции бин логов, дампить базу, импортировать её заново на хост который потерял синхронизацию и тп).

Какую доку почитать бы на этот счет? Суть сводится к тому чтобы можно было безболезнено вырубать один из хостов с базой на неопределенный промежуток времени, при этом как-то организовывать прозрачный переход запросов на второй сервер с базой (скрипты общаются с базой по сети), а затем, после того как хост снова включается, на нем оказывалась актуальная версия базы (обращения на апдейты неприрывны) для того, чтобы можно было вновь сделать его мастером (опять же прозрачно).

Буду рад любым советам.

★★★
← Corosync или Heartbeat?
Нарисовать график загрузки интерфейса с усреднением ~1c →

Мутил я всякие репликации и master-master и master-slave.
У меня работает замечательно. Пара тройка дней офлайна - потом все поднимается без проблем и на одном и на другом сервере. Для master-master.
Дока почти любая в общем подходит.

gich
()

Используем встречную репликацию с разными server-id,auto_increment_offset и auto_increment_increment, при необходимости кладем хосты, проблем после поднятия не замечено. Ничего настраивать больше не надо - один раз настроил и все работает.

dgeliko ★★
()

для востановления репликации необходимо заново настраивать репликацию

Если мастер лег - слейвы пытаются восстановить с ним соединение (кол-во попыток и таймаут задается в конфиге). Когда мастер вернулся - продолжают где закончили. Если не продолжают(кол-во попыток превышено) - лечится комадной `slave start`.

Если выключаю slave - то он просто продолжает там где закочил когда возвращается в онлайн.

Версия сервера Percona-Server-server-55-5.5.17-rel22.1.196.rhel6.x86_64. До этого был mysql из стандартной поставки rhel5 - версия 5.0.45. Вел себя точно так же.

fjoe ★
()
Ответ на: комментарий от Shtsh

mysql-cluster по нашим тестам выдал низкую производительность, отказались от него.

dgeliko ★★
()
Ответ на: комментарий от dgeliko

То есть в Вашем случае это получается что-то вроди master-master репликация? Скажите, а как реализовано переключение между хостами в случае когда надо положить тот, к которому сейчас идут запросы? Все таки приходится тормозить на пару секунд процесс, который работает с базой, или есть какая-нибудь магия?

FreeBSD ★★★
() автор топика
Ответ на: комментарий от gich

Пара тройка дней офлайна - потом все поднимается без проблем и на одном и на другом сервере. Для master-master.

То есть живет и работает без всяких дампов и повторных указаний позиций бин-логов - подсасывает изменения накопившиеся даже за 3 дня?

FreeBSD ★★★
() автор топика
Ответ на: комментарий от FreeBSD

Верно. До недавнего времени для переключения юзали связку corosyn+openais в качестве стека, но, во вторник случилось аццоке восстание машин, которое принесло много миллионов убытков, поэтому выпиливаем его к ***ням и переходим на самописные скрипты. В случае, если необходимо было положить тот, который обрабатывает запросы - то при corosync мигрировали ресурсы, тут будут скрипты делать то же самое, т.е. по сути поднимать кластерный IP на одной машине и одновременно класть его на другой. Да, будет больше проблем, но они хотя бы будут из-за НАШИХ кривых рук, а не из-за того что лог у этого **ядского HA ПО кривой и по нему ничего не отследишь.

dgeliko ★★
()
Ответ на: комментарий от dgeliko

Ясно, спасибо за ответ. Так я и думал. И пост про востание читал =) В нашем случае правда используется еще и mysql-proxy, думаю с его помощью можно что-нибудь придумать, но одно ясно - минимального даунтайма не избежать по-любому.

FreeBSD ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Corosync или Heartbeat?
Admin
Нарисовать график загрузки интерфейса с усреднением ~1c →