Project

General

Profile

Scénario #21151

MySQL doit être configuré afin de limiter les effets d’accroissement de ibdata1

Added by arnaud grossir about 4 years ago. Updated over 3 years ago.

Status:
Terminé (Sprint)
Priority:
Normal
Assigned To:
Category:
Version majeure
Start date:
09/11/2017
Due date:
09/29/2017
% Done:

100%

Estimated time:
(Total: 6.00 h)
Spent time:
(Total: 7.75 h)
Story points:
2.0
Remaining (hours):
0.00 hour
Velocity based estimate:
Release:
Release relationship:
Auto

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


Subtasks

Tâche #21334: Test de la solution proposée en https://dba.stackexchange.com/questions/8982/what-is-the-best-way-to-reduce-the-size-of-ibdata-in-mysql/8983#8983FerméLaurent Flori


Related issues

Related to Distribution EOLE - Tâche #19392: Scribe - partionnement auto de /var Fermé 02/27/2017
Related to Distribution EOLE - Scénario #21175: Le partitionnement des modules EOLE doit être un paramétrage dans GenConfig Partiellement Réalisé 09/22/2017 09/29/2017

History

#1 Updated by Daniel Dehennin about 4 years ago

  • Assigned To set to Daniel Dehennin

Toutes les références que je trouve parle de :

  1. Sauvegarder toutes les bases sauf mysql et performance_schema
  2. Supprimer toutes les bases sauf les deux plus haut
  3. Arrêter MySQL
  4. Supprimer les fichiers ibdata1 et ib_log
  5. Démarrer MySQL
  6. 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.

#3 Updated by Daniel Dehennin about 4 years ago

  • Tracker changed from Demande to Proposition Scénario
  • Project changed from Scribe to eole-mysql
  • Subject changed from partition /var saturée par mysql to MySQL doit être configuré afin de limiter les effets d’accroissement de ibdata1
  • Description updated (diff)
  • Assigned To deleted (Daniel Dehennin)

#4 Updated by Daniel Dehennin about 4 years ago

  • Category set to Version majeure

#5 Updated by Daniel Dehennin about 4 years ago

  • Related to Tâche #19392: Scribe - partionnement auto de /var added

#6 Updated by Daniel Dehennin about 4 years ago

  • Related to Scénario #21175: Le partitionnement des modules EOLE doit être un paramétrage dans GenConfig added

#7 Updated by Daniel Dehennin about 4 years ago

  • Tracker changed from Proposition Scénario to Scénario
  • Due date set to 09/29/2017
  • Target version set to sprint 2017 37-39 Equipe MENSR
  • Start date set to 09/11/2017
  • Release set to EOLE 2.6.2

#8 Updated by Scrum Master about 4 years ago

  • Story points set to 2.0
  • template 2.6.2
  • errata avec procédure
  • doc / FAQ

Intervenants :

  • Daniel
  • Laurent

#9 Updated by Scrum Master about 4 years ago

  • Assigned To set to Daniel Dehennin

#10 Updated by Daniel Dehennin about 4 years ago

  • Description updated (diff)

#11 Updated by Joël Cuissinat almost 4 years ago

  • Status changed from Nouveau to Terminé (Sprint)

#14 Updated by Laurent Flori over 3 years ago

La solution a été testée et validée dans la demande https://dev-eole.ac-dijon.fr/issues/21334

Also available in: Atom PDF