rétention et compaction dans une base de données temporelle

Bonjour,

Le comportement que vous décrivez correspond à une base de données temporelle qui ne déclenche pas correctement la purge automatique des séries expirées. Pour forcer manuellement la compaction et libérer l’espace disque, la méthode dépend du moteur utilisé.

Si vous êtes sur InfluxDB, la rétention est gérée par les retention policies et le moteur TSM. Lorsque les shards expirés ne sont pas supprimés, vous pouvez lancer manuellement la compaction avec :

Code

influxd inspect compact-shards

Cela force la réécriture et la suppression des shards obsolètes. Vous pouvez également exécuter :

Code

influxd inspect delete-expired

afin de supprimer directement les séries dépassant la durée de rétention. Vérifiez ensuite dans le répertoire /var/lib/influxdb/data/<database>/<retention_policy>/ que les fichiers .tsm et .wal ont bien été purgés.

Si vous êtes sur TimescaleDB, la rétention est gérée par les jobs créés via add_retention_policy. Si le job ne s’exécute pas automatiquement, vous pouvez le déclencher manuellement avec :

SQL

SELECT run_job(job_id) 
FROM timescaledb_information.jobs 
WHERE job_type='retention';

Cela lance immédiatement la suppression des chunks dépassant la durée définie. Vous pouvez ensuite contrôler l’espace disque libéré avec pg_total_relation_size sur l’hypertable concernée.

Dans les deux cas, assurez-vous que les droits d’accès du service permettent bien la suppression des fichiers, et que la configuration de la rétention est correcte. Si malgré ces actions la compaction ne libère pas l’espace, il est possible que vous soyez confronté à un bug connu dans la version utilisée. Dans ce cas, la meilleure pratique est de mettre à jour vers la dernière version stable, car plusieurs correctifs ont été apportés sur la gestion de la compaction et du garbage collection.

Je vous recommande de préciser si vous utilisez InfluxDB ou TimescaleDB afin que je puisse vous fournir la commande exacte adaptée à votre environnement.

DV.