Sometimes things don’t work out with replication. When I first started experimenting with it I thought this was a “setup and forget about it” kind of job.
Experience has shown though that you have to regularly triple check and see if things may have broken (despite a good and once working setup).
Let’s take a look at what you can do when your Slave isn’t replicating anymore. If you want to know more about how to setup replication, have a look at my previous article in which I explain how this works.
This is a step-by-step guide on how to replicate an existing MySQL server. The server is live and contains data and needs a constant backup companion.
Many tutorials focus on how to setup replication when no data is present on the system. That’s an ideal solution if you’re building a new setup, but in case you’ve got a server that already has data present then here’s how to accomplish the this:
setup your existing MySQL server (with data) as a Master
export all your databases and user accounts
create a slave and import all your data
I’ve done this several times and always forgot to take some notes – until today. Without further ado, let’s replicate MySQL.
Today was a rather exciting day for me: I’ve successfully turned my aging Samsung NC10 Netbook into an internal server in our office.
I bought the little guy in 2009 and he’s been my trusty companion on many jobs before I got an iPad. He still works fine, even though Windows XP was getting weird of late – and admittedly I hadn’t even turned him on in over 8 months.
Now my trusty pal is running CentOS 6.4 while sitting quietly in a corner next to the ubee modem, serving as an internal Linux server. This is great for testing and automated backups – and in the same spirit as playing with a Raspberry Pi (in a much neater battery powered package).
Refreshing the NC10 wasn’t a picnic though, and some of the steps are rather involved. Here are my notes, in case I either have to do it again or you want to follow along.