Czy źle jest mieć bardzo pełny dysk twardy na serwerze bazy danych o dużym natężeniu ruchu?

Uruchamianie serwera Ubuntu z MySQL dla produkcyjnego serwera bazy danych o dużym ruchu. Na komputerze nie działa nic innego niż instancja MySQL.

Codziennie przechowujemy kopie zapasowe bazy danych na serwerze DB, czy jest jakiś spadek wydajności lub powód, dla którego powinniśmy utrzymywać dysk twardy względnie pusty? Jeśli dysk jest zapełniony do ponad 86% bazą danych i wszystkimi kopiami zapasowymi, czy w ogóle wpływa to negatywnie na wydajność?

Czy więc serwer DB działający z pełną wydajnością 86-90% + działałby gorzej w jakikolwiek sposób niż serwer działający tylko z 10% pełnym dyskiem?

Całkowity rozmiar dysku na serwerze to ponad 1 TB, więc nawet 10% dysku powinno wystarczyć do podstawowej wymiany O / S i tym podobnych.

Przede wszystkim NIE chcesz przechowywać kopii zapasowych bazy danych na tym samym dysku fizycznym lub grupie RAID co baza danych. Powodem tego jest to, że awaria dysku (jeśli działasz bez ochrony RAID) lub katastrofalna awaria RAID (jeśli używasz RAID-1 lub RAID-5) spowoduje utratę bazy danych i kopii zapasowych bazy danych.

Twoje pytanie dotyczące wydajności dysku dotyczy tego, jak pełny jest dysk, zależy od sposobu dostępu do danych na dysku. W przypadku wirujących dysków istnieją dwa czynniki fizyczne, które wpływają na wydajność we / wy. Oni są:

• czas wyszukiwania - czas potrzebny na przemieszczenie głowicy dysku z bieżącej pozycji ścieżki do ścieżki zawierającej żądane dane

• opóźnienie obrotowe - czyli średni czas potrzebny do dotarcia pożądanych danych do głowicy odczytu podczas obracania się dysku - dla dysku o prędkości 15 000 obr./min jest to 2 ms (milisekundy)

Stopień zapełnienia dysku może wpłynąć na średni czas wyszukiwania we / wy serwera. Na przykład, jeśli twój dysk jest pełny i masz tabele bazy danych, które są fizycznie zlokalizowane na dysku na skrajnych przeciwnych końcach talerzy dysku, wtedy podczas wykonywania operacji wejścia / wyjścia uzyskując dostęp do danych z każdej z tych tabel, operacje wejścia / wyjścia będą występować maksymalny czas wyszukiwania dysku.

Biorąc to jednak pod uwagę, jeśli dysk jest pełny, a aplikacja uzyskuje dostęp tylko do niewielkiej części danych przechowywanych na dysku, a wszystkie te dane są zlokalizowane w sposób ciągły na dysku, to na te operacje wejścia / wyjścia będzie miał minimalny wpływ czas wyszukiwania .

Niestety odpowiedź na to pytanie brzmi: „Twój przebieg będzie się różnić”, co oznacza, że ​​sposób, w jaki twoja aplikacja uzyskuje dostęp do danych i gdzie te dane się znajdują, określi, jaka będzie twoja wydajność We / Wy.

Ponadto, jak wspomniano w @gravyface, najlepszym rozwiązaniem byłoby oddzielenie wymagań dotyczących pamięci systemu operacyjnego od bazy danych. Ponownie, pomogłoby to zminimalizować ruch głowicy na powierzchni dysku, ponieważ posiadanie obu na tym samym dysku może powodować ciągłe wyszukiwanie między systemem operacyjnym a obszarami bazy danych napędu, ponieważ zarówno system operacyjny, jak i oprogramowanie bazy danych wysyłają żądania We / Wy.

Należy wziąć pod uwagę dwa punkty widzenia: wydajność i wytrzymałość.

Jeśli chodzi o wydajność, ogólnie zaleca się posiadanie osobnych wrzecion dyskowych (lub grup RAID / zestawów dysków) dla:

1. Rzeczy dotyczące systemu operacyjnego (pliki binarne, dzienniki, katalogi domowe itp.)
2. Zamień przestrzeń (którą można połączyć z (1), jeśli nie spodziewasz się użyć zamiany)
3. Produkcja DB
4. Dzienniki transakcji DB produkcji (jeśli są używane)
5. Zrzuty bazy danych / kopie zapasowe

Powód tego jest dość prosty: nie chcesz, aby wydajność bazy danych wpływała na „inne rzeczy” wymagające dysku (np. Jeśli maszyna zaczyna intensywnie zamieniać, a partycja wymiany znajduje się po drugiej stronie dysku od danych DB, które długi dysk próbuje się zmagać).

Z punktu widzenia niezawodności chcesz tego samego rodzaju podziału, ale z innego powodu: jak zauważyli inni, nie chcesz, aby uszkodzony dysk zabierał zarówno twoją bazę danych, jak i jej kopie zapasowe (choć realistycznie powinieneś kopiować kopie zapasowe serwer i tak w przypadku katastrofalnej awarii).

