репликация "главный-подчиненный" ведомая: ведущее устройство станет узким местом для записей
Почему беспокойство с двумя низкими машинами спецификации, я испытал бы желание просто купить единственный сервер с 12 ГБ памяти, E5540 и выполнить VMs от локальных дисков - это будет НАМНОГО быстрее, чем попытка работать, это от низкопроизводительного NFS монтируется - легче установить также.
Нет никакого единого ответа на масштабирующийся MySQL. Несколько общих советов:
Масштабируйтесь "по диагонали", пока Вы можете, т.е. сохранять вещи на единственном сервере MySQL, пока Вы все еще можете работать на потребительском оборудовании. Это, вероятно, означает 2 x четырехъядерных центральных процессора, 64 + RAM ГБ, 8 дисков RAID 10 - или выше. Верхний конец того, что является "потребительским оборудованием", становится быстрее каждый год.
Взгляните на презентации Brad Fitzpatrick о масштабировании LiveJournal. Они - в значительной степени классика насколько масштабирующаяся ЛАМПА идет. На странице 25 - 26 этой презентации Вы видите проблему, с которой Вы в конечном счете столкнетесь с репликацией MySQL: записи используют весь доступный диск ввод-вывод.
Считайте "Высокопроизводительный MySQL". Это - действительно хорошая книга авторов, которые видели много установок MySQL высокой загрузки.
Избегайте sharding (распространяющий данные по многим серверам MySQL) максимально долго. При запуске sharding Вы бросаете большинство преимуществ реляционных баз данных, и Вы замедляете разработку. Если необходимо сделать sharding, рассмотрите использование хранилища данных NoSQL со встроенной много моделью сервера вместо этого - fx Riak, Cassandra, HBase, MongoDB. Идеально, сделайте "функциональное разбиение" между MySQL и NoSQL, так, чтобы Вы продолжали использовать MySQL для меньших горячих данных, которые соответствуют хорошо RDBMS, и Вы используете механизм NoSQL для 'горячих' данных, к которым Вы не должны присоединяться с данными MySQL.
возможно, кластер mysql? если так, есть ли какие-либо ловушки или ограничения в переключении базы данных к ndb?
В "веб-Операциях" существует глава по MySQL Baron Schwartz. Он в значительной степени выгоняет, говорит "Нет!" к использованию MySQL Cluster / NDB в среде веб-сайта. Кавычка: ".. это не работает хорошо для соединений и запросов GROUP BY, и для веб-приложений нужны они"..
Кластеризация MySQL получит Вас масштабируемость записей путем повреждения базы данных во фрагменты, которые распространены по нескольким машинам. Но это решительно замедлит сложные запросы, которые вытягивают данные из нескольких фрагментов. Только можно определить эффект этого на производительности приложения.
Вы могли бы хотеть посмотреть на sharding данные вручную вместо того, чтобы позволить кластеризирующемуся механизму сделать это для Вас. Потребуется больше конфигурации, но если Вы понимаете, как Ваше приложение использует базу данных, Вы можете придумывать sharding схему, которая позволяет большинство запросов, только получают доступ к одному черепку.
Помните, та репликация MySQL является единственной, распараллелил, таким образом, вероятно, Ваша репликация не будет ограничена основной способностью, но ведомыми устройствами, которые не могут задержать ведущее устройство и будут вне синхронизации. От этой статьи:
Процесс воспроизведения репликации выполняется в единственном потоке на копиях и таким образом не имеет никакой надежды на не отставание даже от умеренно занятой нагрузки записи на основное устройство, где много обновлений происходят одновременно.
Можно думать о кластеризации самой информации. Если возможно - разделить таблицы потребления записи между различными серверами.