Est-il mauvais d'avoir un disque dur très plein sur un serveur de base de données à fort trafic?

Exécuter un serveur Ubuntu avec MySQL pour un serveur de base de données de production à fort trafic. Rien d'autre ne s'exécute sur la machine, sauf l'instance MySQL.

Nous stockons des sauvegardes quotidiennes de la base de données sur le serveur de base de données. Y a-t-il un impact sur les performances ou une raison pour laquelle nous devrions garder le disque dur relativement vide? Si le disque est rempli jusqu'à 86% + avec la base de données et toutes les sauvegardes, cela nuit-il aux performances?

Le serveur DB fonctionnant avec une capacité totale de 86 à 90% + fonctionnerait-il moins bien que le serveur fonctionnant avec un disque complet à 10% seulement?

La taille totale du disque sur le serveur est supérieure à 1 To, même 10% du disque devraient suffire pour l'échange de base O / S et autres.

Tout d'abord, vous NE souhaitez PAS conserver vos sauvegardes de base de données sur le même lecteur physique ou groupe RAID que votre base de données. La raison en est qu'une panne de disque (si vous exécutez sans protection RAID) ou une panne RAID catastrophique (si vous utilisez RAID-1 ou RAID-5) vous fera perdre votre base de données et vos sauvegardes de base de données.

Votre question sur les performances du disque concerne le niveau de saturation d'un lecteur de disque en fonction de l'accès aux données sur le disque. Pour les disques en rotation, deux facteurs physiques affectent les performances d'E / S. Elles sont:

• temps de recherche - qui est le temps qu'il faut au lecteur de disque pour déplacer la tête de disque de sa position de piste actuelle vers la piste qui contient les données demandées

• latence de rotation - qui est le temps moyen nécessaire pour que les données souhaitées atteignent la tête de lecture lorsque le lecteur tourne - pour un lecteur à 15 000 tr / min, cela représente 2 ms (millisecondes)

Le niveau de saturation de votre disque peut affecter le temps moyen de recherche des E / S de votre serveur. Par exemple, si votre lecteur est plein et que vous avez des tables de base de données qui sont physiquement situées sur le lecteur aux extrémités opposées des plateaux du disque, alors que vous effectuez des E / S en accédant aux données de chacune de ces tables, ces E / S connaîtront le temps de recherche maximum du lecteur.

Cela étant dit, cependant, si votre lecteur est plein et que votre application n'accède qu'à une petite fraction des données stockées sur le lecteur et que toutes ces données se trouvent de manière contiguë sur le lecteur, ces E / S seront minimisées par le temps de recherche. .

Malheureusement, la réponse à cette question est que "votre kilométrage variera", ce qui signifie que la façon dont votre application accède aux données et où se trouvent ces données déterminera quelles seront vos performances d'E / S.

En outre, comme mentionné par @gravyface, il serait "préférable" de séparer les exigences de stockage de votre système d'exploitation de votre base de données. Encore une fois, cela aiderait à minimiser le mouvement de la tête sur la surface du disque car le fait d'avoir les deux sur le même lecteur pourrait provoquer une recherche constante entre le système d'exploitation et les zones de base de données du lecteur car le système d'exploitation et le logiciel de base de données font des demandes d'E / S.

Il y a deux angles à considérer ici: les performances et la robustesse.

En termes de performances, il est généralement recommandé d'avoir des broches de disque distinctes (ou des groupes / ensembles de disques RAID) pour:

1. Les éléments du système d'exploitation (binaires, journaux, répertoires personnels, etc.)
2. Espace de swap (qui peut être combiné avec (1) si vous ne prévoyez pas d'utiliser le swap)
3. La DB de production
4. Les journaux de transactions de la base de données de production (le cas échéant)
5. Dumps / sauvegardes de base de données

Le raisonnement derrière cela est assez simple: vous ne voulez pas que les performances de la base de données soient affectées par "d'autres choses" exigeant le disque (par exemple, si la machine commence à échanger fortement et que la partition de swap se trouve de l'autre côté du disque à partir des données de base de données que vous avoir un long disque cherche à faire face).

Du point de vue de la robustesse, vous voulez le même type de panne, mais pour une raison différente: comme d'autres l'ont souligné, vous ne voulez pas qu'un disque défectueux supprime à la fois votre base de données et ses sauvegardes (bien qu'en réalité, vous devriez copier les sauvegardes le serveur de toute façon en cas de panne catastrophique).

Vous voulez également éviter toute configuration avec une /partition monolithique qui contient tout - c'est une erreur malheureuse, tragique et alarmante commune au monde Linux qui n'est pas partagée par les autres systèmes de type Unix.
Comme Gravyface l'a mentionné dans son commentaire, si vous parvenez à remplir /votre système d'une manière ou d'une autre, il est presque certain que le système plante et le nettoyage / récupération peut être long et coûteux si le système a une seule /partition plutôt qu'une hiérarchie bien structurée de points de montage.

Je recommanderais de déplacer la base de données et les sauvegardes temporaires (voir ci-dessous) vers une partition différente de la racine (/).

En outre, proposez un schéma de rotation / rétention judicieux pour vos sauvegardes de vidage de base de données compressées (supposées). Il n'y a (généralement) aucune raison de conserver autant de copies des sauvegardes sur le disque local. Ne fait rien pour la récupération après sinistre et lorsqu'il est déplacé hors site, doit être supprimé du disque.

C'est à peu près la procédure d'exploitation standard.

Cela m'a rappelé un bogue sur NetApp où les systèmes de fichiers qui sont presque pleins ont vu leurs performances chuter de manière significative (comme la moitié). (certes, c'était il y a quelques années).

La réponse, comme tout le monde l'a dit, est que cela dépend, mais cela vaut la peine d'y réfléchir.

Le principal inconvénient des systèmes de fichiers complets est la liste des inodes libres susceptibles d'être fragmentés et partout.

Il existe trois types de données qui se trouvent sur le disque dur d'une base de données.

1. Votre fichier de base de données réel. Ce sera un gros fichier préalloué qui se développe généralement en gros morceaux (10% par exemple).
2. Journaux, votre journal des transactions qui est continuellement écrit, supprimé, écrit, etc.
3. Fichiers temporaires pour les requêtes volumineuses qui ne peuvent pas être exécutées en mémoire.

(1) n'a besoin que d'espace libre pour allouer plus d'espace à votre ensemble de fichiers. Si votre base de données ne se développe pas, elle ne devrait pas être affectée par un système de fichiers à faible espace disque. S'il alloue cependant, il pourrait demander un très gros morceau qui ne rentre pas dans une liste gratuite que vous avez immédiatement fragmenté votre base de données et provoqué la recherche quand il a besoin de données à préparer en mémoire.

(2) une impénémentation naïve des journaux où il utilise le système d'exploitation pour gérer l'allocation d'espace et sa suppression en souffrira. En supposant que votre base de données n'est pas en lecture seule, il y aura un flux constant de journaux, ils seront fréquemment fragmentés sur un espace disque faible. En fin de compte, cela nuira à vos performances d'écriture.

(3) tempDB, si la base de données en a besoin pour des requêtes écrites de mauvaise qualité, ou pas assez de RAM, alors vous avez des problèmes plus importants que le faible espace disque entraînant des problèmes de performances car même vos performances de lecture pourraient alors devenir liées au disque. Vous courez également le risque d'une panne si MySql avait besoin d'allouer de l'espace disque pour tempDB et que le disque dur était épuisé.

À propos des sauvegardes ...

1. Chaque entreprise dans laquelle j'ai travaillé conserve des sauvegardes sur la même machine. Quand il s'agit d'une restauration (qui se soucie des sauvegardes, ce sont les restaurations qui comptent). Rien ne va battre la vitesse d'avoir le fichier db sur le même disque.
2. Avec un peu de chance, assurez-vous que les sauvegardes ne sont pas uniquement locales.

En bref, je dirais que vous survivrez à condition que votre base de données ne soit pas lourde en écriture. Si tel est le cas, le faible espace disque est un problème. Mais si j'étais vous, je travaillerais sur les éléments suivants plus tôt que tard.

1. Confirmer que j'ai suffisamment de RAM
2. Séparation des journaux et de toutes les données transitoires de votre base de données.
3. En séparant votre système d'exploitation, votre installation MySql du reste.

Utilisez des broches et des contrôleurs séparés si vous le pouvez pour 1.

Suivi par des broches séparées

Suivi par les partitions séparées d'un pauvre.

J'ai eu un problème similaire récemment lorsque j'ai utilisé tout l'espace disque sur l'un de mes serveurs de réplication. L'effet immédiat a été que la réplication plante et que je n'ai pas pu me connecter à MySQL car le fichier mysqld.sock n'a pas pu être ouvert.