Projet

Général

Profil

Scénario #21151

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

Ajouté par arnaud grossir il y a plus de 6 ans. Mis à jour il y a plus de 6 ans.

Statut:
Terminé (Sprint)
Priorité:
Normal
Assigné à:
Catégorie:
Version majeure
Début:
11/09/2017
Echéance:
29/09/2017
% réalisé:

100%

Temps estimé:
(Total: 6.00 h)
Temps passé:
(Total: 7.75 h)
Points de scénarios:
2.0
Restant à faire (heures):
0.00 heure
Estimation basée sur la vélocité:
Release:
Liens avec la release:
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


Sous-tâches

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


Demandes liées

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

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 :

  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 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 Dehennin supprimé

#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

Formats disponibles : Atom PDF