Truncated Data Persistence Issue: Reappearance After Aerospike Node Restart

I’m currently facing an issue in our Aerospike cluster where truncated data seems to reappear after a node restart. I’ve tried various steps, including adjusting defragmentation settings and manually triggering defragmentation, but the problem persists

Environment Details:

Aerospike Community Edition version: 5.7.0.17 Replication Factor: 2

Observations:

Truncated data reappears after a node restart. No error or warning messages in the Aerospike logs during the process.

Questions:

1.Why is the truncated data not being removed from the disk file, and what steps can be taken to ensure that the disk space is immediately reclaimed after truncating a table?

2.Why does truncated data reappear after an Aerospike node restart?

Any insights or recommendations on resolving this issue would be greatly appreciated. Thank you!

Aerospike Admin Live Cluster Mode Commands | Aerospike Documentation Truncate is durable in Enterprise Edition only. If you don’t want the records to come back in Community Edition, one way is to wipe the devices before adding the node back in and let “good” data migrate in from the rest of the nodes in the cluster. Or don’t use truncate. Use records with namespace default-ttl set as appropriate with your data model and let the records expire naturally.

1 Like

Thank you for the valuable insight!

1 Like