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