Data prune not working for MySQL?

Questions
,
1

Hello community!

Is the config to prune data is working for MySQL database?

I’ve seen that the database is big (7.2GB in less than a month). So after searching, I’ve find data prune in the documentation (https://docs.n8n.io/reference/configuration.html#prune-data).
But after setting it up in my Docker-compose file (with a short timeout to test it), no prune is running on my MySQL database (container restarted with the new config 4 hours ago).

I’ve check with “export” command inside the container and setting is well applied:
declare -x EXECUTIONS_DATA_MAX_AGE="168"
declare -x EXECUTIONS_DATA_PRUNE="true"
declare -x EXECUTIONS_DATA_PRUNE_TIMEOUT="60"

Thanks :slight_smile:

2

Are you sure that the prune did not run? Or did you only check the database size?

So is it possible that the prune did run, and all the data got deleted but you did not realize because the file size did not change? Because do not know how it works in MySQL but many databases do only free up disk space after running VACUUM.

3

MySQL database size instantly decreases after deletion, It’s not like SQLite

4

I was comparing the number of entries into the table to check and the size was not reduced.
I have manually deleted some lines where the value “startedAt” was set to “null” and now it seems to prune properly.

I will reduce the “MAX_AGE” to check.

EDIT: yes it’s OK now. Maybe these line with “null” for “startedAt” was blocking the process.

5

Thanks for the info @Damian_K !

It really looks like there is something wrong @Elpatii! We will check it out next week and then get back to you.

6

In fact, I think the process relates to “stoppedAt” value: I’ve reduced the maximum age to 48 hours and after a restart of the container, my number of entries was dropped from 20xxx to 6xxx.
But if I check first line, the value “startAt” is older than 48 hours, but the “stoppedAt” value is “null” (and it’s workflow related where status of execution is “Unknown” to get closer of my other post).

Anyway, I will delete these lines manually.
Thanks @jan!

7

I checked before with a new MySQL database (version 5). For me the query, which is supposed to delete the execution, fails and the error does not get displayed by default. We will look into both.

The null values is something else we will check.

8

I was looking through the submitted workflows and noticed someone fixed this issue with a workflow haha

9

I had the same problem.
When you activate the purge, the system delete all lines that have to be purged but the space is still allocated to the database (even in mariadb). I did OPTIMISE TABLE execution_entity; And it did the job for me.