Расскажите о способе репликации

последовательность

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

replication

Репликация и разделение/шардинг — две необходимые возможности для распределенных систем. Подробнее см.Репликация, сегментирование и маршрутизация.
Для массивных данных, с одной стороны, репликация может повысить избыточность и обеспечить доступность системы, а с другой — повысить эффективность чтения.
В этой статье основное внимание уделяется репликации, которая предполагает, что каждый узел достаточно велик для хранения всей реплики.

replication type

В зависимости от того, есть лидер или нет, и количества лидеров, его можно разделить на:

• single leader replication
  То есть метод репликации одного мастера и нескольких слейвов, ведущий синхронизирует/уведомляет ведомого, только ведущий может принять операцию записи, а ведомый может только читать, но не писать.

• multi leader replication
  То есть несколько мастеров и несколько слейвов, есть несколько лидеров, распределенных по разным узлам, одновременно принимающих операции записи, и каждый лидер является последователем друг друга. Он больше подходит для сценариев с несколькими центрами обработки данных, но также возрастает сложность разрешения конфликтов при одновременной записи в несколько центров обработки данных.

• leaderless replication
  Бесцентровая репликация не различает главные и подчиненные реплики, любой узел может получать запросы, а затем уведомляет другие реплики об обновлении.

leader-based replication way

Подробнее см.Копировать стратегию обновления, в основном следующим образом

• sync replication
  Синхронная репликация, это может обеспечить сильную согласованность, но в случае многих последователей задержка слишком велика, как правило, редко используется
• async replication
  Асинхронная репликация, которая может вызвать несогласованность чтения, но высокую эффективность записи.
• semi sync replication
  Полусинхронизация обычно использует механизм кворума, то есть когда количество записываемых узлов удовлетворяет заданным условиям, запись выполняется успешно, а затем обеспечивается согласованность чтения за счет одновременного запроса нескольких узлов.

leaderless replication way

Бесцентровую репликацию можно разделить на три топологии: кольцевая, звезда/дерево и ячеистая топология.

replication implementation

В основном делятся на следующие

• statement/trigger-based replication
  Этот тип репликации реализуется на основе операторов базы данных или триггеров, но есть определенные проблемы.Например, некоторые функции, такие как now()/rand()/seq(), могут вызывать неопределенность синхронизации master-slave, например ведомый узел. Результаты выполнения now()/rand() отличаются от результатов ведущего узла. Это использовалось до версии mysql5.1.В версии 5.1+, когда есть неопределенный оператор, он переключается на репликацию журнала на основе строк.

• write-ahead-log replication(WAL)
  WAL — это эффективный алгоритм ведения журналов в базах данных.Для баз данных без памяти дисковые операции ввода-вывода являются основным узким местом в эффективности базы данных. При том же объеме данных операция записи на диск системы базы данных с использованием журнала WAL составляет примерно половину от операции записи в традиционном журнале отката, когда транзакция зафиксирована, что значительно повышает эффективность операции ввода-вывода на диск базы данных. тем самым повышая производительность базы данных.
  Это то, что использует PG.

• row-based-log replication(logical log)
  WAL связан с механизмом хранения базы данных, а журнал на основе строк также называется логическим журналом, который не зависит от механизма хранения.Он использует метод захвата измененных данных, что очень удобно для синхронизации данных из разнородных источников данных.

Проблемы, вызванные репликацией

replication lag

• большая разница в синхронизации
  Например, oplog mongo слишком мал, чтобы поддерживать скорость записи, в результате чего старый журнал операций отбрасывается, а задержка master-slave продолжает увеличиваться, что приводит к сбою синхронизации реплик.
• Синхронизация вновь добавленных узлов
  Например, онлайн-расширение увеличивает репликацию. В настоящее время это связано с проблемой репликации узла нового узла. Как правило, этот метод синхронизации отличается от метода синхронизации обычных сетевых узлов. Новый узел синхронизируется с определенное время, прежде чем он станет обычным приращением.

master slave failover

Как правило, репликация увеличивает избыточность и часто используется для горячего резерва (поддерживает запросы)/теплого резерва (не поддерживает запросы).

