Skip to main content

Bonjour,

 

Notre base de données devient vraiment volumineuse et difficile à gérer au niveau des backups (+300Go). Nous souhaitons conserver notre rétention par défaut (1 an)

Nous avons l’idée de mettre la table data_bin qui prends 99% de cette espace en COMPRESSION via mariadb

 

ALTER TABLE data_bin PAGE_COMPRESSED=1;

Est ce que Centreon supporte cette modification coté BDD, sensé être totalement transparente coté applicatif ? Nous sommes sur des SSD et les prérequis sont validés.

 

Merci 

Hi @arampon, Please ask your problem in English. This will help all other non-french speaking users who have the same issue to benefit from the solutions that will be proposed. Thank you for your understanding : ) 

Hello

 

Our database size is being critical (more than 300Gb) , specially the data_bin table.

Can we use, on mariadb database side, the compression option ? Is it supported by Centreon application ?

ALTER TABLE data_bin PAGE_COMPRESSED=1;

Thanks 

I’m following

Bonjour @arampon,

je déterre ton ticket car nous sommes dans le même cas (data_bin augmente rapidement). Quel est ton retour d’expérience sur le passage du data_bin en compressed ?

Cordialement 

Hi, 

We have not tested this feature, and do not support it officially, so do it at your own risk. I won’t recommend to do it on a production server.

 

For your information, the data_bin table is used to:

  • feed the MBI storage server on a daily basis
  • regenerate the RRD files ocasionnally (only when triggered by the user)

If your have interest in none of these use cases, you can disable the insertion into data_bin in the central broker output configuration.

Salut,

J’ai fait mes propres tests, je vous partage ici mes conclusions, avec la méthode «Page compression» qui semble être la méthode recommandée.

Les tests ont été fait sur MariaDB 10.5.23

 

Page compression

Cette compression ne fonctionne que pour les nouvelles données ingérées, car elle s’effectue lors de l’écriture des page. Les données déjà présentes, ne seront pas compressées.

Le test à été fait avec un jeux de données de la base «centreon_storage» qui faisait environ 8 Go.

La méthode à été de créer une base «centreon_storage» vide, d’activer la compression sur les tables, et d’injecter les données.

  Espace occupé Espace libre Ratio
Avant injection des données 688M 50G  
Après injection SANS la compréssion 8.1G 42G  
Après injection AVEC la compression 3.0G 47G 37%
 

Un autre test a été fait en dupliquant le flux SQL de C. Broker vers une base «centreon_storage» vide, sur laquelle la compression des tables était activée.

Les données ont été injectées pendant 24h.

Base Taille Ratio
non-compressée 883 Mo  
compressée 369 Mo 41,8%

(J’ai oublié de préciser)

 

Impact sur le serveur

Aucun impact n’a été observé sur le serveur (load, mémoire, i/o, ...), sauf sur le nombre d’opérations/s sur le log de InnoDB, qui est plus important lors des pics réguliers (tout les 1h et ¼ environ).

Les pics sont passé de ~10 à 20 ops/s. Malgré cette augmentation, nombre d’opérations/s sur le log de InnoDB reste très faible en absolu.

Hello,

To give more feedback on this method, we moved to Page Compression on our database 3 months ago, our number of hosts/services is still growing, the database size too.

But the space used is going down.

You can see the impact on the disk I/O of the MariaDB server, on the graphs. The change as been made on mid june.

(Taille DB centreon_storage , is the size of the centreon_storage database)

 

I hope it will help someone.

Reply


Terms & ConditionsCookie settings