Разве плохо иметь жесткий диск на сервере базы данных с высоким трафиком?

Запуск сервера Ubuntu с MySQL для сервера базы данных с высоким трафиком. На машине больше ничего не работает, кроме экземпляра MySQL.

Мы храним ежедневные резервные копии базы данных на сервере БД. Есть ли какое-либо снижение производительности или причина, по которой мы должны держать жесткий диск относительно пустым? Если диск заполнен до 86% + базой данных и всеми резервными копиями, это вообще влияет на производительность?

Так будет ли сервер БД, работающий с 86-90% + полной емкостью, работать менее эффективно, чем сервер, работающий только с 10% заполненного диска?

Общий размер диска на сервере превышает 1 ТБ, поэтому даже 10% диска должно быть достаточно для базовой замены O / S и тому подобного.

Прежде всего, вы НЕ хотите хранить резервные копии базы данных на том же физическом диске или в группе RAID, что и ваша база данных. Причина этого заключается в том, что сбой диска (если вы работаете без какой-либо защиты RAID) или катастрофический сбой RAID (если вы используете RAID-1 или RAID-5) приведет к потере базы данных и резервных копий базы данных.

Ваш вопрос о производительности диска связан с тем, насколько он заполнен, зависит от того, как осуществляется доступ к данным на диске. Для вращающихся дисков существует два физических фактора, которые влияют на производительность ввода-вывода. Они есть:

• время поиска - это время, которое требуется дисководу, чтобы переместить головку диска из текущей позиции дорожки в дорожку, содержащую запрошенные данные

• задержка вращения - то есть среднее время, необходимое для того, чтобы требуемые данные достигли считывающей головки при вращении привода, - для привода со скоростью 15K об / мин это 2 мс (миллисекунды)

Степень заполнения вашего накопителя может повлиять на среднее время поиска операций ввода-вывода на вашем сервере. Например, если ваш диск заполнен, и у вас есть таблицы базы данных, которые физически расположены на диске на крайних противоположных концах пластин диска, то при выполнении операций ввода-вывода для доступа к данным из каждой из этих таблиц эти операции ввода-вывода будут происходить. максимальное время поиска диска.

Тем не менее, если, однако, ваш диск заполнен, и ваше приложение обращается только к небольшой части данных, хранящихся на диске, и все эти данные расположены непрерывно на диске, то эти операции ввода-вывода будут минимально затронуты временем поиска ,

К сожалению, ответ на этот вопрос заключается в том, что «ваш пробег будет разным», а это означает, что то, как ваше приложение получит доступ к данным и где эти данные будут находиться, будет определять вашу производительность ввода-вывода.

Кроме того, как упомянул @gravyface, было бы "наилучшей практикой" отделить требования к хранилищу операционной системы от вашей базы данных. Опять же, это должно помочь минимизировать перемещение головки на поверхности диска, поскольку наличие обоих на одном и том же диске может вызвать постоянный поиск между операционной системой и областями базы данных на диске, поскольку и операционная система, и программное обеспечение базы данных делают запросы ввода-вывода.

Здесь нужно рассмотреть два аспекта: производительность и надежность.

С точки зрения производительности обычно рекомендуется иметь отдельные дисковые шпиндели (или группы RAID / наборы дисков) для:

1. Материал для ОС (двоичные файлы, журналы, домашние каталоги и т. Д.)
2. Пространство подкачки (которое может быть объединено с (1), если вы не планируете использовать своп)
3. Производственная БД
4. Журналы транзакций производственной БД (если используются)
5. Дампы / резервные копии базы данных

Причина этого довольно проста: вы не хотите, чтобы на производительность БД влияли «другие вещи», требующие диска (например, если машина начинает интенсивно менять местами, а раздел подкачки находится на другой стороне диска от данных БД, которые вы уже давно диск стремится сразиться).

С точки зрения надежности вам нужен такой же вид поломки, но по другой причине: как уже отмечали другие, вы не хотите, чтобы отказавший диск извлекал и вашу БД, и ее резервные копии (хотя на самом деле вы должны копировать резервные копии с сервер в любом случае в случае катастрофического сбоя).