• Когда основной узел зависает, на этот раз возникает вопрос, какую репликацию выбрать в качестве основного.

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

  read consistency

  Как только репликация поддерживает чтение, она включает в себя непротиворечивость чтения.Как правило, теоретически помимо строгой согласованности существуют следующие виды окончательной согласованности:

• (1) Причинно-следственная связь
  То есть процесс A уведомляет процесс B после обновления данных, тогда диапазон данных процесса B является последним значением после обновления процесса A.

• (2) Прочитайте свои записи
  После того как процесс А обновит часть данных, он всегда может получить доступ к последнему обновленному значению.
• (3) Согласованность сеанса
  Непротиворечивость данных создается в сеансе, а согласованность чтения и записи реализуется в сеансе. То есть после выполнения обновления клиент всегда может прочитать последнее значение данных в том же сеансе.
• (4) Консистенция монотонного чтения
  Если процесс считывает значение элемента данных из системы, система не должна возвращать более старое значение при любом последующем доступе процесса к данным.
• (5) Консистенция монотонной записи
  Система должна гарантировать, что записи из одного и того же процесса выполняются последовательно.

Если вы читаете, это включает в себя чтение того, что вы написали, каузальное чтение (针对操作有序), монотонное чтение (不读到旧数据)

Решение Quorum/RWN для разрешения конфликтов чтения

write quorum

Предполагая, что определенный фрагмент данных необходимо реплицировать на 3 узла, для обеспечения сильной консистентности необязательно, чтобы все узлы подтверждали операцию записи, только два из них (то есть более половины узлов) требуются для подтверждения. В этом случае, если происходят две конфликтующие операции записи, только одна из операций может быть распознана более чем половиной узлов, что является кворумом записи.Если выразить это чуть более формально, то это W>N/ 2. Это неравенство означает, что количество узлов W, участвующих в операции записи, должно превышать половину числа узлов реплики N. Число узлов реплики также называют коэффициентом репликации.

read quorum

Кворум чтения означает, сколько узлов необходимо установить, чтобы гарантировать, что последние данные могут быть прочитаны. Предполагая, что операция записи требует подтверждения двумя узлами (W=2), мы должны связаться по крайней мере с двумя узлами, чтобы убедиться, что получены самые последние данные. Однако если некоторые операции записи подтверждаются только одним узлом (W=1), то мы должны взаимодействовать со всеми тремя узлами, чтобы убедиться, что полученные данные актуальны. В одном случае может возникнуть конфликт обновления, потому что операция записи не имеет достаточной поддержки узлов. Однако, пока данные считываются с достаточного количества узлов, такие конфликты могут быть обнаружены. Следовательно, даже в случае, когда операция записи не имеет строгой согласованности, можно реализовать операцию чтения со строгой согласованностью.

RWN

• R
  Количество узлов R для связи при выполнении операции чтения
• W
  Количество узлов, с которыми следует консультироваться при подтверждении операции записи, W
• N
  фактор репликации N

Отношения между этими тремя могут быть выражены неравенством, то есть только когда R+W>N может быть гарантирована строгая согласованность операций чтения.

Обзор репликации основных продуктов с открытым исходным кодом

продукт	Метод копирования	Метод реализации	разное
mysql	Полусинхронизация Master-Slave	MySQL 5.0 и более ранние версии поддерживают только репликацию на основе операторов, а версия 5.1+ переключается на репликацию журнала на основе строк при наличии неопределенных операторов.	Обработка задержки Master-Slave
kafka	Полусинхронизация ISR Master-Slave	Лидер пишет сообщение и реплицирует его всем подписчикам, копия в ISR успешно записывается и возвращает подтверждение лидеру, что считается успешной фиксацией.	Производитель может выбрать, ждать ли подтверждения от ISR.
elasticsearch	Полусинхронизация ведущий-ведомый, репликация по умолчанию = синхронизация	Необязательные значения согласованности — кворум, один и все. Значение по умолчанию — кворум.	tradelog и fsync и обновление
pg	Асинхронная репликация master-slave	На основе журнала упреждающей записи	архивные и потоковые методы
redis	Асинхронная репликация master-slave	Инкрементный протокол Redis (полное\инкрементное\длинное соединение)	Sentinel failover
mongo	Асинхронный ведущий-ведомый, режим набора реплик	Постоянный кольцевой буфер local.oplog.rs(initial_sync, устойчивая синхронизация)	Арбитр выбран

