Rudder

Hi Kévin,

Thank you for your ticket.
I've never seen such large disk usage for table nodes, so there is definitively something odd here
The goal of table "nodes" is to store historical data for nodes, like knowing the name of nodes at certain time, or being able to know that there was a node with this name in the past - it is used mainly for the eventlogs
So, you should be able to delete old entries, but to be safe I wouldn't delete any entries younger than 1 or 2 months.

As for nodes_infos, this stores the config_ids that are still relevant (so all thoses with a current value), and are purged when a new config id appears.
There's a catch here: it seems that nodes_infos for deleted nodes are never purged (at least on my test system) - could it be that you deleted a lot lot of nodes?

If you run
select count(*) from nodes_infos;
you should have 113 result (one per node) - how many do you have ?

Hello Nicolas,

In fact, we added and deleted some nodes up to 10 in total (if my memory serves me right).

Does the fact that some node are switched on/off (for maintenance operations, like adding RAM/ROM to the VM) has some impact?

For your questions :

rudder=# select count(*) from nodes_info;
 count
-------
   113
(1 ligne)

For the deletion ... since it's a production environment, I request an overview :

DELETE FROM nodes WHERE endtime < (now() - interval '2 months');

But for `nodes_info` .. how can I clean this table, without breaking the history ?

In the worst case, since I stopped the service, I thought of deleting all informations related to the nodes (and nothing else : I want to keep the directive/rules/... setup), then re-accept the nodes afterwards.
For this worst case scenario, is there a way to do this cleanly?

A bit a data-exploration in the `nodes_info` table gave me that my oldests nodes all have a tremendeous amount of infos in their config_ids field.
I thought of keeping only the first and last entry of the given array. Is that a good way ?

Warm regards,

Thank you for your answer; i'm still strugling to understang why nodes_infos would be so large
which version of rudder are you using ?

We are using version 5.0.4 at the moment.
I plan to update once the database will have been cleaned.

For nodes_info, you can safely purge all old data (old data == older than one agent run, except the latest entry).
If you even agree to have compliance unknown for the lenght of an agent run, you can truncate table nodes_info, and trigger a full generation - that would be much easier

Deleting the nodes wouldn't help you here.
Once you'll update to 5.0.12 or later, you'll also have better cleaning of old data (especially in the ldap directory)

Hello,

Sorry for the late answer.
I will to the truncate action on the `nodes_info` table, and trigger the full regeneration (clearing the policy cache), this afternoon.

Regards,