Понимание многолинейной репликации для распределенных данных

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

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

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

Примеры использования

Репликация данных с несколькими лидерами может использоваться, среди прочего, для периферийных вычислений, мультитенантных платформ SaaS и приложений с интенсивным объемом записи с распределенными пользователями. Давайте посмотрим поближе:

Периферийные вычисления

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

Мультитенантные SaaS-платформы

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

Приложения с интенсивным использованием записи и распределенными пользователями

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

Зачем использовать многолидерную репликацию?

В этой статье основное внимание уделяется поддержке архитектур с несколькими центрами обработки данных. Поддержка таких архитектур посредством многолидерной репликации основана на следующем:

Как избежать единых точек отказа

Традиционная банковская система с единой центральной базой данных уязвима к единичным сбоям. Если основная база данных выйдет из строя, вся система станет недоступной. Благодаря использованию репликации с несколькими лидерами, если в одном центре обработки данных произойдет сбой, другие центры обработки данных все равно смогут обрабатывать транзакции. Таким образом, такие услуги, как онлайн-банкинг, могут оставаться доступными для клиентов.

Изоляция рабочей нагрузки

Каждый центр обработки данных может выполнять свои операции независимо, не завися от других центров обработки данных в каждой транзакции. Благодаря локальной обработке запросов снижается необходимость взаимодействия с удаленными центрами обработки данных для каждой операции чтения или записи. Это минимизирует задержку и повышает производительность. Проблемы в одном центре обработки данных, такие как сбои оборудования или сбои в локальной сети, не влияют немедленно на функциональность других. Рассмотрим, например, случай локальной записи. Системы с несколькими лидерами позволяют каждому центру обработки данных выступать в качестве ведущего узла. Это означает, что локальные клиенты (пользователи) могут писать напрямую в ближайший центр обработки данных. Это значительно снижает задержку записи, поскольку данным не приходится преодолевать большие географические расстояния, прежде чем они будут подтверждены. Проще говоря, когда пользователи разбросаны по разным регионам, наличие нескольких лидеров в разных местах гарантирует, что данные будут ближе к пользователям. Это сокращает время, необходимое для передачи данных между пользователем и сервером.

Синхронизация между центрами обработки данных

Изменения, внесенные в один центр обработки данных, асинхронно распространяются на другие центры обработки данных. Таким образом можно реализовать различные модели согласованности в системе. Хотя записи обрабатываются локально, глобальная синхронизация гарантирует, что все центры обработки данных со временем придут в одно и то же состояние.

Масштабируемость

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

Топологии многолидерной репликации

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

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

Также стоит отметить, что коммерческие базы данных могут использовать гибридные топологии, сочетая аспекты каждой топологии и балансируя компромиссы. Однако для пояснения основных понятий классификация в Таблице 1 основана на трех основных топологиях.

Таблица 1. Сравнение топологии репликации с несколькими лидерами

Топология «все-всем» (Full-Mesh)

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

Плюсы

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

- Низкая задержка распространения: обновления, сделанные на любом узле, отправляются на все остальные узлы по прямым ссылкам. Эта прямая связь исключает промежуточные узлы, обеспечивая быструю синхронизацию данных.

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

Минусы

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

- Сложность связи: для n узлов каждый узел должен поддерживать n-1 прямых соединений с другими узлами. Общее количество соединений в сети упрощается до O(n²). По мере увеличения количества узлов дополнительная сложность может не оправдать ожидаемый выигрыш. Это связано с тем, что большее количество узлов увеличивает вычислительную нагрузку на отдельные узлы. Это особенно верно, поскольку механизмы разрешения конфликтов и согласованности масштабируются с увеличением количества соединений. Кроме того, поскольку в прямой связи участвует больше узлов, конкуренция за сетевые ресурсы и увеличение накладных расходов на управление соединениями могут привести к замедлению времени ответа и снижению пропускной способности.

- Сложность безопасности и уязвимостей. Чем больше подключений, тем сложнее требования к аутентификации, шифрованию и безопасности. Увеличивается поверхность атаки для потенциальных уязвимостей безопасности. Это может привести к увеличению сложности реализации безопасных каналов связи между узлами.

Круговая топология (кольцо)

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

Плюсы

- Простота подключения: каждый узел подключен только к двум соседним узлам. Это сводит к минимуму сложность подключения. В отличие от ячеистых топологий, где каждому узлу может потребоваться поддерживать множество соединений, кольцевая топология снижает накладные расходы на управление соединениями. Одним из потенциальных преимуществ является снижение потребления ресурсов. Эта настройка полезна для систем, в которых предпочтение отдается минимальному подключению, чтобы снизить нагрузку на ресурсы.

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

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

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

Минусы

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

