我是DB的新手，特别是MySQL。 有没有什么好的做法大规模备份MySQL？ 例如，我已经发现了一些事情。
使用mysqlbackup （物理备份）而不是mysqldump 。
将key_buffer_size增加到RAM的20％（不仅仅是备份非常有用的选项）。
看看maatkit的工具有几个备份。
如果你知道任何MySQL备份共享的好东西。
不要在Maatkit中使用这些工具。 （我写他们。）他们是危险的。 我在别处写了这个。 Percona Toolkit是Maatkit的替代品，它不包含这些工具。
如果你有一个MySQL企业订阅，mysqlbackup是伟大的。 如果没有的话，可以考虑Percona XtraBackup，一个几乎完全相同的免费工具。
这不是一个愚蠢的问题。 你应该认真备份。
让我们看看你的三个select：
1) Use mysqlbackup (physical backup) instead of mysqldump.
MySQL的企业备份是在施瓦茨男爵的，所以我不会重复。
2) increase key_buffer_size to 20% of RAM (not just for backup extremely helpful option).
key_buffer_size控制MyISAM密钥缓冲区的大小，用于cachingMyISAM表的索引页。 它们不会影响备份。 例如，如果您使用mysqldump并执行SHOW PROCESSLIST; ，你会看到类似的东西
SELECT /* SQL_NO_CACHE */ FROM tblname
这可以防止颠簸caching。 否则，在备份期间，所需的数据将被不必要地从MySQL的caching中推出。
3) take a look at tools of maatkit there are few for backup.
Percona推出了mk-parallel-dump和mk-parallel-restore 。 Percona最近宣布这些工具已被弃用。 有些人仍然自担风险使用它们。
我实际上编写了我自己的数据库和表的并行转储版本，并将algorithm公布在DBA StackExchange中 。
Percona现在有Percona工具。 它不包含任何备份工具。 这与XtraBackup分开销售。 恕我直言， 它有优点和缺点，但绝对是大型装置的理想select
如果您正在寻找时间点恢复，这是不理想的，因为来自XtraBackup的备份数据的时间点是基于XtraBackup何时完成的，而不是XtraBackup何时启动的。 如果传入数据的速率几乎与备份过程本身一样快，这一点就会变得很明显。 从理论上讲，如果传入数据的速率与备份过程一样快或更快，备份过程将永远不会结束。 在2011年5月的Percona Live大会现场舞台上， 只要你能忍受这个和你当前的传入数据速率，那么XtraBackup就是你的解决scheme 。
您可以创build一个MySQL集群并使用第二个节点作为备份。