база данных mysql имеет около 2 ТБ данных.
у меня работает репликация главный-подчиненный-подчиненный. приложение, которое использует базу данных, читает (SELECT) запросы только на одном из 2 ведомых устройств и записывает запросы (DELETE / INSERT / UPDATE) на ведущем. приложение больше читает, чем пишет.
если у нас есть проблема с запросами чтения (SELECT), мы можем просто добавить еще одну подчиненную базу данных и сообщить приложению, что есть еще одна мазь. так что хорошо масштабируется ...
В настоящее время мастер выполняет около 40% дискового ввода-вывода из-за операций записи.
Поэтому я думаю о том, как масштабировать базу данных в будущем. Потому что однажды мастер будет перегружен.
Какое там может быть решение?
может кластер mysql? Если да, то есть ли какие-то подводные камни или ограничения при переключении базы данных на ndb?
Заранее большое спасибо... :)
Не существует универсального ответа на вопрос масштабирования MySQL. Несколько общих советов:
Масштабируйте "по диагонали" так долго, как можете, т.е. храните все на одном сервере MySQL, пока вы все еще можете работать на стандартном оборудовании. Это, вероятно, означает 2 четырехъядерных процессора, 64+ ГБ оперативной памяти, 8 дисков RAID 10 или выше. Верхняя граница «товарного оборудования» с каждым годом становится все быстрее.
Посмотрите презентации Брэда Фитцпатрика о масштабировании LiveJournal. С точки зрения масштабирования LAMP они в значительной степени классика. На стр. 25–26 данной презентации вы видите проблему, с которой вы в конечном итоге столкнетесь с репликацией MySQL: операции записи потребляют весь доступный дисковый ввод-вывод.
Читать "Высокая производительность MySQL". Это действительно хорошая книга авторы, которые видели много установок MySQL с высокой нагрузкой.
Избегайте сегментирования (распространения данных по множеству серверов MySQL) как можно дольше. Когда вы начинаете сегментирование, вы отказываетесь от большинства преимуществ реляционных баз данных и замедляете разработку. Если вам нужно выполнить сегментирование, рассмотрите возможность использования хранилища данных NoSQL со встроенной многосерверной моделью - fx Riak, Cassandra, HBase, MongoDB. В идеале выполните «функциональное разделение» между MySQL и NoSQL, чтобы вы продолжали использовать MySQL для менее горячих данных, которые хорошо вписываются в СУБД, и вы использовали механизм NoSQL для «горячих» данных, которые вам не нужно объединять с MySQL. данные.
может кластер mysql? если да, то есть ли какие-то подводные камни или ограничения при переключении базы данных на ndb?
В "Веб-операции«есть глава по MySQL Барона Шварца. Он в значительной степени справедливо говорит« Нет! »использованию MySQL Cluster / NDB в среде веб-сайта. Цитата:« .. он не работает хорошо для объединений и запросов GROUP BY, и веб-приложениям они нужны. ".
Кластеризация MySQL даст вам масштабируемость записи, разбив базу данных на фрагменты, которые распределены по нескольким машинам. Но это резко замедлит сложные запросы, которые извлекают данные из нескольких фрагментов. Только вы можете определить влияние этого на производительность вашего приложения.
Возможно, вы захотите взглянуть на сегментирование данных вручную, вместо того, чтобы позволить механизму кластеризации сделать это за вас. Потребуется дополнительная настройка, но если вы понимаете, как ваше приложение использует базу данных, вы можете придумать схему сегментирования, которая позволяет большинству запросов обращаться только к одному сегменту.
Помните, что репликация MySQL является однопоточной, поэтому, вероятно, ваша репликация будет ограничиваться не мощностью мастера, а ведомыми устройствами, которые не могут отставать от мастера и будут не синхронизированы. Из этой статьи:
Процесс воспроизведения репликации выполняется в одном потоке на репликах, и поэтому у него нет никакой надежды справиться даже с умеренно загруженной записывающей нагрузкой на первичный, где одновременно происходит множество обновлений.
Можно подумать о кластеризации самой информации, если есть возможность - разделить записи потребления таблиц между разными серверами.