-
From: Reindl Harald h.rei...@thelounge.net
Date: Thu, 01 Nov 2012 16:49:45
To: mysql@lists.mysql.commysql@lists.mysql.com
Subject: 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
@lists.mysql.com
Subject: 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
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
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
@lists.mysql.com
Subject: 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
-
From: Reindl Harald [mailto:h.rei...@thelounge.net]
Sent: Thursday, November 01, 2012 4:47 AM
To: mysql@lists.mysql.com
Subject: 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
Am 01.11.2012 16:36, schrieb Singer Wang:
On Thu, Nov 1, 2012 at 11:34 AM, Rick James rja...@yahoo-inc.com
mailto:rja...@yahoo-inc.com wrote:
Full backup:
* Xtrabackup (Backup: slight impact on source; more if you have MyISAM
(as mentioned))
* Slave (Backup: zero impact on
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
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
@lists.mysql.com
Subject: 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
find you!
-Original Message-
From: Reindl Harald h.rei...@thelounge.net
Date: Thu, 01 Nov 2012 16:49:45
To: mysql@lists.mysql.commysql@lists.mysql.com
Subject: Re: Mysql backup for large databases
good luck
i would call snapshots on a running system much more dumb
than
[mailto:machiel.richa...@gmail.com]
Sent: Thursday, November 01, 2012 8:54 AM
To: Reindl Harald; mysql@lists.mysql.com
Subject: 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
find you!
-Original Message-
From: Reindl Harald h.rei...@thelounge.net
Date: Thu, 01 Nov 2012 16:49:45
To: mysql@lists.mysql.commysql@lists.mysql.com
Subject: Re: Mysql backup for large databases
good luck
i would call snapshots on a running system much more dumb
than
13 matches
Mail list logo