Видно, что при некоторых высоких требованиях к согласованности может использоваться механизм полусинхронизации, обычно основанный на механизме кворума, например, es основан на этом механизме, а kafka основан на механизме ISR, оба могут быть настроены
Другие представляют собой в основном асинхронную репликацию.Для синхронизации вновь добавленных узлов и узлов восстановления используются разные методы синхронизации.Вновь добавленные узлы обычно используют полную синхронизацию, а узлы в нормальном состоянии обычно используют добавочную синхронизацию.

ISR Кафки (англ.In-Sync Replicas的缩写，表示副本同步队列)

Все реплики вместе называются назначенными репликами или AR. ISR является подмножеством AR. Лидер ведет список ISR. У ведомого есть некоторая задержка в синхронизации данных от ведущего. Если какой-либо из них превышает пороговое значение, ведомый будет удален из ISR и сохранен в OSR (Outof-Sync Replicas) Список вновь добавленных последователей Он также будет сначала сохранен в OSR. АР=ИСР+ОСР.

Когда производитель отправляет сообщение брокеру, лидер записывает сообщение и реплицирует его всем последователям. После фиксации сообщения оно успешно реплицируется на все синхронизированные реплики. Задержка репликации сообщения ограничена самым медленным последователем, важно быстро обнаруживать медленные реплики, если повторитель слишком сильно «запаздывает» или выходит из строя, лидер удалит его из ISR.

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

es согласованность реплик

Непротиворечивость es в основном имеет два аспекта:

• Проблема обновления, вызванная использованием механизма индексации lucene
  

  

  
  Между Elasticsearch и диском находится кеш файловой системы. Документ в индексном буфере в памяти будет записан в новый сегмент, но здесь новый сегмент будет сначала записан в кэш файловой системы — этот шаг менее затратный, а позже сброшен на диск — этот шаг является дорогостоящим. Однако, пока файл уже находится в кэше, его можно открыть и прочитать, как и любой другой файл.

  В Elasticsearch упрощенный процесс записи и открытия нового сегмента называется обновлением. По умолчанию каждый сегмент автоматически обновляется каждую секунду. Вот почему мы говорим, что Elasticsearch близок к поиску в реальном времени: изменения в документах не сразу становятся видимыми для поиска, а становятся видимыми в течение секунды.
  Такое поведение может сбивать с толку новых пользователей: они индексируют документ и пытаются найти его, но не находят. Решение этой проблемы — выполнить обновление вручную с помощью API обновления.
  refresh_interval может динамически обновляться в существующем индексе. В производственной среде при создании большого нового индекса можно сначала отключить автоматическое обновление, а затем снова включить их, когда вы начнете использовать индекс.

• Проблемы согласованности реплик (согласованность: один, все, кворум), вызванные использованием сегментирования и репликации
  В случае конфигурации реплики данные отправляются с узла Elasticsearch в ответ от узла Elasticsearch, и поток выглядит следующим образом.
  

  

• 1) Запрос клиента отправляется на узел Node1, который также может быть отправлен на другие узлы здесь
• 2) Узел Node1 использует _id данных, чтобы вычислить, что данные должны храниться на shard0.С помощью информации о состоянии кластера выясняется, что первичный сегмент shard0 находится на узле Node3.Node1 пересылает данные запроса на Node3. , а Node3 завершает индексирование данных. Процесс индексирования описан выше Подробности в этом сообщении блога.
• 3) Node3 пересылает данные параллельно осколкам реплик Node1 и Node2, выделенным с помощью shard0. После получения отчета от любого узла об успешной записи данных сегмента реплики узел Node3 возвращается к начальному принимающему узлу Node1, чтобы объявить об успешной записи данных. Node1 успешно возвращается к клиенту.

резюме

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

doc

• Углубленная интерпретация надежности данных kafka
• RWN и Quorum и сильная согласованность
• проблема согласованности
• процесс написания
• Примечания к исследованию Elasticsearch (3) Процесс чтения и записи операций сегментирования кластера Elasticsearch
• Полное руководство по ElasticSearch — внутреннее устройство шардинга