I’m trying to self-host a Ghost 5.0 instance. In any. scenario using docker-compose I get
Error: connect ECONNREFUSED 127.0.0.1:3306
I have tried deploying at local orangepi with Ubuntu and fly.io, with the same results. If with fly the database issue is quite obvious, with pi ubuntu server I just can’t see why such error might appear.
My latest docker-compose.yaml is based upon suggested structure at docker hub.
How to fix container connection?
Having same issue here.
[2022-08-22 11:25:29] INFO Ghost is running in production...
[2022-08-22 11:25:29] INFO Your site is now available on https://davidsha.me/
[2022-08-22 11:25:29] INFO Ctrl+C to shut down
[2022-08-22 11:25:29] INFO Ghost server started in 1.867s
[2022-08-22 11:25:29] ERROR connect ECONNREFUSED 127.0.0.1:3306
connect ECONNREFUSED 127.0.0.1:3306
"Unknown database error"
Error: connect ECONNREFUSED 127.0.0.1:3306
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1247:16)
[2022-08-22 11:25:29] WARN Ghost is shutting down
[2022-08-22 11:25:29] WARN Ghost has shut down
[2022-08-22 11:25:29] WARN Your site is now offline
[2022-08-22 11:25:29] WARN Ghost was running for a few seconds
I’ve got the same issue too.
Exactly the same issue for me too. All three blogs - self hosted - are now down as a result of updating my Docker image to latest.
EDIT: I’m using the alpine image if this helps. I’ve also tried reverting to ghost:5.10-alpine and ghost:5.10.1-alpine and the issue remains. All blogs are still down.
EDIT 2: Have created an issue on GitHub too.
This is because the official Docker image switched the default database to MySQL. I just fixed this on my own blog (now running on 5.10.1, still with SQLite) and wrote a post about it.
SQLite3 is not supported in production from 5.0. The docker image has been belatedly updated to reflect this.
The details of this breaking change are here: BREAKING CHANGE: Switch from sqlite3 to MySQL by default by tianon · Pull Request #323 · docker-library/ghost · GitHub
@maroonmed24 - RE your post:
It bears repeating that running Ghost on SQLite in production is officially unsupported, and that this could stop working at any time if future versions of Ghost implement new features or breaking changes that simply won’t work with SQLite any more. Indeed, you’ll be reminded of this every time you visit the admin panel. However, as Ghost uses knex.js as a database abstraction layer, hopefully this won’t happen anytime soon!
The reason it was done in 5.0 is that we expect sqlite3 to break between now and 6.0. Probably not in a very obvious to understand way.
I completely understand the desire to use sqlite3, especially for hobbyist sites, but if you’re using any of the membership, newsletter or subscription features you should definitely be using MySQL8 from 5.0 onwards.
Thanks for the response, and clarification. I think it would be useful to update Ghost’s self-hosting documentation regarding this change and the upcoming expectation of breakage, if that’s the case. Alternatively, would it be possible to have Ghost forcibly disable the membership, newsletter, subscription, etc. features if it detects sqlite3 being used? It seems that a lot of the hobbyist/small personal blog crowd aren’t actively using this features.
Hi @maroonmed24, I’m not aware of any documentation that is out of date. If you can point me to anything specific, I’d be happy to take a look.
In terms of adding db-related feature flags, this would run counter to much of what we’re trying to achieve. The primary purpose of continuing to support sqlite3 in development mode is to make it super easy to do local and source Ghost installs for theme developers and contributors - we do not want to disable any features for this use case.
Meanwhile, the primary purpose of dropping sqlite3 support in production from 5.0 is because the maintenance overhead of working around sqlite3 limitations had become too big for us to manage. Asking us to add in more code paths is therefore counterintuitive to the intent of us not officially supporting sqlite3.
This is a solution post for above issue with root cause analysis (Atleast in my case) cc: @Hannah
So after updating Ghost to ver.5 and corresponding MySQL to ver. 8. After few days I started getting this issue.
When I analysed the issue further following is my finding and steps to solve the issue:
1. Before upgrading to MySql 8, container memory consumption was ~88% which is now become ~97% (In a 1 GB digital ocean droplet)
2. As per MySql error logs
[InnoDB] page_aligned_alloc mmap(137236480 bytes) failed; errno 12.
That means its trying to have swap memory ~130MB which is not available at that time.
So here the issue was in the droplet there was no swap memory allotted. You can check it by following command:
So to configure swap memory you can do 2 ways.
- Use external disk for swap space
- Use space from your droplet/container for swap space
I used second approach and the steps you can follow like:
- Check your disk space using command
It should have sufficient space
- Create a swapfile using a command. Here 512M is the swap space I am providing for my case. In your case you can increase or decrease it
sudo fallocate -l 512M /swapfile
- Check the swapfile must be created at root with 512M size
sudo ls -lh /swapfile
- Provide only the root to access this swap file
sudo chmod 600 /swapfile
- Now attach swapfile to swap space
sudo mkswap /swapfile
- Finally activate it
sudo swapon /swapfile
Now if I am checking the memory % its total 125% in place of 100% as the swap space is also added.
This swap space will be reverted if you reboot instance. So to make it permanent open following file
sudo vi /etc/fstab
At the bottom add following line
`/swapfile none swap sw 0
For the sake of others In the case of fly.io:
MySQL is not part of Ghost’s docker image, so you need to install it separately, when doing that you realize the real issue: MySQl8 needs a lot more RAM than fly.io offers and what most hosting platforms offer. Bare minimum one seemingly needs 2GB RAM. PS: PlanetScale was also never an option
Conclusion: Hosting Ghost on fly.io’s (free tier) is no longer an option