1. 利用mysqldump进行逻辑备份

1）全逻辑备份：

mysqldump -uxxx -p --flush-logs --delete-master-logs --all-databases > alldb.sql (每天晚上进行一次全备)

2）增量备份：

mysqladmin flush-logs (每小时刷一下，保存起来，进行了一次增量备份)

3）缺点：

1> --all-databases 包含了 mysql 数据库，其中包含了权限的数据，所以我们应该加上 --flush-privileges，在恢复时，权限才能生效；

? ? 注意 --all-databases 包括了mysql数据库，但是不会包含 information_schema和performance_schema两个数据库。

2> 因为 mysqldump 默认启用了 --lock-tables，所以会导致在备份期间对所有表持有读锁： lock table tb read local，所以所有的update，delete语句

? ? 会被阻塞。但是select语句和insert语句不会被阻塞。

3> --delete-master-logs 备份之后，会执行 purge logs to 语句。删除了备份之后的master上的binary log. 一般而言，我们不建议随便删除binary log.

? ? 我们应该将它们保存起来，而不是直接删除。以防万一，要留条退路。

4> 该备份方式，虽然在整个备份过程中持有了 lock table tb read local，但是还是可以执行 insert 语句的。所以得到的不是一致性的备份。虽然得到的不是

? ? 一致性的备份，但是因为flush log之后，所有的操作 也会记入新的binary log，所以如果使用了所有新的binary log来进行完全恢复的话，最后恢复的数据

? ? 也是一致性的。当然不一致性的备份无法用于搭建slave。

? ? 如果要得到一致性的备份的话，需要使用 --lock-all-tables 或者使用 --single-transaction 选项。前者使用了全局读锁，不允许任何修改操作。后者使用

? ? 了事务的特性来得到一致性备份。

所以我们应该对上面的备份方式进行改良。

2. 使用mysqldump备份的最佳姿势

1）优化锁 和 得到一致性备份：

我们可以使用结合使用 --single-transaction 、--master-data=2 、--flush-logs 来达到将锁定时间大大减少的目的。同时有得到了一致性的备份，而且该一致性备份和 flush 的日志也是一致的；

2）去掉 --delete-master-logs 选项，改为在备份之后，将所有被刷新的 binary log 移到一个地方保存起来；

3）因为使用了 --single-transaction 选项，针对的只能是 innodb 数据，但是mysql数据是Myisam引擎的，所以我们最好将mysql数据库的备份分开来，

? ? 另外专门针对 mysql 数据库进行一次操作。当然不分开来备份，可能也没有问题。

4）还要加上 --routines 来备份存储过程和函数，触发器默认会备份。

优化之后，我们得到：

mysqldump -uxxx -p --single-transaction --master-data=2 --routines --flush-logs --databases db1 db2 db3 > alldb.sql;

mysqldump -uxxx -p --flush-privileges --databases mysql > mysql.sql;

如果将mysql也一起备份的话：

mysqldump -uxxx -p --single-transaction --master-data=2 --routines --flush-logs --flush-privileges --all-databases > alldb.sql;

3. 使用mysqldump来搭建slave环境

搭建slave环境，一般有两种方法，对于规模不大的库，可以采用mysqldump来搭建；对于规模很大的库，最好采用xtrabackup来搭建，速度要快很多。

1）首先 分别在master和slave上设置不同的server_id=1/101，启用master上的log-bin=1，启用slave上的relog-log=relay-bin; 在master上设置：

? ? binlog_format=row；二进制日志的格式。maser上最好还设置sync_binlog=1 和 innodb_flush_log_at_trx_commit=1防止发生服务器崩溃时

? ? 导致复制破坏。在slave上最好还配置：read-only=1 和 skip-slave-start=1 前者可以防止没有super权限的用户在slave上进行写，后者防止在启动

? ? slave数据库时，自动启动复制线程。以后需要手动start slave来启动复制线程。注意slave没有必要启用 log-bin=1，除非需要搭建二级slave。

2）在master上建立一个具有复制权限的用户：? ? ?

3）备份master上的数据库，迁移到slave上：

另外还需要知道该一致性备份的数据，对应的master上的binary log的文件名，以及在该文件中的position，所以必须启用 master-data选项。

因为--master-data会启用--lock-all-tables 所以数据才是一致性的；但是导致了全局锁，不能进行任何修改操作；下面我们使用--single-transaction进行优化：

mysqldump -uroot -p --routines --flush-logs --single-transaction --master-data=2 --databases db1 db2 > /root/backup.sql; (--flush-logs非必须)

这样全局锁仅仅在备份的开始短暂的持有。不会再备份的整个过程中持有全局锁。

4）在slave上执行备份的脚本，然后连上master，开启复制线程：

执行sql脚本：

找到 --master-data 输出的 binary log 的文件名和postion:

执行 change master to, start slave:

最后在slave上查看复制线程的状态：

slave_IO_Runing 和 slave_sql_runing 状态都是yes表示搭建成功。

5）replication涉及到的三个线程：
1> master上的 binlog dump(dump线程)，即读取master上的binlog，发送到slave上的线程。
2> slave上的IO线程：读取slave上的relay log。
3> slave上的sql线程：执行IO线程读取的relay log的线程。 ? ? ? ? ? ? ? ? ? ? ? ? ?

4. 使用mysqldump的备份进行 还原

下面使用 mysqldump 进行一个备份，然后删除 datadir, 然后使用备份sql脚本和binary log进行还原的过程。

1）首先进行一个全备：

数据库有两个库： gs , ngx_lua.

2）将 备份时刷新之后的 binary log 利用 mv 命令移动到安全的位置，也就是--master-data=2输出的日志文件，它之前的日志文件都存储到安全的位置：