From: Reindl Harald Date: November 1 2012 3:49pm Subject: Re: Mysql backup for large databases List-Archive: http://lists.mysql.com/mysql/228567 Message-Id: <50929A19.9000903@thelounge.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCF4C059C0C1B300B1DFF5A73" --------------enigCF4C059C0C1B300B1DFF5A73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable good luck i would call snapshots on a running system much more dumb than "innodb_flush_log_at_trx_commit =3D 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=3D0 or= 2 and etc, you should be fine. We have been > using the trio: flush tables with read lock, xfs_freeze, snapshot for m= onths now without any issues. And we test > the backups (we load the backup into a staging once a day, and dev once= a week)=20 >=20 > On Thu, Nov 1, 2012 at 11:41 AM, Reindl Harald > wrote: >=20 > > Why do you need downtime? >=20 > because mysqld has many buffers in memory and there > is no atomic "flush buffers in daemon and freeze backend FS" >=20 > short ago there was a guy on this list which had to realize > this the hard way with a corrupt slave taken from a snapshot >=20 > that's why i would ALWAYS do master/slave what means ONE time > down (rsync; stop master; rsync; start master) for a small > timewindow and after that you can stop the slave, take a > 100% consistent backup of it's whole datadir and start > the slave again which will do all transactions from the > binarylog happened in the meantime --------------enigCF4C059C0C1B300B1DFF5A73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCSmhkACgkQhmBjz394AnnSkACbBdS+4Dw5MkCLpEfd7Jgqo14S QWAAn2FxhWAf+NbgjROvHQpa+xTajEQ3 =k9Qe -----END PGP SIGNATURE----- --------------enigCF4C059C0C1B300B1DFF5A73--