- Зависимость от одного узла: весь поток данных прерывается, если один узел выходит из строя в однонаправленном кольце. Конфигурация двунаправленного кольца помогает снизить этот риск, но добавляет сложности. В однонаправленном кольце каждый узел полностью зависит от своих соседей в вопросах связи и репликации данных. Единственная точка отказа может полностью остановить поток данных, нарушив работу. Эта уязвимость делает кольцевые топологии менее надежными для приложений, которым требуется высокая доступность и отказоустойчивость.

- Петли репликации. В двунаправленных кольцах или системах с плохо управляемым контролем репликации данные могут циркулировать в петлях. Это приводит к избыточной передаче данных и дополнительной задержке. Циклы репликации создают ненужный сетевой трафик и потребляют полосу пропускания, не обеспечивая при этом дополнительную согласованность данных. Для предотвращения этой проблемы необходимы механизмы тщательного контроля. Такие циклы могут увеличить нагрузку на администраторов по настройке и мониторингу.

- Сложное восстановление после сбоя узла. При выходе узла из строя его реинтеграция или добавление нового узла взамен может быть сложной задачей, часто требующей существенной реконфигурации. Это связано с тем, что пути передачи данных и связи должны быть скорректированы. Последовательная конструкция кольцевой топологии делает ее чувствительной к изменениям. Это может включать повторную синхронизацию данных на нескольких узлах.

- Более высокая задержка записи: для распространения записи по всему кольцу требуется больше времени. Это связано с тем, что каждая запись должна последовательно реплицироваться узел за узлом, что задерживает полную согласованность данных. В приложениях с большим объемом записи эта задержка становится узким местом. Каждое обновление должно ожидать репликации предыдущего. Это особенно ограничивает приложения, требующие быстрого и согласованного доступа к обновленным данным на всех узлах. Он вводит задержки для каждого узла для достижения последнего состояния данных.

Звездная топология

Назначенный корневой узел (центральный узел-лидер) пересылает запись всем остальным узлам. Центральный узел-лидер действует как концентратор, к которому напрямую подключаются сателлиты-лидеры. Это приводит к звездообразной топологии, как показано на рисунке 3, которую также можно обобщить до древовидной топологии.

Плюсы

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

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

- Централизованное управление и мониторинг: узел-концентратор может служить точкой мониторинга всей сети. Его можно использовать для отслеживания работоспособности узла, задержки репликации и стабильности сети. Его также можно использовать для процессов настройки, обслуживания и резервного копирования. Такая установка снижает потребность в обширных распределенных системах мониторинга и управления.

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

Минусы

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

- Ограниченная масштабируемость: хотя звездообразная топология масштабируется лучше, чем полная сетка, она также имеет ограничения. По мере роста числа узлов концентратор должен обрабатывать увеличенный трафик репликации, что может расширить его аппаратные ограничения. Чтобы избежать этого узкого места, концентраторы должны быть оснащены масштабируемым оборудованием, а для более крупных установок могут потребоваться дополнительные концентраторы.

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

Синхронный, полусинхронный и асинхронный

При синхронной репликации лидер ожидает ответа от последователя. При асинхронной репликации лидер не ждет ответа от последователя.

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

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

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

Проблемные функции в установках с несколькими выносками

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

Ограничения целостности

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

Триггеры

Триггеры базы данных автоматически выполняются в ответ на определенные события (например, вставки, обновления или удаления). Когда одна и та же операция происходит одновременно на разных лидерах, могут возникнуть конфликты между триггерами. Например, узел A обновляет запись, что активирует триггер для обновления связанных данных. Обновление распространяется на узел B, где снова срабатывает тот же триггер. По сути, обновление отправляется обратно на узел А, продолжая цикл на неопределенный срок. Если триггеры включают несколько связанных таблиц или каскадные обновления, простое изменение на одном ведущем узле может привести к каскадным конфликтам на других.

Автоинкрементные ключи

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

Подведение итогов

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

В этой статье разработчиками DST Global, были проанализированы три основные топологии репликации с несколькими лидерами. Мы рассмотрели их плюсы и минусы и выделили некоторые коммерческие базы данных, которые мы использовали для каждой топологии. Существуют и другие топологии, выходящие за рамки нашей компетенции, например, топология «главный-главный» со свидетелями, которая предназначена для балансировки отказоустойчивости, операционной эффективности и согласованности данных. Ожидаются также новые топологии, либо в виде гибридных комбинаций проанализированных, либо в виде новых инновационных идей, поскольку спрос на репликацию данных возрастает.

Репликация данных редко используется сама по себе и часто используется параллельно с секционированием базы данных. Хотя в этой статье основное внимание уделяется конкретному виду репликации данных, секционирование базы данных — это тема, которая сама по себе требует внимания. Я надеюсь, что эта статья может послужить основой для понимания существующих гибридных комбинаций топологий репликации данных с несколькими ведущими устройствами и навигации по ним.