Репликация данных: Master-Slave

Репликация означает хранение копий одних и тех же данных на нескольких машинах, подключенных через сеть. Репликация может быть синхронной или асинхронной .

Для очень больших наборов данных или очень высокой пропускной способности запросов, этого недостаточно, нам нужно разбить данные на разделы. Это также известно как

Преимущества

  • Сохраняет данные находятся географически близко к вашим пользователям, что снижает задержку доступа.

  • Позволяет системе продолжать работать, даже если некоторые из ее частей вышли из строя, тем самым повышая доступность.

  • Масштабирует количество машин, которые могут обслуживать запросы чтения, тем самым увеличивая пропускную способность чтения.

Имейте в виду

Если данные, которые вы реплицируете, не меняются с течением времени, то процесс репликации является одноразовым. Частое изменение данных — настоящая проблема; это требует тщательного обдумывания параллелизма и всех вещей, которые могут пойти не так, чтобы мы могли справиться с последствиями этих ошибок. Как минимум, нам нужно иметь дело с недоступными узлами, прерываниями сети и незаметным повреждением данных из-за ошибок приложения.

Вот следующие алгоритмы для репликации изменений между узлами:

  • Репликация главный-подчиненный (простая)

  • Репликация с несколькими лидерами (более устойчивая)

  • Репликация без лидера

Репликация главный-подчиненный

Когда клиент хочет для чтения из базы данных он может запрашивать либо ведущее, либо любое из ведомых устройств. Однако записи принимаются только на мастере. Часто репликация на основе лидера конфигурируется как полностью асинхронная. В этом случае, если ведущее устройство выходит из строя и не подлежит восстановлению, любые записи, которые еще не были реплицированы на ведомые устройства, теряются. Это означает, что длительность записи не гарантируется. Снижение устойчивости — плохой компромисс.

Как мы можем придумать методы репликации, которые не теряют данные, но при этом обеспечивают хорошую производительность и доступность?

Обработка сбоев подчиненного узла

Любой узел в системе может выйти из строя из-за ошибки или перезагрузки в целях обслуживания. На своем локальном диске каждое ведомое устройство ведет журнал репликации изменений данных, полученных от ведущего устройства. Если ведомое устройство выходит из строя или перезапускается, оно может восстановиться из своего локального журнала, поскольку ему известна последняя транзакция, которая была обработана перед завершением работы. Как только ведомое устройство включено, оно подключается к ведущему и синхронизирует его там, где оно было отключено.

Обработка сбоев главного узла

Ошибка обработки главного узла — это сложнее. Теперь нам нужно обновить самое обновленное ведомое устройство в качестве нового ведущего и перенастроить логику для записи запросов на новый главный узел..

В случае полусинхронной репликации, мы делаем синхронное ведомое устройство новым ведущим, поскольку знаем, что он является наиболее обновленным и никакие данные не будут потеряны.

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

Общие сведения о журнале репликации: репликация на основе операторов

В простейшем случае лидер регистрирует каждый запрос записи ( оператор), который он выполняет, и отправляет этот журнал операторов своим последователям. Это означает, что для реляционной базы данных каждый оператор INSERT, UPDATE или DELETE пересылается последователям. Затем каждый последователь анализирует и выполняет этот оператор SQL, как если бы он был получен от клиента. На что следует обратить внимание:

Любой оператор, вызывающий недетерминированную функцию, например NOW () , для получения текущей даты и времени. или RAND () для получения случайного числа, скорее всего, для каждой реплики будет сгенерировано другое значение. Решение состоит в том, чтобы лидер заменил любые недетерминированные вызовы функций фиксированным возвращаемым значением, когда оператор регистрируется, чтобы все последователи получали одно и то же значение.

Использование в лучшем случае

Этот тип репликации требует, чтобы все операции записи выполнялись через один главный узел, но запросы только для чтения могут поступать на любые реплики. Для рабочих нагрузок, которые состоят в основном из чтения и лишь небольшого процента операций записи (распространенный шаблон в Интернете), есть привлекательный вариант создания множества последователей и распределения запросов на чтение между этими подписчиками. Это снимает нагрузку с лидера и позволяет запросам чтения обслуживаться ближайшими репликами.

Распространенные проблемы при использовании асинхронной репликации главного подчиненного устройства

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

  • Если пользователь попытается прочитать данные сразу после выполнения записи , возможно, новые данные еще не достигли реплики. Однако для пользователя это будет выглядеть так, как будто отправленные данные были утеряны.

Решение: при чтении чего-то, что пользователь, возможно, модифицировал, прочтите это у лидера; в противном случае прочтите это у подписчика. Это требует, чтобы у вас был способ узнать, было ли что-то изменено, не запрашивая его. Например, информацию профиля пользователя в социальной сети обычно может редактировать только владелец профиля, а не кто-либо другой.. Таким образом, простое правило — всегда читать собственный профиль пользователя у лидера и читать профили других пользователей у фолловера.

Минусы: это увеличивает нагрузку на главный узел

Многолидерная репликация

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

Стандартный шаблон распределения/миграции данных

  • Bi -направление : экземпляр отчета

  • Одностороннее : мгновенное переключение при отказе (репликация с несколькими лидерами)

  • Одноранговое соединение : балансировка нагрузки (высокая доступность)

  • Broadcast : широкое распространение данных на несколько экземпляров

  • Консолидация : хранилище данных (хранилище данных)

Оцените статью
nanomode.ru
Добавить комментарий