Как организовать горячую замену базы для запросов с монопольным доступом?
Добрый день.
Сейчас возникла необходимость спроектировать сервис с достаточно высокой отказоустойчивостью и возник вопрос как работать с базой данных. В сервисе есть данные которые должны быть защищены от одновременного редактирования (например счет виртуальных денег в онлайн игре, нельзя допустить что-бы с него одновременно списали деньги за две покупки) и есть данные, скажем очередь задач по выдаче наград за ивент, нельзя что бы награду выдали дважды (в случае если две ноды одновременно вынут из базы и начнут исполнять эту задачу).
Первый вопрос про архитектуру. Хотелось организовать автоматическую быструю замену субд. Если по какой-то причине основной мастер выходит из строя, на его место автоматически встает второй, полноценный (чтение+запись). Т.е. получается необходимо организовать Мастер-Мастер репликацию. Мы посмотрели в сторону Percona XtraDB Cluster. Однако поверхностный поиск показал что это наложит ряд ограничений на выполняемые запросы и в целом схема получается не простой. Вопрос: оптимально ли такое решение для организации безотказной работы? или есть иные, более простые решения с мастер-слейв репликацией?
Второй вопрос, про допустимые запросы при такой (М-М) архитектуре. Интернеты пишут про две проблемы(которые вроде бы как даже перкона окончательно не решает), это рассинхронизация данных на серверах и невозможность использовать запросы вида select for update и в целом пользоваться локами. Учитывая что М-М всеж пользуются, то как-то такие атомарные операции как я описал выше исполняют при М-М репликации. Вопрос: как организовать защиту от двух описанных случаев (одновременная покупка(проверка баланса+списание средств) с него двумя нодами) и выборка на исполнение двумя нодами одной "записи-задачи" из субд.
Мастер-Мастер репликации потенциально может вызвать проблемы, которые будет сложно разгрести. Как минимум, хорошо бы гарантировать, что всегда будет идти запись в одну из нод кластера. Ну и в вашем случае не забывать про транзакции.
Кластер из 3-х нод отлично переживал убиение любых двух с последующим восстановлением без ручного вмешательства. Однако, я не вдавался в детали его конфигурации - полагаю все же там гарантировалась запись только на 1 ноде и переключение на другую ноду посредством keepalived. Отмечу, что у нас стояла задача выживаемости, а не высокой нагрузки и балансировки.
Дмитрий Шицков, А эффект "отставания" при переключении наблюдался? или galera и её форки решают всеж эту проблему в достаточной степени?
Исходя из логики просто если у нас запись идет на А, а Б в резерве, то в момент когда А упал и арбитр(в схеме с 2мя М-серверами) не все данные могут быть переданы на Б. Опять же интернеты говорят что Галера как-то притормаживает А, и следит за реалтайм соответствием Б... Интересно насколько в реальности это работает или частичная потеря данных при переключении возможна...
Multigame, частичной потери данных не исключить - отставание конечно будет и при падении текущего основного сервера часть данных может быть потерена. Однако, после восстановления работоспособности упавшей ноды должна произойти синхронизация. За этим перконовский кластер следит.
Рекомендую провести ресерч с испытаниями интересующих вас кейсов.
