Дмитрий Исайкин @nikiasi
iOS-разработчик, серверный бэкенд-разработчик
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
iOS-разработчик, серверный бэкенд-разработчик
Как поступают неопытные тестировщики — они сразу пытаются ввести неправильный пароль.
Опытные же тестировщики сначала пытаются войти по правильному паролю.
Ну а во-вторых, еще необходима доработка на нашей стороне. Которую мы как раз уже сделали и в течение месяца постараемся выложить.
Дефолтным доменом для дким-подписи является mail.ru, вы совершенно правы.
В будущем для биз-доменов сделаем дефолтным какой-нибудь отличный от mail.ru домен.
Если репликация не пройдет, в синхронном случае клиенту вернется ошибка, а в асинхронном случае попытки синхронизации будут продолжаться до победного конца.
В текущей схеме все операции чтения идут на мастер, а реплика простаивает. Операции записи производятся и на мастере, и на реплике, просто на реплику они доезжают с задержкой.
В случае синхронной репликации чтение можно будет производить с любого сервера и нагрузка от чтения поделится между ними поровну. Запись будет по-прежнему производиться на обоих серверах, но уже синхронно. Это увеличит время, затрачиваемое на запись (из-за необходимости дожидаться, пока изменения доедут до второго сервера), но лишнюю нагрузку это создать не должно.
Получается, что нагрузка падает с (w + r) до (w + 0.5r) на первом сервере, и возрастает с (w) до (w + 0.5r) на втором. В целом максимальная нагрузка, которую сможет выдержать кластер, возрастает практически вдвое.
Если же хранилище практически write-only, то такая схема уже не работает. Это да. Ну так ее никто и не будет использовать для таких хранилищ.
В этом случае мы ответим клиенту, что не смогли применить изменения, хотя на самом деле их применили.
Вводя ограничения на время обработки команды, мы не избавляемся на сто процентов от подобных ситуаций, но сильно уменьшаем вероятность их возникновения.
По поводу синхронной мастер-мастер-репликации. Смысл подобной репликации в другом. Сейчас все запросы делаются в мастер (чтобы избежать рассогласованности данных). Даже на чтение. Синхронная репликация позволит делать запросы в любую из мастер-копий данных, выравнивая тем самым нагрузку на каждый из них. Т.к. разные мастера будут стоять в разных дата-центрах, то можно будет не ходить за данными за тридевять земель.
В случае поломки линка между ДЦ, не будут работать команды на модификацию, это правда. Но линки между ДЦ ломаются очень редко и за их здоровьем очень следят.
В случае сетевых или других проблем синхронизация может произойти позднее, но в конце концов обязательно происходит.