Feature Req: Create a Helper application to help users migrate away from journal_metadata

[Drew]

Is your feature request related to a problem? Please describe.

Historical information:

The use of a Journal_Metadata table in Akka.Persistence.Sql.Common is a legacy of it's design based on leveldb.

akka-persistence-jdbc (upon which this is based) does not use such a table; Journal sequence numbers are instead read off the last deleted row (which is kept in the table regardless of soft-delete setting, with IsDeleted set to true/1)

Akka.Persistence.Linq2Db currently has a compatibility mode for this, to allow users to still achieve most of the benefits of Akka.Persistence.Linq2Db's architecture without losing their existing journal table (and moving back if needed.)

Drawbacks to journal_metadata

However, in this mode there are still drawbacks, as it means deletes must do 2 writes to journal (update IsDeleted, delete all but last soft deleted record) as well as a write to journal_metadata, all in one transaction. Under heavy load in prod where a lot of deletions are happening (think at-least-once-delivery type buffers that are transient and have lots of churn) you can still have some issues around deletions getting in the way of other writes.

Crux of the issue:

And as noted in #67 and #68 , if a tag table is to be used, an additional table will be involved in the transaction.

For best results, if users are going to use tag tables, they should -not- use sql common compatibility mode.

Once the journal deletes records (thus applying it's delete style to both journal and journal_metadata), you can turn off compatibility mode. However, there is no 'automated' or 'semi-automated' migration to do this

Describe the solution you'd like

I think it would be nice to create a script utility to 'migrate' the journal metadata state over to the new format, similar to the index helper app Proof of concept.

Potential challenges

We may require a 'blank' record to put back into the journal, that if accidentally 'undeleted' (isDeleted set back to false) will not cause an undue recovery failure (or, perhaps, a recovery failure that makes it clear to the users, they should not have done that.)