On Feb 20, 2010, at 10:20 PM, Ronald Bradford wrote:
> Let me try to address some of your points, and also correct some of the
> inaccurate information in the response.
Thanks for responding, Ronald. I was "shooting from the hip" and there
definitely were some inaccuracies there. Nice to have your expert input. As
you pointed out, there are a lot of factors that go into the decision on what
backup solution is best for a particular setup. Konstantin, if you haven't
seen it already, you might be interested in these questions for evaluating
backup solutions -
http://www.mysqlperformanceblog.com/2009/03/03/10-things-you-need-to-know-about-backup-solutions-for-mysql/
> --single-transaction
This is the mysqldump option I was referring to.
> innodb_file_per_table is not a good idea for default, there are plenty of
> arguments for not using it when you have a large number of tables because of
> the increased data disk syncing.
Yeah, just searching innodb_file_per_table in google yields many pros and cons.
Probably worth benchmarking using your data if you can.
> Disaster is enviable. It is critical you have a backup and recovery plan, you
> actually test it, you time it and you document it. Many organizations fail to
> do this, here is a checklist you need to ensure you follow --
> http://ronaldbradford.com/blog/checked-your-mysql-recovery-process-recently-2010-02-15/
Thanks for sharing. This is helpful.
_______________________________________________
New York PHP Community MySQL SIG
http://lists.nyphp.org/mailman/listinfo/mysql
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
