#kubernetes #distributed-system #fault-tolerance
Вопрос:
Насколько я понимаю, большинство баз данных позволяют использовать реплики, которые могут заменить лидера в случае, если лидер недоступен.
Я задаюсь вопросом о необходимости наличия этих реплик в среде Kubernetes при использовании, скажем, набора состояний. Как только модуль перестанет отвечать на запросы, Kubernetes перезапустит его, верно? И ПВХ позаботится о том, чтобы данные не были потеряны.
Может быть, выборы лидера-это более быстрый процесс, чем подача нового заявления?
Или дело в том, что единственным преимуществом реплик является обеспечение балансировки нагрузки для запросов на чтение?
Ответ №1:
Насколько я понимаю, большинство баз данных позволяют использовать реплики, которые могут заменить лидера в случае, если лидер недоступен.
Я задаюсь вопросом о необходимости наличия этих реплик в среде Kubernetes при использовании, скажем, набора состояний.
Произошел переход к распределенным базам данных с предыдущих баз данных с одним узлом. Распределенные базы данных обычно работают с использованием 3 или 5 реплик / экземпляров в кластере. Основной целью для этого является высокая доступность и отказоустойчивость, например, при отказе узла или диска. Это то же самое, если база данных запущена на Kubernetes.
ПВХ позаботится о том, чтобы данные не были потеряны.
Цель PVCs состоит в том, чтобы отделить конфигурацию приложения от выбора системы хранения. Это позволяет, например, развертывать одно и то же приложение как в Google Cloud, AWS, так и в Minikube без какой-либо другой конфигурации, хотя вы будете использовать разные системы хранения. Это не меняет того, как работают системы хранения.
Может быть, выборы лидера-это более быстрый процесс, чем подача нового заявления?
Многие разные вещи могут выйти из строя, узел, система хранения или сеть могут быть разделены так, что вы не сможете добраться до определенного узла.
Выборы лидера-это всего лишь часть мер по устранению этих проблем в кластерной настройке, вам также необходима последовательная репликация всех данных. Алгоритм консенсуса Raft является распространенным решением для этого в современных распределенных базах данных.
Или дело в том, что единственным преимуществом реплик является обеспечение балансировки нагрузки для запросов на чтение?
Да, это может быть преимуществом в распределенных базах данных. Но, по моему опыту, это редко бывает основной причиной их использования.