New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Hetzner or netcup
WHERE?
EUROPE, USA, CANADA.
skynet
Be sure to back up your data frequently. Everything else can be used for production.
Yes, but I don't want to have downtimes frequently.. And it is important that support will react quickly to any issues.
@greencoludvps @AlexBarakov @hosthatch @kuroit
greencloudvps banned?
oh that's someone else ig -- the main person (owner of gcvps) is @NDTN
Why not have multiple providers with a DNS fail over?
@Calin
Waiting for next LET deal
Absolutely. I have 7 haproxy frontends pointing to 4 web mirrors and 5 webapp back-ends. Of these, 3 are "live" at any time, in that they have DNS records pointing at them, which are also served by 4 DNS servers with a low TTL.
If any live frontend server goes down, maybe a client will have a slow first connection, but otherwise nothing too bad as they'll soon try one of the other IPs, and I can easily update the DNS to switch out a problematic frontend with one of the others if it stays down longer term.
As such, I'm not really too bothered if any single provider goes down.
try ihostart, they have the best uptime.
maybe @Calin can hook you up with a spicy discount 🫦😝👅
This is the way.
For production I use
Hetzner - stable for 5 year with them
hosthatch - new use
OVH dedicated - main website (new use) one reboot and offline 30min !!
greencloudvps- for small website
Netcup - small website
Oops, my bad...wrong link, correct one was given above.
OVH, Hetzner
Hello,
We have locations in London, USA, Frankfurt, and Poland
We use Ryzen 9950x. If you have any questions, we're here to help
How do you handle databases?
EU 🇪🇺
OVH/Hetzner/Clouvider/AlphaVPS
US 🇺🇸
Clouvider/GTHost
CA 🇨🇦
OVH/GTHost
What
Maybe @gigahost is also a good choice
I recommend @Hetzner_OL or Premium @berohost
Had a long time OVH & Scaleway, but never more recommend them.
one reboot and offline 30min !!!
Bro never used a dedi before:(
Everything happens for the first time one in your life)
But I didn’t blame OVH for it even the first time!
I use sqlite3 and (for now) litefs to replicate it. Longer term, I'd like to change this to a custom implementation as it feels a bit clunky when it errors, but fortunately that doesn't seem happen too often.
I've architected my web-app essentially as a message passing system so each edge node has its own database for new records from the client, which are then replicated to the servers automatically with litefs. There's a single writer thread on each edge node so there's no write contention, although if load increases in the future I might switch this to multiple writer threads, each with their own database.
The central server copies all the records it doesn't already have into the master database, and again there's a single writer so there's no write contention. This is replicated back to the edge nodes again using litefs. There are actually multiple central servers, one per dedi, and they use litefs/consul to make sure one of them is the leader, which provides redundancy on the server-side.
Once the master database is propagated back to the edge nodes, multiple reader threads can access it concurrently without locking. Additionally, the writer threads periodically delete old records that it sees have been copied to the master database, although I leave them in the spool for about a week to provide additional backups.
On all the central servers, every database, client or master, is dumped to text using
.dumponce an hour, and I keep a whole week of such dump files. These are backed up using borgbackup (to 3 other servers), and each edge node does the same with its spool and the master DB. There is a LOT of unnecessary redundancy here and the edge nodes certainly don't really need backing up as well!I should add that anything that could be PII isn't copied from the edge node spools to the master DB, but to another spool. There's another server that copies all the PII to a secure server (that does things like send reminder e-mails on request etc) and just the ID is copied back onto the master DB so the edge nodes now to remove the PII from the spool.
The the moment, the database isn't close to being large enough to worry about, but later on I'll shard the master DB and use haproxy rules to forward requests to an appropriate backend for the shard the user needs.
It's quite a lot more convoluted than just a random mysql install etc, but I really love how fast sqlite is and that my app is a single binary.
There's some more details going on, such as negotation of a server ID between edge nodes and the central servers, and then each server can allocate globally unique 64-bit IDs including a timestamp, and authentication using signed tokens so any edge node can verify user credentials even if they haven't yet been propagated to the master DB.
Thanks for the details. I too prefer SQLite because of how simple and powerful it is but I have not attempted multi server deployment for apps that use a writable SQLite database. (Some apps use a readonly database which is easy to deploy to multiple servers.) I will look into litefs.
It works quite well and pretty easy to set up with single writer and multiple readers, but to support switching the writer to another machine requires you to set up consul which is pretty frustrating. Once you've done that though, it's quite pleasant how you actually need less unique configuration per node (because you can set your local port to :0 and it's automatically allocated, and then litefs queries consul to determine the leader and correct address/port).
One gotcha with litefs is that anything that can potentially be a leader needs good routing between all other potential leaders. I had a few routing issues (eventually resolved) between SG and USA and if either was the leader then the other one would sometimes randomly be promoted because all the other machines could see both, but it didn't have the latest data and it'd all diverge and go wrong.