Какие методы или инструменты используются для масштабирования базы данных mysql. У нас есть база данных mysql, размер которой увеличивается с каждым днем. Мы только что выделили для него фиксированный размер жесткого диска, поэтому меня беспокоит то, что нам нужно будет переместить или увеличить размер жесткого диска когда-нибудь, когда жесткий диск будет заполнен.
Использование RAID казалось хорошей идеей, но по-прежнему имеет фиксированный размер. Нам нужна масштабируемая система для базы данных MySQL.
Сейчас я могу думать только о Hadoop как о решении.
Идеальное решение для нас - когда жесткий диск достигнет своего предела, мы просто добавим еще один жесткий диск на машину, и MySQL распознает его как один, тогда мы не сможем добавить еще жесткий диск на сервер, будет настроен новый сервер, который будет добавить к общему размеру пространства для хранения данных MySQL.
Три самых популярных метода масштабирования - это репликация главный-подчиненный, разделение и сегментирование. Репликация главный-подчиненный эффективна только тогда, когда вы хотите масштабировать чтение. Он не предназначен для масштабирования размера БД или записи. Разбиение - это метод хранения большой таблицы в нескольких физических местах (на нескольких жестких дисках). Шардинг можно рассматривать как разделение на глобальном уровне, выполняемое приложением, а не сервером MySQL. По сути, сегментирование - это метод хранения похожих данных в нескольких базах данных MySQL, не связанных напрямую. Первые два метода поддерживаются MySQL внутренне, сегментирование должно выполняться разработчиками приложений на уровне приложения. Похоже, вам следует использовать сегментирование, поскольку разделение не может распространяться на несколько серверов и тогда имеет определенные ограничения.
Кластеризация обычно используется как решение проблемы производительности, однако моя интерпретация того, что вы написали, заключается в том, что проблема в размере базы данных?
Использование базы данных NoSQL обычно делается из соображений производительности (репликация MySQL проста в настройке - поэтому нет большой разницы с точки зрения доступности), но вы теряете ОГРОМНЫЙ количество функциональных возможностей. Hadoop не решит проблемы с объемом данных и может означать, что вам нужно переписать МНОГО кода.
То, как вы управляете объемами данных, во многом зависит от характера приложения и данных - можете ли вы удалить старые данные? Можете ли вы перенести его в автономный режим? Можете ли вы объединить старые данные?
Идеальное решение для нас - когда жесткий диск достигает предела, мы просто добавляем еще один жесткий диск на машину, и MySQL распознает его как один
Хотя вы можете просто добавить диск в виде массива RAID-0 или JBOD, это очень запутанная практика - вы переходите от единой точки отказа к множеству точек отказа.
Точно так же вы можете смонтировать диск и перенести отдельные файлы таблиц (используя символические ссылки из исходных местоположений), но это предполагает, что вы не используете однофайловую внутреннюю часть innodb. Это так же плохо, как использование RAID-0 / JBOD.
Для транзакционной СУБД зеркалирование (RAID-1) дает огромные преимущества в производительности, но не увеличивает объемы хранения. Поэтому я бы рекомендовал спланировать скачок объема хранилища с 1 до 4 дисков (настроенных как зеркальная пара наборов лент).