|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день!
Есть следующая задача.
Несколько управляющих машин (УМ) черпают данные для своей работы (контроль доступа) из локальных (важна скорость SELECT'ов) MySQL баз. То есть, на каждой из машин установлен MySQL сервер. Данные в базы заносятся с администраторских рабочих мест находящихся где-то в локальной сети. Важно, чтобы все изменения в базах, отображались на всех управляющих машинах в течение единиц секунд, соответственно, асинхронная репликация не подходит.
Склоняюсь к решению с кластером, в который объединяются УМ, что гарантирует идентичность данных в системе во время нахождения всех нод кластера в режиме "онлайн". Однако, есть следующий тонкий момент. Что происходит с нодой кластера при выпадении ее из сети? То есть, важны две вещи:
1) Могу ли я продолжать работать с ней как со standalone сервером базы данных из приложения, запущеенного на том же hoste (только Select'ы).
2) Я так понимаю, что данные на ноде кэшируются в оперативной памяти. Как регулярно сбрасываются они на диск, ибо время работы сервера вне кластера может составлять продолжительное (несколько суток) время.
Заранее спасибо.
Неактивен
Сервер не будет работать вне кластера.
Чем Вас не устраивает обычная репликация?
Неактивен
paulus написал:
Сервер не будет работать вне кластера.
Именно в это я уже уперся. По идее, у него же имеется локальная копия всех таблиц, почему бы ему не продолжить работать с ними при обрыве связи с управляющей нодой? Или, стоит попробовать приделать к каждому из физических серверов по управляющей ноде?
Чем Вас не устраивает обычная репликация?
Мне нужно, чтобы при любом изменении данных, эти изменения отображались во всей системе в течении максимум 10 секунд. Стандартная репликация MySQL, как я понимаю, никакого гарантированного времени синхронизации всех слейвов с мастером не обеспечивает.
Да, у меня нагрузка на базу крайне асимметрична - запись производится минимум на пару порядков реже, чем селекты.
Неактивен
Управляющая нода Вам не поможет, основная задача кластера как раз не разделиться на несколько, что противоречит заявленной вами задачи. Прочитайте мою статью Повышенная доступность MySQL Cluster и алгоритм арбитража
Неактивен
