Почему нам нужны базы данных с несколькими лидерами?

1. Поддержка операций записи в нескольких центрах обработки данных для повышения производительности в центрах обработки данных.
2. Устойчивость к сетевым проблемам в центрах обработки данных.
3. Независимая работа всех других центров обработки данных, даже если один из них выйдет из строя

Как мы должны справляться с письменными конфликтами между лидерами? Столкновение автоинкрементных ключей? Исправить перепутанные данные в мультилидере из-за какой-либо ошибки или проблемы? и более

Самый простой способ решить проблему — это вообще не испытывать боли.

Как у нас не может быть конфликтов в мультилидере?

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

Способы разрешения конфликтов

Теперь есть два пути разрешения конфликтов

1. Приложение разрешает конфликты: приложение обнаруживает конфликты, и фрагмент кода разрешает их, или это может сделать база данных. Одним из способов является техника «выигрывает последней записью» (LWW).
   Дайте мне знать в комментариях, если вы хотите блог для обсуждения различных методов. Я бы с удовольствием это сделал :)
2. Пользователь разрешает конфликты: сохраните все версии конфликта, и в следующий раз, когда пользователь прочитает данные, предложите пользователю и запишите результат обратно в базу данных.

Каждый узел пишет с одного узла и перенаправляет эти записи на другой узел.

Один назначенный корневой узел пересылает записи на все остальные узлы.

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

Как избежать бесконечных циклов репликации?

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

Но здесь есть еще одна проблема, единственная точка отказа.

Если один узел выйдет из строя, это повлияет и на другие узлы.

Как предотвратить единую точку отказа?

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

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

Вектор версии — это совершенно другой блог, поэтому здесь он не обсуждается.

Это могло дать вам изрядное количество архитектуры с несколькими лидерами, так что вы думаете, стоит ли все это того? Или мы должны избегать мультивыноски?

Вы можете следить и подписываться, чтобы оставаться в курсе со мной :)

Проектирование приложений с интенсивным использованием данных: большие идеи, лежащие в основе надежных, масштабируемых и обслуживаемых систем: Мартин Клеппманн