All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Migrating KimSufi to new KimSufi with zero mysql downtime?
Going to upgrade my KS-9 to a KS-17.
It's running LAMP, with debian, apache and mariadb.
I want to migrate to the new server with no more than a minute or two of down time, ideally none.
Now, I can easily get the new server set up and configured, thats fine, but my biggest concern is how I can keep the DB up and running, changes and all, while "switching" over.
the DB is around 10GB at present and theres probably 10-20 updates a second.
You can probably guess at this point, I have zero experience of replication or using mysql remotely.
I found a guide here: https://autoize.com/migrating-mysql-databases-with-no-downtime-for-non-dbas/
but I have a couple of questions:
- Can I do this /without/ using SSL? theres no sensitive data in the DB and I'd like to avoid steps relating to certificate generation etc. plus it's probably quicker.
- with a master/slave configuration, if i make DB updates on the slave, will they be replicated to the master, or is syncing only one way? Because ideally I'd like to switch the services that are using the DB over one by one, which would mean that changes made to the DB on either server would need to be replicated, until I've finished moving them over and then I can switch off the master/old server.
Any help appreciated.
Comments
SSL is not needed. Master-slave is one way (that is why it is called a slave).
You can set up replication in the other direction independently, so it is like a two-way street. But then you are responsible for not screwing it up by introducing inconsistencies.
You can also switch off read-only for the slave and start updating it for specific tables while still replicating others from the master. This is living dangerously.
I would setup a wireguard tunnel between the two servers, so 1.) is neglegible (due to wireguards encryption).
However, afaik, it is not possible to use the slave to update the master (only one way).
Another possibility would be to setup a master/master cluster (mysql galera cluster for instance). But that would drastically reduce db speed I believe.
However, how about syncing to the new server via master/slave and then portforward the mysql port on your old KS-9 to the new KS-17 via the tunnel?
The would just mean a minimal / no downtime, if done correctly, and allows the old applications to operate, so you can switch them one by one.
I don't know how the slave behaves, if data gets written to it. And you wouldn't be able to set it into read only mode as suggested by the tutorial you sent.
But I would try it this way
Set low TTL a day or so before, switch the DNS, kill the app on server1 as you move the database to server2 right before activating the app.
There's something to be said for simplicity. If it's that vital that it can't withstand a few minutes of downtime, for the love of god please don't host it on bargain basement servers 😛
so much this. why spend hours of configuring replication stuff on an already running system? other than for educational purpose it's the wrong way of doing it. what do you really lose over some minutes downtime?
plan and announce (if needed) a proper maintenance windows. shut down old stuff, transfer/migrate, switch back on. as @jar already said, keep in mind dns is something you can't factor in properly anyway, so people might still end up on your old instance because caching/TTL. shutting it down properly is the right way to go.
if at all I'd plan some proper failover/replication now for the new setup, so you can utilize this next time. but trying to build it on top of the old production system... hmm.
do backups.
@jar method is what I use for migrating ecommerce, though db updates are much less frequent. Apart from the one minute, or so, downtime (during the switchover) any inconsistencies are down to how quick the browsing (potential) customers get their cache/DNS updated. A "Store Closed - check back soon" on the original site helps though.
A 10GB Database hosting an app on that can't afford downtime of even a few minutes... on a Kimsufi? Sorry but I could not swallow that in the first place.
Well, Kimsufi is pretty solid, can't beat the uptime.
However, running a app that critical, on a single machine, seriously?
Keep in mind, kimsufi even if automated can easily take 1 hour to replace a motherboard.
If you reaaaaly can't afford any downtime >30s, do:
This would be the most effective way i think in your usecase. Best is to have some minutes of downtime though and take your time to execute this. And as always MAKE BACKUPS.
Hey guys, some great points, i'll try to answer them
I will echo @Faizo's point here.
Zero downtime sounds cool, and that's the only charm.
Don't act cool. Do the shit properly even if it involves some minutes of downtime.
Now, if you have any user complaining over those minutes of downtime, those are ones you should be avoiding in the first place.
what makes you think a bit of downtime has any effect here at all? whoever told you this, is rather bullshitting you or really believes in some crappy old urban legends.
what would you do if ovh has a network outage? those do happen and you might not even recognize them all the time. how'd you think this effects indexing and serp?
also even if a small downtime would have an effect, wouldn't you agree that google is then also smart enough to recognize what's going on and quickly get back on track afterwards? :-)
I mean, it's definitely your show and as said before learning something new is always a good approach, so keep on digging into the replication / HA topic.
but personally I'd just find it too risky to try that directly now on your valuable project. if things go wrong you might end up with an even larger downtime or mess of data instead. would that be worth it?
best of luck in any case ;-)
Lol 🤣.. you must be losing millions by 5 minute downtime..
I think it's important for OP to realize that the world does not revolve around him.
Some minutes of downtime - nobody will care. Not certainly Google. Not certainly Yahoo (dead). Not Bing.
And certainly not us.
years of first hand experience of running literally 1500+ domains in certain niches. If google considers a site down, even for only a few minutes, then they can and do (sometimes) reduce/harm serps; maybe for a few hours, maybe for much longer. Theres various factors at play including the sites authority and age.
but it's not only serps, it'll also lead to google reducing indexing frequency, sometimes googlebot doesnt return for a day or two in any meaningful numbers.
FYI, I'm having 300-500k pages indexed daily across my services. after the few hours of OVH network outages a little while ago, this dropped to ~100k for the following day and creeping back up over the next few days.
that's happened a few times, and it has 100% led to it affecting serps negatively too. I've in the past considered having a second box up and ready to go in the case of downtime but it's just something i've put at the bottom of a list. But in the case of network downtime, a second KS box (cant be in CA) isnt going to help me and boxes elsewhere are significantly more epexnsive if I want the same or better specs (the ram and ssd being most importnat).
I did look at the ryzen hetzner box as an upgrade path and I would have gone that way in a few months time if KS hadnt done this refresh.
3x a day rclone to google drive
well, it's me complaining, not the user. I can probably avoid myself but I don't think it'll help me
yeah, ive been complacent because of how rock solid this KS-9 has been. I do want to improve the setup and have a backup machine live and ready to go.
yeah its a running meme on here, but while not millions, it would likely be enough for most people to want to avoid it given the choice.
PMS detected.
If you can't do a 503 Service unavailable for a couple of minutes, I would suggest looking for SymmetricDS.
It's a multi-master setup where you can sync both MySQL databases and switch whenever you want between the two.
After the move, you can remove SymmetricDS and it's tables/triggers easily.