Re: Mysql backup for large databases

Hi, For doing backups on the primary database, I know nothing better than have your tables in InnoDB and use Innobackup (or MySQL Enterprise backup). This, however, still has the possibility of hanging as it is using FLUSH TABLES WITH READ LOCK for taking backups of MyISAM tables.One may

RE: Mysql backup for large databases

Are both Masters writeable? If so, you have even worse problems. If not, then consider switching to one master with 2 slaves and use MHA for failover, etc. With that, you can seamlessly and nearly instantly switch to any slave. It does not involve a "restore", but gets you alive very quickly

Re: Mysql backup for large databases

as said: use a replication slave dedicated for backups you can even let a slave write a binlog and sync another slave with this one * rsync backups working with diff * they are extremly fast after the first time * a dedicated backup-slave has ZERO impact i am doing rsync-backups of 1.5 TB data o

Re: Mysql backup for large databases

Well, the biggest problem we have to answer for the clients is the following: 1. Backup method that doesn't take long and don't impact system 2. Restore needs to be done on a quick as possible way in order to minimize downtime. The one client is running master - master replication with master ser

Re: Mysql backup for large databases

good luck i would call snapshots on a running system much more dumb than "innodb_flush_log_at_trx_commit = 2" on systems with 100% stable power instead waste IOPS on shared storages Am 01.11.2012 16:45, schrieb Singer Wang: > Assuming you're not doing dumb stuff like innodb_flush_log_at_tx=0 or 2

Re: Mysql backup for large databases

Assuming you're not doing dumb stuff like innodb_flush_log_at_tx=0 or 2 and etc, you should be fine. We have been using the trio: flush tables with read lock, xfs_freeze, snapshot for months now without any issues. And we test the backups (we load the backup into a staging once a day, and dev once

Re: Mysql backup for large databases

Am 01.11.2012 16:36, schrieb Singer Wang: > On Thu, Nov 1, 2012 at 11:34 AM, Rick James > wrote: > > Full backup: > * Xtrabackup (Backup: slight impact on source; more if you have MyISAM > (as mentioned)) > * Slave (Backup: zero impact on Master -- once

Re: Mysql backup for large databases

On Thu, Nov 1, 2012 at 11:34 AM, Rick James wrote: > Full backup: > * Xtrabackup (Backup: slight impact on source; more if you have MyISAM (as > mentioned)) > * Slave (Backup: zero impact on Master -- once replication is set up) > * LVM -- a minute of server down; see below > Why do you need down

RE: Mysql backup for large databases

Full backup: * Xtrabackup (Backup: slight impact on source; more if you have MyISAM (as mentioned)) * Slave (Backup: zero impact on Master -- once replication is set up) * LVM -- a minute of server down; see below Full restore: * Xtrabackup - Takes time * Slave - minute(s) to "failover", mostly d

Re: Mysql backup for large databases

Am 01.11.2012 11:28, schrieb Machiel Richards - Gmail: > Using mysqldump and restores on an 80-100GB database seems a bit unpractical > as the restore times seems to > get quite long as well as the backup times. * setup a master/slave configuration * stop the slave * rsync the raw datadir to wh

Re: Mysql backup for large databases

On 01/11/2012 11.28, Machiel Richards - Gmail wrote: [...] I am busy investigating some options relating to the backup for MySQL databases when they get quite large. When using the MySQL enterprise, there is the option to use the MySQL enterprise backup as it is part of the Enterprise

Mysql backup for large databases

Hi All I am busy investigating some options relating to the backup for MySQL databases when they get quite large. When using the MySQL enterprise, there is the option to use the MySQL enterprise backup as it is part of the Enterprise license. However, when using the GA (fre