Запуск сервера Ubuntu с MySQL для высокопроизводительного сервера базы данных. На машине больше ничего не работает, кроме экземпляра MySQL.
Мы храним ежедневные резервные копии базы данных на сервере БД, есть ли снижение производительности или причина, по которой мы должны держать жесткий диск относительно пустым? Если диск заполнен базой данных и всеми резервными копиями на 86% +, это вообще повредит производительности?
Так будет ли сервер БД, работающий с 86-90% + полной емкостью, работать хуже, чем сервер, работающий только с 10% заполненным диском?
Общий размер диска на сервере превышает 1 ТБ, поэтому даже 10% диска должно быть достаточно для базовой подкачки O / S и т.п.
Прежде всего, вы НЕ хотите хранить резервные копии базы данных на том же физическом диске или в группе RAID, что и ваша база данных. Причина этого в том, что сбой диска (если вы работаете без какой-либо защиты RAID) или катастрофический сбой RAID (если вы используете RAID-1 или RAID-5) приведет к потере вашей базы данных и резервных копий базы данных.
Ваш вопрос о производительности диска относится к тому, насколько заполнен диск, зависит от того, как осуществляется доступ к данным на диске. Для вращающихся дисков на производительность операций ввода-вывода влияют два физических фактора. Они есть:
время поиска - время, которое требуется дисководу, чтобы переместить головку диска из текущей позиции дорожки на дорожку, содержащую запрошенные данные
задержка при вращении - это среднее время, необходимое для того, чтобы нужные данные достигли считывающей головки при вращении диска - для диска со скоростью 15 000 об / мин это 2 мс (миллисекунды)
Насколько заполнен ваш диск, может повлиять на среднее время поиска операций ввода-вывода вашего сервера. Например, если ваш диск заполнен и у вас есть таблицы базы данных, которые физически расположены на диске на крайних противоположных концах пластин диска, то при выполнении операций ввода-вывода с доступом к данным из каждой из этих таблиц эти операции ввода-вывода будут испытываться. максимальное время поиска накопителя.
При этом, однако, если ваш диск заполнен, а ваше приложение обращается только к небольшой части данных, хранящихся на диске, и все эти данные расположены на диске непрерывно, то время поиска будет минимально влиять на эти операции ввода-вывода. .
К сожалению, ответ на этот вопрос заключается в том, что «ваш пробег будет варьироваться», что означает, что то, как ваше приложение получает доступ к данным и где эти данные находятся, будет определять, какой будет ваша производительность ввода-вывода.
Кроме того, как упомянул @gravyface, было бы "лучше всего" отделить требования к хранилищу вашей операционной системы от вашей базы данных. Опять же, это поможет свести к минимуму перемещение головки по поверхности диска, поскольку наличие обоих на одном диске может вызвать постоянный поиск между операционной системой и областями базы данных на диске, поскольку и операционная система, и программное обеспечение базы данных делают запросы ввода-вывода.
Здесь необходимо учитывать два аспекта: производительность и надежность.
С точки зрения производительности обычно рекомендуется использовать отдельные шпиндели дисков (или группы RAID / наборы дисков) для:
Причина этого довольно проста: вы не хотите, чтобы на производительность БД влияли "другие вещи", требующие диска (например, если машина начинает интенсивно менять местами, а раздел подкачки находится на другой стороне диска от данных БД, которые вы длинный диск старается бороться с).
С точки зрения надежности вам нужна такая же поломка, но по другой причине: как указывали другие, вы не хотите, чтобы отказавший диск извлекал как вашу БД, так и ее резервные копии (хотя на самом деле вы должны копировать резервные копии с сервер в любом случае в случае катастрофического отказа).
Вы также хотите избежать любой конфигурации с монолитным / перегородка, в которой есть все - это досадная, трагичная и тревожно распространенный ошибка, допущенная в мире Linux, не разделяемая другими Unix-подобными системами.
Как упомянул Gravyface в своем комментарии, если вам как-нибудь удастся заполнить / ваша система почти наверняка выйдет из строя, а очистка / восстановление может занять много времени и денег, если в системе есть один / раздел, а не хорошо структурированная иерархия точек монтирования.
Я бы рекомендовал переместить базу данных и временные (см. Ниже) резервные копии в другой раздел, кроме корневого (/).
Кроме того, придумайте разумную схему ротации / хранения для ваших (предполагаемых) резервных копий сжатого дампа базы данных. (Обычно) нет причин хранить такое количество копий резервных копий на локальном диске. Ничего не делает для аварийного восстановления и при перемещении за пределы предприятия должен быть удален с диска.
Это довольно стандартная рабочая процедура.
Это напомнило мне об ошибке в NetApp, когда почти полностью заполненные файловые системы сильно падали (примерно наполовину). (правда, это было несколько лет назад).
Как все сказали, ответ зависит от обстоятельств, но над этим стоит подумать.
Основным недостатком полных файловых систем является то, что список свободных индексных дескрипторов, вероятно, будет фрагментирован и повсюду.
На жестком диске базы данных хранятся данные трех типов.
(1) свободное пространство требуется только при выделении дополнительного места для набора файлов. Если ваша база данных не растет, на нее не должно влиять файловая система с нехваткой места на диске. Однако, если он распределяется, он может запросить очень большой кусок, который не вписывается ни в один свободный список, который вы немедленно фрагментируете и вызываете поиск, когда ему нужны данные для загрузки в память.
(2) наивная реализация журналов, когда ОС используется для управления распределением пространства, и при его удалении пострадает. Предполагая, что ваша база данных не предназначена только для чтения, будет постоянный поток журналов, они часто будут фрагментированы при нехватке места на жестком диске. В конечном итоге это снизит производительность записи.
(3) tempDB: если он нужен БД для некачественно написанных запросов или недостаточно оперативной памяти, тогда у вас есть более серьезные проблемы, чем недостаток места на диске, вызывающий проблемы с производительностью, поскольку даже ваша производительность чтения может тогда стать привязанной к диску. Вы также рискуете выйти из строя, если MySql нужно было выделить дисковое пространство для tempDB, а на жестком диске закончилось.
О резервных копиях ...
Короче говоря, я бы сказал, что вы выживете, если ваша БД не будет писать тяжелую. Если это так, то проблема заключается в нехватке места на диске. Но на вашем месте я бы поработал над следующим раньше, чем позже.
По возможности используйте отдельные шпиндели и контроллеры для 1.
За ними следуют отдельные шпиндели
Далее идут отдельные перегородки бедняка.
У меня была аналогичная проблема недавно, когда я использовал все дисковое пространство на одном из моих серверов репликации. Непосредственным следствием этого был сбой репликации, после чего я не смог войти в MySQL, потому что не удалось открыть файл mysqld.sock.