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

Question

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

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

Answer 1

Mysql NDB Cluster БУДЕТ сделать это. Но его нелегко настроить и у него много ошибок.

Кроме того, его производительность, как правило, довольно плохая, и он хранит данные в памяти (да, я знаю, они звучат противоречиво).

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

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

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

Я бы порекомендовал игнорировать multi-master и использовать вместо него HA MySQL (например, с InnoDB), который легко настроить и очень хорошо работает с типичными временами переключения при отказе до 30 секунд. Это система «ведущий-ведомый», в которой ведомое устройство не может даже выполнять чтение (но вы можете добавить считываемые ведомые устройства с репликацией, если вам не нужно, чтобы они были полностью обновлены)

Answer 2

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

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

Answer 3

Я думаю, что Oracle прибил эту концепцию. Однако, если вы смертный человек без счета в швейцарском банке, то, возможно, вам стоит заглянуть в MySQL NDB Cluster .