Я бы сказал, что ваш реальный вопрос не в том, как справиться с репликацией, а в том, как справиться с масштабированием или, по крайней мере, масштабированием для возможности запроса. И хотя есть разные ответы на эту загадку, один ответ будет выделен: не с использованием репликации.
Проблема с репликацией, особенно с репликацией слиянием, заключается в том, что при записи записи умножается . Допустим, у вас есть система, которая обрабатывает загрузку 100 запросов (90 операций чтения и 10 операций записи) в секунду. Вы хотите масштабировать, и вы выбираете репликацию. Теперь у вас есть 2 системы, каждая из которых обрабатывает 50 запросов, 45 операций чтения и 5 операций записи каждая . Теперь эти записи должны быть реплицированы, поэтому фактическое количество записей составляет не 5 + 5, а 5 + 5 (оригинальные записи), а затем еще 5 + 5 (запись реплики), так что у вас есть 90 операций чтения и 20 операций записи. Таким образом, хотя нагрузка на каждую систему была снижена, соотношение операций записи и чтения увеличилось. Это не только меняет шаблоны ввода-вывода, но, что наиболее важно, меняет модель параллелизма нагрузки. Добавьте третью систему, и у вас будет 90 операций чтения и 30 операций записи и так далее, и так далее. Вскоре у вас будет больше записей, чем операций чтения, и задержка обновления репликации в сочетании с проблемами параллелизма и конфликтами слияний приведут к сбою в вашем проекте. Суть в том, что «скоро» гораздо раньше, чем вы ожидаете. Достаточно скоро, чтобы оправдать взор на увеличение масштаба, так как вы в любом случае говорите о масштабировании из 6-8 пиров в лучшем случае, а увеличение емкости в 6-8 раз при увеличении будет быстрее, намного проще и возможно даже дешевле начать с.
И имейте в виду, что все это просто чисто теоретические числа. На практике получается, что инфраструктура репликации не является бесплатной, она добавляет собственную нагрузку на систему. Записи должны быть отслежены, изменения должны быть прочитаны, должен существовать распространитель для хранения изменений, пока они не будут переданы подписчикам, затем изменения должны быть записаны и опосредованы для возможных конфликтов . Вот почему я видел очень мало развертываний, которые могли бы претендовать на успех при использовании стратегии масштабирования на основе репликации.
Одной из альтернатив является масштабирование только операций чтения, и здесь репликация работает , обычно с использованием репликации транзакций, но также и при доставке журналов или зеркалировании с помощью моментального снимка базы данных.
Реальная альтернатива - разбиение (т.е. разбиение). Запросы направляются в приложение на соответствующий раздел и попадают на сервер, содержащий соответствующие данные. Изменения в одном разделе, которые необходимо отразить в другом разделе, отправляются с помощью асинхронных (обычно основанных на обмене сообщениями) средств. Данные могут быть объединены только внутри раздела. Для более подробного обсуждения того, о чем я говорю, прочитайте как это делает MySpace . Излишне говорить, что такая стратегия оказывает большое влияние на дизайн приложения и не может быть просто вставлена после v1.