Urgent Help Needed: Failed Migration After Docker Restart, Lost Work

Hello Community,

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.

Hey @Benedikt_Bohm,

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.

Hi @Jon , the interfces does not work.
This config im using for the docker stack in portainer:

version: "3.9"

services:
  redis:
    image: bitnami/redis:latest
    restart: unless-stopped
    ports:
      - 6579:6379
    environment:
      REDIS_PASSWORD: ${REDIS_PASSWORD}
  
  n8n-main:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6678:6678
    env_file:
      - stack.env
    command: start

  n8n-webhook:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6680:6678
    env_file:
      - stack.env
    command: webhook

  n8n-worker1:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6690:6678
    env_file:
      - stack.env
    command: worker

  n8n-worker2:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6691:6678
    env_file:
      - stack.env
    command: worker

  n8n-worker3:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6692:6678
    env_file:
      - stack.env
    command: worker

  n8n-worker4:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - 6693:6678
    env_file:
      - stack.env
    command: worker

Ah that is annoying so it would be a case of restoring the backup if it isn’t loading although the n8n ready line suggests it might be which is odd.

I would also maybe look at moving to Postgres once you are in as we will be dropping MySQL support in the future.

I don’t really have a quick way to handle it though, I think the plan you have is probably the best.

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

2 Likes

The new version is really good! Good job n8n Team.
Thank you for your work!!

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.