* What algorithms there are for doing failover in a distributed system?
Возможно, не алгоритмы, а системы. Вы должны разработать свою архитектуру вокруг вопросов, которые вы задали.
* What algorithms there are for consensus in a distributed system?
Вы, вероятно, хотите реализовать Paxos. Простые Паксос не так уж сложно получить право. Если вы пытаетесь сделать это пуленепробиваемым, прочитайте статью Google «Paxos Made Live». Если вы надеетесь сделать его высокопроизводительным, посмотрите на Multi-Paxos.
* How should the nodes in the cluster determine that a node is down?
Зависит. Сердцебиение на самом деле довольно хороший способ сделать это. Проблема в том, что у вас есть ложные срабатывания, но это неизбежно, и в кластере в одной локальной сети с управляемой нагрузкой они точны. Хорошая вещь о Paxos состоит в том, что ложные срабатывания обрабатываются автоматически. Однако, если вам действительно нужна информация о сбое для какой-либо другой цели, вам нужно убедиться, что вы можете определить узел как отказавший, но на самом деле он просто находится под нагрузкой и требует времени для ответа на сердцебиение.
* How should the nodes determine that what database entries had their master copy on the failed node at the time of failure, so that other nodes may recover those entries?
* How to decide that which node(s) has the latest secondary copy of some entry?
* How to decide that which node's secondary copy should be promoted to be the new master copy?
Я думаю, что вы действительно выиграете от чтения статьи Google FileSystem. В GFS есть выделенный главный узел, который отслеживает, какие узлы имеют какие блоки. Эта схема может работать для вас, но ключ в том, чтобы сохранить доступ к этому мастеру минимальным.
Если вы не храните эту информацию на выделенном узле, вам придется хранить ее везде. Попробуйте пометить данные идентификатором основного владельца.
* How to handle it, if the node which was though to be down, suddenly comes back as if nothing happened?
См. Выше, но суть в том, что вы должны быть осторожны, потому что узел, который больше не является мастером, может подумать, что это так. Одна вещь, которую я не думаю, что вы решили: как обновление доходит до мастера - т.е. как клиент узнает, на какой узел отправлять обновление?
* How to avoid split-brain scenarios, where the network is temporarily split into two, and both sides think that the other side has died?
Паксос работает здесь, предотвращая прогресс в случае идеального раскола. В противном случае, как и прежде, вы должны быть очень осторожны.
В общем, решите вопрос о том, какой узел получает какой элемент данных в качестве главного, и вам предстоит долгий путь к исправлению вашей архитектуры. Обратите внимание, что вы не можете просто сделать узел, получающий обновление, главным - что, если два обновления происходят одновременно? Не полагайтесь также на синхронизированные глобальные часы - в этом и заключается безумие. Возможно, вы захотите избежать консенсуса при каждой записи, если сможете помочь, поэтому вместо этого, возможно, используйте медленный протокол аварийного переключения мастера и быстрый путь записи.
Не стесняйтесь снимать мне почту в автономном режиме, если вы хотите узнать больше деталей. Мой блог http://the -paper-trail.org посвящен многим из этих вещей.
ура
Генри