I inadvertently initiated a migration by restarting Docker instances with the :latest version. Unfortunately, the migration has failed, and here are the relevant logs:
swiftCopy code
2023-07-26T10:18:25.349Z | warn | Migrations in progress, please do NOT stop the process. "{ file: 'migrationHelpers.js', function: 'logMigrationStart' }"
2023-07-26T10:18:25.349Z | debug | Starting migration MigrateIntegerKeysToString1690000000001 "{ file: 'migrationHelpers.js', function: 'logMigrationStart' }"
2023-07-26T10:18:28.787Z | error | Last session crashed "{ file: 'CrashJournal.js', function: 'init' }"
2023-07-26T10:18:38.910Z | debug | Lazy Loading credentials and nodes from n8n-nodes-base "{\n credentials: 317,\n nodes: 423,\n file: 'DirectoryLoader.js',\n function: 'loadAll'\n}"
n8n ready on 0.0.0.0, port 6678
Regrettably, my last backup could only be performed four days ago since the server storage was too full.
At this point, I am in desperate need of insights on how I could restore as much of the work as possible.
Here’s a potential solution I’ve thought of, though it may be overly complicated:
Make a backup of the current database now
Restore the backup from four days ago
Start an update and hope everything works
Manually copy workflow scripts from the old MySQL database into the new instance
I suspect the issue with the current database, which I would like to keep because much work was invested in scripts, is that the migration failed due to the logging of all executions, which amounts to approximately 50GB in size and n8n running with several worker instances.
What do you think would be the most sensible and time-saving process after several things didn’t go as they should have?
I am grateful for any assistance you can provide. Thank you in advance.
That looks like the migration did work as n8n has started which is handy, Assuming you are able to access the interface of n8n it could just be a permission issue and running through the migration guide for v1 could help.
There is a simple solution to migrate mysql workflows to a new n8n postgres instance if the update fails.
it works over the n8n api and a mysql connection to the old database