3种mysql备份恢复方案优劣对比( 三 ) _mysql

模拟全量备份脚本

执行以下 SQL，准备好我们的基础数据
使用 xtrabackup 进行全量备份
模拟人为数据库误操作
通过 xtrabackup 进行恢复

使用命令行进行全量备份
xtrabackup --backup --target-dir=/root/xtrabackup/bakcups --user=root --password=root参数解释：
--backup：将备份文件让道 target-dir，也就是说明它和 target-dir 是搭配使用的
--target-dir：备份文件放置文件，当前我使用的文件夹是 /root/xtrabackup/bakcups
如果看到有类似输出，即说明已经成功备份了
190904 14:30:48 [00] Writing xtrabackup_info190904 14:30:48 [00] ...donextrabackup: Transaction log of lsn (4417990) to (4417999) was copied.190904 14:30:49 completed OK!然后我们执行 SQL，模拟误操作，增删改都可以。我这里就直接删除一个表吧~
drop tables tablesname;接着通过命令进行全量恢复
xtrabackup --prepare --target-dir=/root/xtrabackup/bakcups这时候可以打开数据进行检验。
模拟增量备份恢复

增量备份目前仅可用于 InnoDB 或 XtraDB，对于 MyISAM，增量和全量备份同样还是会扫描全表的

通常在做增量备份，先做一个全量备份的(如果需要账号密码登录自行加上) 。
xtrabackup --backup --target-dir=/root/xtrabackup/base在 /data/backups/base 下会生成很多文件。我对于增量备份，我们着重看一个叫 xtrabackup_checkpoints 。以下是它的结构：
backup_type = full-backuped // 备份类型from_lsn = 0 // 初始位置to_lsn = 15188961605 // 备份位置last_lsn = 15188961605 // 最后备份位置也就是说，增量备份会基于全量备份的信息进行备份的。
xtrabackup --backup --target-dir=/root/xtrabackup/inc1--incremental-basedir=/root/xtrabackup/base刚刚生成的 /root/xtrabackup/inc1 里边包含大多信息，而且这里边也有一个 xtrabackup_checkpoints 文件。我给出一个大概结构的文件
backup_type = incrementalfrom_lsn = 4124244 to_lsn = 6938371last_lsn = 7110572compact = 0recover_binlog_info = 1现在我们通过 xtrabackup --prepare 进行数据恢复。
innobackupex --defaults-file=/etc/my.cnf --user=root --password='password' /backup/20180423/接下来就是检查的情况了
关于备份与恢复的一些知识点

有些部分备份不会真正减少服务器的开销。
不要备份没有改变的表。MyISAM 会记录每个表最后修改时间，通过查看磁盘文件或运行 show tables status 来看时间；如果是 InnoDB 。，可以利用触发器记录修改时间到一个小的“最后修改时间”表中，帮助追踪最新的修改操作。需要确保只对变更不频繁的表进行跟踪，这样才能降低开销。通过定制脚本可以轻松获得哪些表变更了。
增量备份的缺点是，增加了恢复的复杂度，额外的风险，更长的恢复时间。如果可以做全备，尽量做全备。
建议备份至少一周一次。
但是一般情况下，这个备份是不能用于恢复的，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件处于不一致的状态，我们现在就是要通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
备份文件的命名需要规范起来。例如全量备份的话可以使用特定标识作为前缀；增量备份可以以时间段作为命名