MYSQL自动备份策略的选择与优劣点分析

目前流行几种备份方式：
1、逻辑备份：
使用mysql自带的mysqldump工具进行备份。备份成sql文件形式。
优点：最大好处是能够与正在运行的mysql自动协同工作，
在运行期间可以确保备份是当时的点，它会自动将对应操作的表锁定，不允许其他用户修改(只能访问)。可能会阻止修改操作。sql文件通用方便移植。
缺点：备份的速度比较慢。如果是数据量很多的时候。就很耗时间。如果数据库服务器处在提供给用户服务状态，在这段长时间操作过程中，意味着要锁定表(一般是读锁定，只能读不能写入数据)。那么服务就会影响的。
备注：所谓的与mysql服务器能够自动协同工作，实际上是指加参数来控制mysql服务器，比如锁定所有表只能进行读，不能进行写操作。
--lock-all-tables
2、物理备份：
直接拷贝mysql的数据目录。缺点，你不能去操作正在运行的mysql服务器(在拷贝的过程中有用户通过应用程序访问更新数据，这样就无法备份当时的数据)
可能无法移植到其他机器上去。
直接拷贝只适用于myisam类型的表。这种类型的表是与机器独立的。但实际情况是，你设计数据库的时候不可能全部使用myisam类型表。你也不可能：因为myisam类型表与机器独立，方便移植，于是就选择这种表，这并不是选择它的理由。
更多的情况是，你会根据业务特点(比如你需要支持事务机制就必须使用innodb)，查询速度和服务性能来选择表类型的。
必须保证表不被使用中。
如果服务器在你则正在拷贝一个表时改变它，拷贝就失去意义。
如果数据库表在文件系统备份过程中被修改，进入备份的表文件主语不一致的状态，而对以后的恢复表将失去意义。
保证你的拷贝完整性的最好方法是：关闭服务器，拷贝文件，然后重启服务器。
或者是，要锁定对应的表(对前端用户造成访问问题)。
解释直接拷贝文件，为什么不具备可移植性？
mysqldump 产生可移植到其他机器、甚至具有不同硬件结构的机器上的文本文件。直接拷贝文件不能够移植到其他机器上，除非要拷贝的表使用MyISAM 存储格式。ISAM 表只能在具有相同硬件结构的机器之间进行拷贝。例如，将文件从S PARC 的Solaris 机器拷贝到Intel 的Solaris 机器（或者相反）是行不通的。由MySQL3.23 引进的MyISAM 表存储格式可以解决这个问题，因为该格式与机器独立。因此，如果以下两个条件都满足的话，直接拷贝文件可以移植到具有不同硬件结构的机器上：即另一台机器上也必须运行MySQL3.23 以上的版本，并且文件必须表示成MyISAM 表，而不是ISAM 表。
3、双机热备份。
mysql数据库没有增量备份的机制。当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制(也就是双机热备)