Работает ли MySQL (или любая другая реляционная база данных) на GFS (с DRBD) и несколько узлов, читающих и записывающих в нее? Если да, то это «лучший» способ обеспечить настройку базы данных / приложения высокой доступности? Подходит ли RHEL (набор кластеров) для этого? (или centos)
DRBD работает только с двумя узлами. Если вы используете его в первичной / первичной настройке, это действительно позволит вам получить некоторую высокую доступность.
Я бы не рекомендовал GFS, он очень медленный. DRBD работает медленно, потому что ему необходимо реплицировать данные по сети. Если вы добавите к этому медленную FS, вы столкнетесь с проблемами. Под медленным я подразумеваю медленнее, чем DAS.
Функции репликации, включенные в MySQL, представляют собой беспорядок. С двумя серверами это уже довольно сложно, но с круговой репликацией это просто безумие.
Для серверов БД я считаю, что лучшим решением является использование функций репликации, включенных в систему БД. Использование блочной репликации потенциально может привести к повреждению данных, что, скорее всего, приведет к сбою сервера.
Представьте себе, у вас есть настройка master / master с использованием DRBD / OCFS. Что произойдет, если вы сделаете вставку в одну и ту же таблицу обоих хостов одновременно (+/- 1 мс)? Как DRDB / OCFS должен знать, как упорядочивать кортежи? Функции репликации программного обеспечения БД будут знать, как с этим справиться, в то время как DRBD / OCFS не предназначен для обработки таких вещей.
Поэтому используйте функции репликации MySQL и проведите краш-тест. Попробуйте потянуть за шнур один сервер и посмотреть, что произойдет, когда он вернется в сеть. Попробуйте потянуть за шнур оба и посмотреть, что произойдет, когда они вернутся в сеть. Сделайте много одновременных вставок и обновлений на обоих одновременно.
Для более чем двух узлов рассмотрите MySQL Proxy.
Круговая репликация mysql + drbd + heartbeat работала в нескольких настройках.
вам просто нужно его настроить.
Что касается чтения / записи нескольких узлов, я попробую прокси mysql.
HTH