Hosting Gods: How do you keep a site up and running normally when performing a backup?
 

I have a site with a good amount of users on it.

Everyday when my site does a backup it creates a dump of the database. It takes about a minute to dump that database, so the tables can not be written to for that time.

It bothers me when this happens because the site is down for 30-60 seconds.
My members think my site sucks, tell each other it sucks, and they leave to go to my competitors. It happens everyday. That's bad for my business.

Is this lock normal? Or can something be done about it?
My competitors sites are much bigger than mine and I dont see them crash. So I dont understand how they do it.

:helpme:helpme:helpme:helpme:helpme:helpme

Use mysql replication.... then backup from the slave. That way no mysql downtime at all.

I wondered about this too, although I don't have the problem myself.

end of thread.

Do you need 2 servers for this? Im not technically savvy so dont know what the setup is for this.

I use rsync to avoid downtime.

LOL!

I don't use SQL.

well, technically I think you can run two instances of mysql on different ports, but by far the simplest is to run the slave on your backup server or a cheap dedi or even cloud setup. I run mine on a 256MB cloud instance that costs me 1c/hr and have no problems on it. Then that gets backed up to my remote 100GB backup space. Mysql (my most valuable data) is then spread across 3 servers... Backup of sites/configs is spread across 2 servers.

Another option would be to take a cheap 250GB dedi box at ?15/month, run the mysql slave there and use that too for backups, that way everything is spread across 3 drives, but I like the cloud availability (100%) for a replication server...

you need at least 2 mysql server instances, running on different ports if on the same server. Like I said above, best (and simplest) is to run mysql on another server.

For technical how to - follow this tuto. It's for centos, but effectively shows all the mysql configs which is distro-independent. :2 cents:

1. Having a secondary MySQL server as a slave and backing up from that is the best option
2. Rsyncing the binary files, while not recommended, can be "safe" for INNODB based tables, however you cannot guarantee consistency and may need to check/repair the table once restored. This is not recommended at all for InnoDB tables as you will also need to restore the binary log data, which may cause unforseen issues with other data in the database.
3. For InnoDB you can either use InnoDB hot copy, or use mysqldump with the "?single-transaction" option enabled.

#1 and 3 are the preferred methods :)

No it's not normal.

The site should not be effected by the backups. I assume they are not using rcync and doing a full backup each time which is overloading your server. Mysql can be rsynced just like everything else.

borked is right... Best way is to back up from a slave however...

In the interim and if your site's traffic doesn't justify a separate slave box... There are a plethora of flags/options to set in mysqldump to make sure you aren't tanking your MySQL instance during a backup ;)

EDIT: Check out mysqlhotcopy

of course it can, but don't expect a simple restore, or any for that matter....

simply copying the /var/lib/mysql/mysql directory is asking for trouble :error

agreed :2 cents:

well the best answer is of course never mentioned - stop using mysql.

flat files are the future. well they'll been my present for half a decade. they are fast, easy to backup, and easy to transfer.

look into it.

any chance of geospatial index support in your flat files?

I agree, databases are getting outdated but we still have a good 4-5 years before they are obsolete. MySQL it's simply a cpu hog and not as reliable as flat files.

lol ya there's a lot of that going on in porn. nerd.

This is such a fallacy - I have around 14 million mysql db hits and ~1million of those are on very complex joins involving very non-ordinary indexes. Not even taking into account the load added by apache for all those hits, my server load averages only 0.05. And I can back that up with stats to anyone who wants a private argument off the board over email...

What the problem is often frequently craply designed databases. Anyone saying mysql is a hog should run something like mysqltuner on their server and see if all green lights come up. Mine do, and my most used db is 6.5GB in size, and yet mysql is only set to use 4GB of RAM.

phooey.

ehm, there are exactly 2-3 million daily hits using just those. Nerd :winkwink:

My fav part:

"What the problem is often frequently craply designed databases. Anyone saying mysql is a hog should run something like mysqltuner on their server and see if all green lights come up. Mine do, and my most used db is 6.5GB in size, and yet mysql is only set to use 4GB of RAM."

Well said, & well done! :)

Most of the time just doing a simple mysqldump of one database then the sites actual files will work fine without any downtime. As long as you do site1db, site1files, site2db, site2files, etc (instead of dumping all dbs then all files) and the databases aren't massive it will be within sync enough. It's even less of a big deal if you keep multiple backups instead of relying on one. Sure to be technical you should lock it all before the backup then unlock it but it usually isn't a big deal for a normal site or small group of them on a server.

you are just trolling, right? :helpme

mysqldump locks the tables

Curious who you use for the cloud service?

You can turn that off though with different options.

A minute or so of slowness / non-response per day isn't a biggie for most sites if that occurs at an odd time when relatively few visitors are on.

Have you tried scheduling the backup for a very slow time when there are the fewest users on? -if no, check your logs to see when that usually is and change the backup time to match.

Many people do maintenance between 12AM Midnight to 3 AM, but that can often be a bad time when factoring in the location of the server and time zone of most visitors. So don't be surprised if the slowest, more ideal time ends up being somewhat later, such as around 6 AM.

Ron

didn't know that... i guess we never cared to look since we are just backing up from our slave and it doesnt effect us.

And you are just wrong again right?

Please see post number 7.

:thumbsup

chaze aka "DWHS" is a complete newbie, pretty obvious from his posts and hosting operation.

Your members run for the hills over 60 seconds of downtime? I have trouble with both Google and Yahoo every day, have never considered going somewhere else? Temporary glitch.

when it happens again and again they get irritated and angry. Ive had cancellations and increasingly angry emails.

Do you backup when you know you have the least amount of people on your site?

miniCloud - very useful for this kind of stuff or for automation
http://www.ovh.ie/cloud/

haha ya i saw it too late. :upsidedow