MySQL с Innodb предоставляет хорошее решение общего назначения и, вероятно, будет достаточно легко соответствовать вашим требованиям к производительности на не слишком дорогом оборудовании. Он может легко обрабатывать тысячи обновлений в секунду на двухъядерном процессоре с приличными дисками. Встроенная асинхронная репликация обеспечит большую часть ваших требований к доступности, но вы можете потерять данные на несколько секунд, если произойдет сбой основного. Некоторые из этих потерянных данных могут быть восстановлены при восстановлении первичного сервера или могут быть восстановлены из журналов вашего приложения: насколько вы можете это терпеть, зависит от того, как работает ваша система. Альтернатива с меньшими потерями - но медленнее - это использование MySQL Innodb с общим диском между основным и резервным блоками: в этом случае отказоустойчивый блок займет диск при сбое основного без потери данных - до тех пор, пока основной не было какой-то дисковой катастрофы. Если общий диск недоступен, DRBD можно использовать для имитации этого, синхронно копируя дисковые блоки в резервный модуль по мере их записи: это может повлиять на производительность.
Использование Innodb и одного из приведенных выше решений для репликации позволит скопировать ваши данные на ваше устройство Failover, что является большой частью решаемой проблемы восстановления, но для переконфигурирования вашей системы требуется дополнительный клей, чтобы подключить устройство Failover к сети , Обычно это выполняется с помощью кластерной системы, такой как RHCS, Pacemaker или Heartbeat (в Linux) или MS Cluster для Windows. Эти системы представляют собой наборы инструментов, и вам остается только испачкать руки, превратив их в решение, подходящее для вашей среды. Однако для всех этих систем существует короткий период простоя, пока система замечает, что первичный произошел сбой, и перенастраивает систему для использования модуля Failover. Это может занять десятки секунд: попытка уменьшить это может сделать вашу систему обнаружения сбоев слишком чувствительной, и вы можете обнаружить, что ваша система отказывается без необходимости.
Двигаясь вверх, MySQL NDB призван сократить время восстановления и в некоторой степени помочь расширить вашу базу данных для повышения производительности. Однако MySQL NDB имеет довольно узкий диапазон применимости. Система отображает реляционную базу данных в распределенную хеш-таблицу, и поэтому для сложных запросов, включающих множественные объединения между таблицами, между компонентом MySQL и компонентами хранилища (узлами NDB) довольно много трафика, что делает сложные запросы медленными. Однако запросы, которые хорошо подходят, действительно выполняются очень быстро. Я смотрел на этот продукт несколько раз, но мои существующие базы данных были слишком сложными, чтобы соответствовать им, и для получения хорошей производительности потребовалось бы много изменений. Однако, если вы находитесь на стадии проектирования новой системы, NDB будет работать хорошо, если вы будете помнить о ее ограничениях по ходу работы. Кроме того, вы можете обнаружить, что вам нужно немало машин для обеспечения хорошего решения NDB: пара узлов MySQL плюс 3 или более узлов NDB - хотя узлы MySQL и NDB могут сосуществовать, если ваши требования к производительности не слишком велики.
Даже MySQL NDB не может справиться с полной потерей сайта - пожар в центре обработки данных, ошибка администратора и т. Д. В этом случае вам обычно требуется другой поток репликации, работающий на сайте DR. Обычно это делается асинхронно, чтобы сбой соединения на межсайтовой ссылке не останавливал всю вашу базу данных. Это обеспечивается опцией географической репликации NDB (в платной телефонной версии), но я думаю, что MySQL 5.1 и выше может обеспечить это изначально.
К сожалению, я мало что знаю о Zookeeper и Chubby. Надеюсь, что кто-то еще сможет понять эти аспекты.