I use this way to upgrade for a long time, and it works perfectly.
I used version 0.234.1 before I upgrade this time(0.236.1), but I cannot enter the system
and it always shows “n8n is starting up. Please wait”
This is my docker-compose.yml file, I don’t know if I changed something by mistake?
Please help! Thanks!
Thanks so much for sharing your Docker compose file - would you happen to have any logs you could share, as well? That might help us troubleshoot with you!
I don’t think anything in particular is wrong here - the version you’re upgrading to has a mandatory database migration, and if you have a particularly large database, it’s going to take some time Taking a look at your screenshot, there’s some progress, for example:
...LIMIT 381170, 10
...LIMIT 381500, 10
The Select syntax in SQLite is SELECT columns FROM table LIMIT offset, count; - you can see this in the screenshot, as n8n is fetching 10 rows starting at row 381170 to migrate. The next (slow) query has it fetching 10 rows starting at 381500, so there’s progress.
You’ll likely need to run this for quite a bit, but it’s working as intended!
I’m having a similar issue here. My logs have been stuck for the past hour, and I see almost constant 99% CPU usage on the host machine. Any help or update here would be super appreciated.
What @EmeraldHerald said is right, n8n is copying 10 executions at a time in order to optimize the execution table.
I wouldn’t recommend stopping the migration if it’s still running; it’s progressing, although slowly.
In case you have already stopped it, your data might be corrupt, but if not, you can simply choose to empty the execution_entity table and it would greatly reduce the amount of data to be transferred, causing your migration to be almost instant instead.
I have exactly the same problem. Unfortunately I do not know which version I had before. But my database is 2,5Gb. and I get the following log:
root@Ubuntu-Server:~# docker-compose logs
Attaching to root_n8n_1, root_traefik_1
n8n_1 | License manager not initialized
n8n_1 | Last session crashed
n8n_1 | n8n ready on 0.0.0.0, port 5678
n8n_1 | Migrations in progress, please do NOT stop the process.
n8n_1 | Pruning was requested, but was not enabled
n8n_1 |
n8n_1 | Stopping n8n…
n8n_1 | License manager not initialized
n8n_1 | Last session crashed
n8n_1 | n8n ready on 0.0.0.0, port 5678
n8n_1 | Migrations in progress, please do NOT stop the process.
n8n_1 | Pruning was requested, but was not enabled
traefik_1 | time=“2023-07-21T16:11:23Z” level=info msg=“Configuration loaded from flags.”
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“accept tcp [::]:443: use of closed network connection” entryPointName=websecure
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“accept tcp [::]:8080: use of closed network connection” entryPointName=traefik
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“close tcp [::]:8080: use of closed network connection” entryPointName=traefik
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“close tcp [::]:443: use of closed network connection” entryPointName=websecure
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“accept tcp [::]:80: use of closed network connection” entryPointName=web
traefik_1 | time=“2023-07-21T16:20:19Z” level=error msg=“close tcp [::]:80: use of closed network connection” entryPointName=web
traefik_1 | time=“2023-07-21T16:27:09Z” level=info msg=“Configuration loaded from flags.”
I have stopped and restarted docker several times and my CPU usage is also at 100%. I find this very unusual. because that was never the vall that it took so long. Should I just delete all the data in the table ‘execution_entity’? There are 322172 rows.
Because I have been unable to upgrade smoothly before, I have re-operated the upgrade steps. The syntax is as follows:
# Stop current setup
sudo docker-compose stop
# Delete it (will only delete the docker-containers, data is stored separately)
sudo docker-compose rm
# Then start it again
sudo docker-compose up -d
It has been five days since the first time I posted an inquiry, should I give up?
If I am willing to abandon the previous workflows, is there any way to quickly restart the service?
@Markus08 If you can afford deleting the data in the execution_entity, that would certainly cause the migration to run instantly. It’s worth trying.
Lastly, if you don’t mind losing executions, another possible approach is:
Stop n8n
Export workflows and credentials using the CLI commands as shown here
Rename your database.sqlite file to something else to serve as a backup
Run the Import commands using the instructions in the link above - n8n will create a new database.sqlite file and import those workflows and credentials there
Start n8n
This is a way of continuing to use n8n without losing workflows and credentials.
I downloaded the .sglite file from the server and opened it in SQLite Studio on Windows. Then I used a query to delete all executions except the last 100. I had ChatGPT create the query because I don’t know how to write and create it properly. Then I still used a query command ‘VACUUM;’ to minify the database. Because it was, despite the deleted Executions entries, still 2,5Gb big. After downsizing, the database was then only 5MB in size.
After replacing the .sqlite file with the existing file on the server, I restarted Docker. But the server load was still at 100% and nothing happened. Then I deleted the last row of the migration table in the database. And then the update worked immediately and my n8n installation was still accessible through the web browser. All workflows and settings were still available.
I worked on this for almost 6 hours until I found the solution. I was very relieved that I had not lost my data.
Is it actually possible to set n8n to save only a maximum of 100 executions per workflow? So that everything older than entry 100 is automatically deleted? And that the database is continuously reduced automatically?
Around n8n updates and backups, there is still a lot of potential for improvement.
My suggestion would be to create another web environment next to the regular n8n installation. Maybe with a separate Docker container. This environment is then only responsible for the updates and backups and can be completely controlled via the browser. This environment monitors the update and constantly checks if the n8n installation is running correctly. Especially for critical updates, it would be advantageous if this watchdog application then creates a backup and performs the update. If something goes wrong here, it can be informed in the browser. So the whole thing can be canceled or restarted.
Not everyone is a programmer and understands how n8n and Linux works.
Another improvement would be if an n8n update is first performed in parallel to the running n8n installation in a newly created Docker container. As soon as this is done successfully, the new Docker container installation is transferred to the old one. Then the executions that have occurred in the meantime are transferred to the new update database, so that there is no gap in the execution history.
Because an n8n update that takes several hours is not acceptable. Our n8n workflows must be available 14/7. An update where n8n is not available for such a long time is a very big problem.
What do you think about my suggestions?
To anyone that it might help. I just let this run over the weekend per the advice of the guys from the n8n Team, and it took over 48 hours, but the migration did finish and n8n was able to start fine. My docker logs would go 5-6 hours between logging an update from the migration, so it really does seem like nothing is happening.
In the steps you outlined, you mentioned to Stop n8n at the first step. Once I stop n8n running, and then trying to export the the workflows and credentials, I get the error - Error response from daemon: Container b4092a1a275fd6577c0b46a7da5ce41f198bc18881f4790d6ea9bdce20cf0e8b is not running
Can you elaborate further on the right way of stopping n8n?
I’m a big noob on this - so apologies in advance if this sounds trivial
@Markus08 this is def a good idea, the auto update mechanism certainly could be improved; for now we strongly suggest backing up your database before migrating as this is the sensible part usually. We try our best to make upgrading as easy as possible by testing the upgrade process multiple times, but sometimes we need to make big, fundamental changes, and in those situations upgrading may be hard.
@kevintee What you are facing is actually expected, once you stop n8n you won’t be able to run commands against it. Have you mapped the n8n’s folder to your local machine? If so, I would expect you to be able to see the .n8n folder inside your user’s home folder.
If so, you don’t need docker to run the commands; you can simply run npx [email protected] export:workflow and then similar to export credentials.
Sorry you’re running into this!
Taking a look at your screenshot, there’s some progress, for example:
