@Multigame

Как организовать горячую замену базы для запросов с монопольным доступом?

Добрый день.

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

Первый вопрос про архитектуру. Хотелось организовать автоматическую быструю замену субд. Если по какой-то причине основной мастер выходит из строя, на его место автоматически встает второй, полноценный (чтение+запись). Т.е. получается необходимо организовать Мастер-Мастер репликацию. Мы посмотрели в сторону Percona XtraDB Cluster. Однако поверхностный поиск показал что это наложит ряд ограничений на выполняемые запросы и в целом схема получается не простой. Вопрос: оптимально ли такое решение для организации безотказной работы? или есть иные, более простые решения с мастер-слейв репликацией?

Второй вопрос, про допустимые запросы при такой (М-М) архитектуре. Интернеты пишут про две проблемы(которые вроде бы как даже перкона окончательно не решает), это рассинхронизация данных на серверах и невозможность использовать запросы вида select for update и в целом пользоваться локами. Учитывая что М-М всеж пользуются, то как-то такие атомарные операции как я описал выше исполняют при М-М репликации. Вопрос: как организовать защиту от двух описанных случаев (одновременная покупка(проверка баланса+списание средств) с него двумя нодами) и выборка на исполнение двумя нодами одной "записи-задачи" из субд.

Спасибо
  • Вопрос задан
  • 77 просмотров
Пригласить эксперта
Ответы на вопрос 1
Мастер-Мастер репликации потенциально может вызвать проблемы, которые будет сложно разгрести. Как минимум, хорошо бы гарантировать, что всегда будет идти запись в одну из нод кластера. Ну и в вашем случае не забывать про транзакции.
Кластер из 3-х нод отлично переживал убиение любых двух с последующим восстановлением без ручного вмешательства. Однако, я не вдавался в детали его конфигурации - полагаю все же там гарантировалась запись только на 1 ноде и переключение на другую ноду посредством keepalived. Отмечу, что у нас стояла задача выживаемости, а не высокой нагрузки и балансировки.

Более корректный ответ лучше услышать от DBA.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы