Scénario #21151
MySQL doit être configuré afin de limiter les effets d’accroissement de ibdata1
100%
Description
Problème¶
Après un certain temps, le fichier /var/lib/mysql/ibdata1
grossi de façon considérable sans possibilité simple de correction, ce qui sature la partition /var
.
Proposition¶
Nous devrions configurer MySQL comme indiqué dans une réponse StackExchange DBA
Critères d’acceptation¶
La configuration de MySQL créer un fichier ibdata1 par base de données.
Demande initiale¶
Bonjour,
Nous constatons, en cette rentrée, des saturations de la partition /var (100%) sur plusieurs de nos scribes en version 2.5
Après recherches, il s'avère que la source de cette saturation provient du fichier /var/lib/mysql/ibdata1 qui grossi sans cesse.
Une fois /var saturé, beaucoup de services ne fonctionnent plus (phénomène bien connu), rendant le serveur non opérationnel.
Le partitionnement du serveur scribe est le partitionnement automatique proposé lors de l'installation, aucune modification de notre part. De même, la configuration de mysql est celle par défaut (bases en innodb, un seul fichier: ibdata1)
Pour revenir à un état fonctionnel, nous n'avons trouvé pour l'instant que cette méthode:
- déplacer /var/lib/mysql sur une autre partition
- exporter les bases / supprimer ibdata1 & ib_logfile* / ré-importer les bases
(ce qui pourrait être considéré comme un équivalent de "vacuum" des tables, à priori pas possible en innodb)
- redéposer le dossier mysql dans /var/lib
Cette solution nous a permit de gagner de l'espace sur le fichier ibdata1, libérant ainsi un peu /var.
Toutefois, elle ne peut être considérée comme perenne.
Le fichier continue de grossir et d'ici une ou deux semaines, nous allons être confrontés de nouveau au problème. Et cela risque de s'étendre, dans des délais plus ou moins proches, à l'ensemble de nos serveur scribe 2.5
Par exemple, sur une partition /var de 8.2 Go (partitionnement automatique) remplie à 100%, ibdata1 pèse 3.25 Go.
Après la manipulation décrite plus haut, on libère 600 Mo, ce qui n'est pas énorme et ne tiendra pas à moyen terme...
Nous pensons que bareos est, à priori, la source de nos soucis: ses enregistrements se comptent en centaines de milliers (voire en millions dans certains établissements). A chaque suppression d'enregistrement, le fichier ne s'optimise pas et donc grossit sans cesse dans des proportions assez importante par rapport à la taille de la partition.
Nous aimerions savoir s'il existe, de votre côté, des solutions ou des préconisations pour résoudre ce problème de base mysql innodb qui grossit sans cesse et qui sature /var.
Merci d'avance
Sous-tâches
Demandes liées
Historique
#1 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Assigné à mis à Daniel Dehennin
Toutes les références que je trouve parle de :
- Sauvegarder toutes les bases sauf
mysql
etperformance_schema
- Supprimer toutes les bases sauf les deux plus haut
- Arrêter MySQL
- Supprimer les fichiers
ibdata1
etib_log
- Démarrer MySQL
- Restaurer la sauvegarde
Il n’est pas possible de limiter la taille de ce fichier, de ce fait, peu importe la taille da la partition /var
, si MySQL est utilisé, alors un jour ou l’autre /var
sera plein.
#2 Mis à jour par Daniel Dehennin il y a plus de 6 ans
J’ai peut-être trouvé de quoi limiter les effets :
#3 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Tracker changé de Demande à Proposition Scénario
- Projet changé de Scribe à eole-mysql
- Sujet changé de partition /var saturée par mysql à MySQL doit être configuré afin de limiter les effets d’accroissement de ibdata1
- Description mis à jour (diff)
- Assigné à
Daniel Dehenninsupprimé
#4 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Catégorie mis à Version majeure
#5 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Lié à Tâche #19392: Scribe - partionnement auto de /var ajouté
#6 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Lié à Scénario #21175: Le partitionnement des modules EOLE doit être un paramétrage dans GenConfig ajouté
#7 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Tracker changé de Proposition Scénario à Scénario
- Echéance mis à 29/09/2017
- Version cible mis à sprint 2017 37-39 Equipe MENSR
- Début mis à 11/09/2017
- Release mis à EOLE 2.6.2
#8 Mis à jour par Scrum Master il y a plus de 6 ans
- Points de scénarios mis à 2.0
- template 2.6.2
- errata avec procédure
- doc / FAQ
Intervenants :
- Daniel
- Laurent
#9 Mis à jour par Scrum Master il y a plus de 6 ans
- Assigné à mis à Daniel Dehennin
#10 Mis à jour par Daniel Dehennin il y a plus de 6 ans
- Description mis à jour (diff)
#11 Mis à jour par Joël Cuissinat il y a plus de 6 ans
- Statut changé de Nouveau à Terminé (Sprint)
#14 Mis à jour par Laurent Flori il y a plus de 6 ans
La solution a été testée et validée dans la demande https://dev-eole.ac-dijon.fr/issues/21334