Чи погано мати дуже повний жорсткий диск на сервері баз даних з високим трафіком?

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

Ми зберігаємо щоденні резервні копії баз даних на сервері БД, чи є якісь ефективні дії або причина, чому нам слід тримати жорсткий диск відносно порожнім? Якщо диск заповнений до 86% + базою даних та всіма резервними копіями, чи взагалі це шкодить продуктивності?

Тож чи буде сервер БД, що працює з 86-90% + повною ємністю, в будь-якому разі працює менш добре, ніж сервер, що працює лише з 10% повним диском?

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

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

Ваше запитання щодо продуктивності диска стосується того, наскільки повноцінним є дисковий диск, залежить від того, яким чином доступ до даних на диску. Для прядильних дисків є два фізичні фактори, які впливають на продуктивність вводу / виводу. Вони є:

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

• затримка при обертанні - це середній час, який потрібен, щоб бажані дані дісталися до зчитувальної головки, коли привід обертається - для приводу обертання в обороті в 15 Кб це 2 мс (мілісекунд)

Наскільки повноцінний ваш накопичувач, може вплинути на середній час пошуку вводу / виводу вашого сервера. Наприклад, якщо ваш накопичувач повний і у вас є таблиці баз даних, які фізично розташовані на диску на крайніх протилежних кінцях пластин диска, то під час виконання вводу-виводу ви отримаєте доступ до даних з кожної з цих таблиць. максимальний час пошуку приводу.

Однак, якщо ваш накопичувач заповнений і ваша програма отримує доступ лише до невеликої частини даних, що зберігаються на диску, і всі ці дані знаходяться безперервно на диску, то ці введення / виведення будуть мінімально впливати час пошуку .

На жаль, відповідь на це запитання полягає в тому, що "ваш пробіг буде змінюватися", тобто те, як ваша програма отримує доступ до даних і де вони знаходяться, визначатиме, якою буде ваша ефективність вводу / виводу.

Також, як згадує @gravyface, було б "найкращою практикою" відокремлювати вимоги щодо зберігання операційної системи від вашої бази даних. Знову ж таки, це допоможе мінімізувати рух голови по поверхні диска, оскільки наявність обох на одному диску може викликати постійний пошук між операційною системою та областями бази даних накопичувача, оскільки і операційна система, і програмне забезпечення бази даних роблять запити вводу / виводу.

Тут слід врахувати два кути: Продуктивність та Надітність.

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

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

Причини цього досить прості: Ви не хочете, щоб на продуктивність БД впливали "інші речі", що вимагають диска (наприклад, якщо машина починає сильно мінятися, а розділ swap знаходиться на іншій стороні диска з даних БД, які ви довгий диск прагне протистояти).

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

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

Я рекомендую перемістити базу даних та тимчасові (див. Нижче) резервні копії на інший розділ, ніж root (/).

Крім того, придумайте обґрунтовану схему повороту / утримання для ваших (припустимих) резервних копій дамп-файлів. Немає жодної причини зберігати стільки копій резервних копій на локальному диску. Нічого не стосується відновлення після аварій, а коли переїхати за межі сайту, слід вийняти з диска

Це майже стандартна операційна процедура.

Це нагадало мені про помилку в NetApp, коли файлові системи, які знаходяться майже в повному обсязі, значно знизилися (як удвічі). (правда, це було кілька років тому).

Відповідь, як усі казали, це залежить, але варто продумати це.

Основним недоліком повноцінних файлових систем є список вільних вкладів, які, ймовірно, будуть фрагментовані і всюди.

Існує три типи даних, які сидять на жорсткому диску для бази даних.

1. Ваш фактичний файл бази даних. Це буде великий попередньо розміщений файл, який зазвичай росте великими шматками (наприклад, 10%).
2. Журнали, ваш журнал транзакцій, який постійно записується, видаляється, записується в тощо.
3. Тимчасові файли для великих запитів, які не можуть працювати в пам'яті.

(1) вільний простір потребує лише для виділення більше місця для вашого набору файлів. Якщо ваша база даних не зростає, на неї не повинно вплинути файлова система з невеликим дисковим простором. Якщо він виділяє, він може попросити дуже великий фрагмент, який не вписується у жоден безкоштовний список, який ви одразу фрагментує вашу базу даних і викликає пошук, коли потрібні дані для готовності до пам'яті.

(2) постраждає наївна імпементація журналів, коли вона використовує ОС для управління виділенням простору та видалення. Припустимо, що ваша база даних не тільки для читання, буде постійний потік журналів, вони часто будуть фрагментовані на невеликому просторі на жорсткому диску. Зрештою це зашкодить вашій письмовій формі.

(3) tempDB, якщо БД потрібна для запитаних запитів або недостатньо оперативної пам’яті, то у вас є більші проблеми, ніж низький дисковий простір, що спричиняє проблеми з продуктивністю, оскільки навіть ваші показники читання можуть перетворитися на диск. Ви також ризикуєте перебоями, якщо MySql потрібно було виділити місце на диску для tempDB і жорсткий диск закінчився.

Про резервні копії ...

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

Якщо коротко сказати, ви переживете, якщо ваша БД не буде важкою. Якщо це так, то мало місця на диску - це проблема. Але якби я був ти, я би працював над цим раніше, ніж пізніше.

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

Використовуйте окремі шпинделі та контролери, якщо можете для 1.

Далі йдуть окремі шпинделі

Слідом за окремими перегородками бідолахи.

У мене була подібна проблема нещодавно, коли я використав весь диск на одному з моїх серверів реплікації. Безпосередній ефект полягав у тому, що реплікація зазнала краху, і тоді я не зміг увійти в MySQL, оскільки файл mysqld.sock не вдалося відкрити.