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--