Comments 20
А сие чудо (капрон) — это часть tarantool или существует в отдельном виде? Opensource? Хотелось-бы посмотреть на нее в контексте балансировки MySQL.
А как вы определяете доступность сервера?
Недостаток такой архитектуры — наличие единой точки отказа в виде лоад бэлэнсера, который у вас называется Капроном. Если упадет Капрон, упадет вся система. Вероятность, что упадет сервер с Капроном, грубо говоря, такая же, что и вероятность, что упадет один из слейвов. Или я не понял и у каждого веб сервера свой собственный Капрон?
Да, у каждого сервера запущен свой процесс Капрона. Это локальная прокся.
Тогда понятно.
А данные (каждого пользователя, например) хранятся всегда только на одном сервере или дублируются на N серверов для надёжности?
А данные (каждого пользователя, например) хранятся всегда только на одном сервере или дублируются на N серверов для надёжности?
Все данные дублируются минимум на двух серверах (мастер и реплика).
Если в результате какого-то сбоя данные на мастере будут отличаться от тех же данных на слейве, восстановление консистентности будет происходить в автоматическом режиме (и если да, то как?) или это надо будет делать вручную?
Синхронизация данных выполняется автоматически на стороне тарантула. Каждое состояние базы данных имеет свой числовой идентификатор. При изменении состояния идентификатор инкрементируется. На реплике крутится процесс синхронизации, который запрашивает и применяет к своей копии данных все изменения, произошедшие с мастером (изменения применяются последовательно, при этом наследуется идентификатор состояния).
В случае сетевых или других проблем синхронизация может произойти позднее, но в конце концов обязательно происходит.
В случае сетевых или других проблем синхронизация может произойти позднее, но в конце концов обязательно происходит.
Выставляем таймаут на обработку 1 секунду, а сетевой таймаут в Капроне — 2 секунды.
Что если мастер применит апдейт, но ответ веб-серверу дойдет позже, чем 2 секунды (лаг сети, gc)?
ждем от разработчиков Тарантула синхронную мастер-мастер-репликацию
Я правильно понял, что ответ веб-серверу не возвращается, пока изменение не применено на обоих мастерах? Тогда для отказа системы достаточно падения линка между мастерами. Как планируете обрабатывать такую ситуацию?
Что если мастер применит апдейт, но ответ веб-серверу дойдет позже, чем 2 секунды (лаг сети, gc)?
В этом случае мы ответим клиенту, что не смогли применить изменения, хотя на самом деле их применили.
Вводя ограничения на время обработки команды, мы не избавляемся на сто процентов от подобных ситуаций, но сильно уменьшаем вероятность их возникновения.
По поводу синхронной мастер-мастер-репликации. Смысл подобной репликации в другом. Сейчас все запросы делаются в мастер (чтобы избежать рассогласованности данных). Даже на чтение. Синхронная репликация позволит делать запросы в любую из мастер-копий данных, выравнивая тем самым нагрузку на каждый из них. Т.к. разные мастера будут стоять в разных дата-центрах, то можно будет не ходить за данными за тридевять земель.
В случае поломки линка между ДЦ, не будут работать команды на модификацию, это правда. Но линки между ДЦ ломаются очень редко и за их здоровьем очень следят.
Синхронная репликация позволит делать запросы в любую из мастер-копий данных, выравнивая тем самым нагрузку на каждый из них. Т.к. разные мастера будут стоять в разных дата-центрах, то можно будет не ходить за данными за тридевять земель.
Т.е. вы оптимизируете чтение (можно читать из ближайшего мастера) ценой удорожания записи — любая запись не быстрее, чем запись в дальний мастер, на самом деле еще медленее, ведь нужно сходить в ближайший мастер, оттуда во второй и потом весь путь обратно?
Не очень понял за счет чего уменьшается нагрузка, ведь каждая запись должна быть сделана в каждый мастер?
Если операций чтения сильно больше операций записи, оптимизация чтения за счет удорожания записи оправдана.
В текущей схеме все операции чтения идут на мастер, а реплика простаивает. Операции записи производятся и на мастере, и на реплике, просто на реплику они доезжают с задержкой.
В случае синхронной репликации чтение можно будет производить с любого сервера и нагрузка от чтения поделится между ними поровну. Запись будет по-прежнему производиться на обоих серверах, но уже синхронно. Это увеличит время, затрачиваемое на запись (из-за необходимости дожидаться, пока изменения доедут до второго сервера), но лишнюю нагрузку это создать не должно.
Получается, что нагрузка падает с (w + r) до (w + 0.5r) на первом сервере, и возрастает с (w) до (w + 0.5r) на втором. В целом максимальная нагрузка, которую сможет выдержать кластер, возрастает практически вдвое.
Если же хранилище практически write-only, то такая схема уже не работает. Это да. Ну так ее никто и не будет использовать для таких хранилищ.
В текущей схеме все операции чтения идут на мастер, а реплика простаивает. Операции записи производятся и на мастере, и на реплике, просто на реплику они доезжают с задержкой.
В случае синхронной репликации чтение можно будет производить с любого сервера и нагрузка от чтения поделится между ними поровну. Запись будет по-прежнему производиться на обоих серверах, но уже синхронно. Это увеличит время, затрачиваемое на запись (из-за необходимости дожидаться, пока изменения доедут до второго сервера), но лишнюю нагрузку это создать не должно.
Получается, что нагрузка падает с (w + r) до (w + 0.5r) на первом сервере, и возрастает с (w) до (w + 0.5r) на втором. В целом максимальная нагрузка, которую сможет выдержать кластер, возрастает практически вдвое.
Если же хранилище практически write-only, то такая схема уже не работает. Это да. Ну так ее никто и не будет использовать для таких хранилищ.
Хотел еще спросить в чем преимущество такой схемы перед синхронной мастер-слэйв репликации, но понял сам — можно ходить по более оптимальному маршруту для записи. Если до мастера А ближе, чем до В, мы идем С-А-В-А-С, где С — клиент кластера, вместо С-В-А-В-С, если бы В был единственным мастером.
А что происходит, ежели при записи на одну из реплик, по какой-либо из причин запись «не пройдет» (и в то же время, на мастере будет успешно выполнена)?
Клиент пишет только в один из серверов. Дальнейшей репликацией занимается сам Тарантул. В зависимости от политики (синхронная или асинхронная репликация) ответ на запрос клиент получит сразу или после успешной синхронизации мастеров.
Если репликация не пройдет, в синхронном случае клиенту вернется ошибка, а в асинхронном случае попытки синхронизации будут продолжаться до победного конца.
Если репликация не пройдет, в синхронном случае клиенту вернется ошибка, а в асинхронном случае попытки синхронизации будут продолжаться до победного конца.
Спасибо.
Получается, в асинхронном случае, возможно временная рассогласованность данных; когда мастер еще не успел перелить апдейты на реплики, однако сказал клиенту, что изменения сохранены, а потом «умер». Мы лезем на реплику и зачитываем еще не обновленные («старые») варианты данных, а клиент думает, что они уже обновлены. Или все-таки это не так критично в данном случае?
Получается, в асинхронном случае, возможно временная рассогласованность данных; когда мастер еще не успел перелить апдейты на реплики, однако сказал клиенту, что изменения сохранены, а потом «умер». Мы лезем на реплику и зачитываем еще не обновленные («старые») варианты данных, а клиент думает, что они уже обновлены. Или все-таки это не так критично в данном случае?
Sign up to leave a comment.
Fault tolerance: как предоставлять надежный сервис в случае сбоя оборудования