Chcesz także uniknąć jakiejkolwiek konfiguracji z monolityczną /partycją, która zawiera wszystko - jest to niefortunny, tragiczny i alarmująco częsty błąd popełniany w świecie Linuksa, który nie jest współdzielony przez inne systemy uniksopodobne.
Jak Gravyface wspomniał w swoim komentarzu, jeśli uda ci się jakoś zapełnić /system, prawie na pewno się zawiesi, a czyszczenie / odzyskiwanie może być czasochłonne i kosztowne, jeśli system ma jedną /partycję zamiast dobrze zorganizowanej hierarchii punktów montowania.

Polecam przeniesienie bazy danych i tymczasowych (patrz poniżej) kopii zapasowych na inną partycję niż root (/).

Wymyśl także rozsądny schemat rotacji / przechowywania dla (zakładanych) skompresowanych kopii zapasowych zrzutu bazy danych. (Zwykle) nie ma powodu, aby przechowywać tyle kopii zapasowych na dysku lokalnym. Nie robi nic w przypadku odzyskiwania po awarii i po przeniesieniu poza miejsce powinno zostać usunięte z dysku.

To prawie standardowa procedura operacyjna.

Przypomniało mi to błąd w NetApp, w którym systemy plików, które są prawie pełne, znacznie spadły (podobnie jak połowa). (co prawda było to kilka lat temu).

Odpowiedź, jak wszyscy mówili, jest zależna, ale warto ją przemyśleć.

Główną wadą pełnych systemów plików jest lista wolnych i-węzłów, które prawdopodobnie zostaną rozdrobnione i wszędzie.

Istnieją trzy typy danych, które znajdują się na dysku twardym dla bazy danych.

1. Twój aktualny plik bazy danych. Będzie to duży wstępnie przydzielony plik, który zwykle rośnie w dużych porcjach (na przykład 10%).
2. Dzienniki, dziennik transakcji, który jest stale zapisywany, usuwany, zapisywany itp.
3. Pliki tymczasowe dla dużych zapytań, których nie można uruchomić w pamięci.

(1) potrzebuje tylko wolnego miejsca przy przydzielaniu większej ilości miejsca dla zestawu plików. Jeśli baza danych nie rośnie, system plików z małą ilością miejsca na dysku nie powinien na nią wpływać. Jeśli jednak alokuje, może poprosić o bardzo dużą porcję, która nie mieści się w żadnej wolnej liście, którą od razu dzielisz bazę danych i powoduje wyszukiwanie, gdy potrzebuje danych do przygotowania do pamięci.

(2) naiwne usprawnianie dzienników, w których wykorzystuje system operacyjny do zarządzania przydzielaniem miejsca i usuwanie go ucierpi. Zakładając, że baza danych nie jest tylko do odczytu, będzie istniał stały strumień dzienników, często będą one fragmentowane na małej ilości miejsca na dysku twardym. Ostatecznie wpłynie to negatywnie na wydajność zapisu.

(3) tempDB, jeśli DB potrzebuje go do tandetnych zapisanych zapytań lub niewystarczającej ilości pamięci RAM, to masz większe problemy niż mało miejsca na dysku powodujące problemy z wydajnością, ponieważ nawet twoja wydajność odczytu może zostać związana z dyskiem. Ryzykujesz także awarię, jeśli MySql będzie musiał przydzielić miejsce na dysku dla tempDB i zabraknie dysku twardego.

Informacje o kopiach zapasowych ...

1. Każde przedsiębiorstwo, w którym pracowałem, wykonuje kopie zapasowe na tym samym komputerze. Jeśli chodzi o przywracanie (kto dba o kopie zapasowe, liczą się przywracanie). Nic nie przekroczy prędkości pliku db na tym samym dysku.
2. Mamy nadzieję, że to oczywiste, upewnij się, że kopie zapasowe są nie tylko lokalne.

W skrócie powiedziałbym, że przeżyjesz, pod warunkiem, że twoja baza danych nie jest ciężka. Jeśli tak, problem stanowi mała ilość miejsca na dysku. Ale gdybym był tobą, pracowałbym nad następującymi raczej wcześniej niż później.

1. Potwierdzenie, że mam wystarczającą ilość pamięci RAM
2. Segregowanie dzienników i wszystkich danych przejściowych z bazy danych.
3. Segregując system operacyjny, instalujesz MySql od pozostałej części.

Użyj oddzielnych wrzecion i kontrolerów, jeśli możesz dla 1.

Następnie oddzielne wrzeciona

Następnie oddzielne przegrody biednego człowieka.

Miałem podobny problem ostatnio, kiedy zużyłem całe miejsce na dysku na jednym z moich serwerów replikacji. Natychmiastowym skutkiem było zawieszenie się replikacji, a następnie nie mogłem zalogować się do MySQL, ponieważ nie można otworzyć pliku mysqld.sock.