Вы также хотите избежать любой конфигурации с монолитным /разделом, который содержит все - это печальная, трагическая и тревожно распространенная ошибка, допущенная в мире Linux, которой не обладают другие Unix-подобные системы.
Как упомянул Gravyface в своем комментарии, если вам как-то удастся заполнить /вашу систему, почти наверняка произойдет сбой, а очистка / восстановление может занять много времени и затрат, если в системе есть один /раздел, а не хорошо структурированная иерархия точек монтирования.

Я бы порекомендовал переместить базу данных и временные (см. Ниже) резервные копии в другой раздел, чем корневой (/).

Кроме того, придумайте разумную схему ротации / хранения для ваших (предполагаемых) сжатых резервных копий дампа базы данных. Обычно нет причин хранить столько копий резервных копий на локальном диске. Ничего не делает для аварийного восстановления и при перемещении за пределы сайта должен быть удален с диска.

Это довольно стандартная рабочая процедура.

Это напомнило мне об ошибке в NetApp, когда у файловых систем, которые почти заполнены, их производительность значительно упала (наполовину). (правда, это было несколько лет назад).

Ответ, как все говорили, зависит от того, стоит ли его обдумать.

Основным недостатком полных файловых систем является то, что список бесплатных инодов, вероятно, будет фрагментирован и повсеместно.

Существует три типа данных, которые хранятся на жестком диске для базы данных.

1. Ваш фактический файл базы данных. Это будет большой предварительно выделенный файл, который обычно растет большими кусками (например, 10%).
2. Журналы, журнал транзакций, который постоянно записывается, удаляется, записывается и т. Д.
3. Временные файлы для больших запросов, которые не могут работать в памяти.

(1) требуется только свободное место, когда выделяется больше места для вашего набора файлов. Если ваша база данных не растет, она не должна зависеть от файловой системы с небольшим дисковым пространством. Однако, если он выделяется, он может запросить очень большой кусок, который не помещается ни в один свободный список, который вы немедленно фрагментируете в своей базе данных, и вызывает поиск, когда ему нужны данные для готовности в памяти.

(2) пострадает имплементация журналов, где она использует ОС для управления распределением пространства и удаления его. Предполагая, что ваша база данных не только для чтения, будет постоянный поток журналов, они часто будут фрагментированы на небольшом жестком диске. В конечном итоге это ухудшит вашу производительность записи.

(3) tempDB, если БД нуждается в ней для неаккуратных письменных запросов или не хватает ОЗУ, то у вас больше проблем, чем на недостаточном дисковом пространстве, что приводит к проблемам с производительностью, поскольку даже ваша производительность чтения может в этом случае ограничиться диском. Вы также рискуете выйти из строя, если MySql нужно было выделить дисковое пространство для tempDB и на жестком диске не хватило.

О резервных копиях ...

1. Каждое предприятие, на котором я работал, хранит резервные копии на одной машине. Когда дело доходит до восстановления (кто заботится о резервных копиях, это восстановление, которое учитывается). Ничто не сравнится с быстродействием наличия файла db прямо на том же диске.
2. Надеюсь, очевидно, убедитесь, что резервные копии не только локальные.

Короче говоря, я бы сказал, что вы выживете, если ваша БД не будет писать тяжело. Если это так, то недостаток дискового пространства является проблемой. Но если бы я был тобой, я бы работал над следующим раньше, чем позже.

1. Подтверждение, что у меня достаточно оперативной памяти
2. Разделение журналов и всех переходных данных из вашей БД.
3. Отделение вашей ОС, MySql от остальных.

Используйте отдельные шпиндели и контроллеры, если можете для 1.

Вслед за отдельными шпинделями

Вслед за отдельным разделом бедного человека.

Недавно у меня была похожая проблема, когда я использовал все дисковое пространство на одном из моих серверов репликации. Непосредственный эффект был для сбоя репликации, и тогда я не мог войти в MySQL, потому что файл mysqld.sock не мог быть открыт.