Event db pruning

[jennijuju]

Currently, there isn't ant event db management tooling for users.

I think two things that could be nice to add

1. a cli allows one to do ./lotus indexes prune-event similar to ./lotus-shed indexes prune-msgindex
2. auto pruning based on user config? i.e: MaxEventHistory; MaxEventDbSize ..?

[jennijuju]

@rvagg @Stebalien wondering what you think makes sense

[rvagg]

I'd like to see some stats on what this looks like on nodes that have been running some time, even the whole time we've been generating events.

My node, which I think is only a couple of weeks since I started fresh looks like this:

-rw-r--r-- 1 lotus lotus 190M Mar  5 15:49 events.db
-rw-r--r-- 1 lotus lotus  32K Mar  5 16:03 events.db-shm
-rw-r--r-- 1 lotus lotus  32M Mar  5 16:04 events.db-wal
-rw-r--r-- 1 lotus lotus  30M Mar  5 15:50 txhash.db
-rw-r--r-- 1 lotus lotus  32K Mar  5 16:03 txhash.db-shm
-rw-r--r-- 1 lotus lotus  32M Mar  5 16:04 txhash.db-wal

So assuming the write-ahead log doesn't grow too much more than this, that's maybe 13M per day for events and maybe 2M per day for txhash.

@rjan90 @TippyFlitsUK care to share some older ~/.lotus/sqlite/ sizes?

We're also planning on adding at at least a table to the db, and probably indexing that too, which will increase it slightly again. #11640

[Stebalien]

My database that has been running (off and on) since last July is ~2GiB total (a little over 2GiB for transaction hashes). Pruning these doesn't seem like a priority, IMO.

[Stebalien]

So, there's actually a reason to do this: consistency. Right now, we may events but no longer have the associated messages due to splitstore compaction, which leads to issues like #11117. We should probably trim the index after performing splitstore compaction.