mysql数据库三种备份和恢复,如何实现MySQL数据库的备份与恢复
mysql数据库三种备份和恢复,如何实现MySQL数据库的备份与恢复详细介绍
本文目录一览： win7系统怎么备份和恢复MySQL数据 win7系统备份和恢复MySQL数据的方法
今天本文教程和大家分享就是win7系统备份和恢复MySQL数据的方法，MySQL是一个小型关系型数据库管理系统，为防止数据丢失，有时候需要备份MySQL数据。或者遇到系统崩溃等问题，那么怎么恢复MySQL数据？接下来本教程和大家介绍win7系统备份和恢复MySQL数据的方法，通过命令的方式，下面来看看具体设置方法吧。具体方法如下:1、win+r打开命令窗口，输入cmd，打开了cmd窗口；2、退出到C盘的根文件夹，如果不退，在下面备份和恢复的两条命令中要分别在mysqldump和mysql后面加上-hlocalhost；3、然后加载进入MySQL安装目录中的bin文件夹路径；4、接下来就可以进行备份和恢复步骤了。这里解释一下这两条命令：1.备份数据命令mysqldump是MySQL安装的时候自带的一个工具，可以用来备份数据库-uroot是输入用户名-pcompanyd_dept此处是输入数据库名数据库中的表名（如果不需要指定某个表可以不加上后面的表名）这个符号表示导出（即为备份）后面加上要导出的路径company.sql是指定的导出文件，如果路径中没有此文件系统会帮忙新建2.导入备份数据文件恢复数据库命令假设数据库此时被毁坏了，需要导入之前备份的数据库文件前面的用法和备份数据命令基本一致，只是前面关键词由mysqldump改成了mysql这个符号表示导入（与导出相反）后面加上要导入的数据库文件路径source‘文件路径’也可以用来导入备份的文件关于win7系统备份和恢复MySQL数据的方法介绍到这里了，其实备份和恢复MySQL数据的步骤比较简单，并没有想象中那么难，有需要的用户可以掌握，以后对大家操作电脑有所帮助。
如何实现MySQL数据库的备份与恢复
在数据库表丢失或损坏的情况下 备份你的数据库是很重要的 如果发生系统崩溃 你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态 有时 正是MySQL管理员造成破坏 管理员已经知道表以破坏 用诸如vi或Emacs等编辑器试图直接编辑它们 这对表绝对不是件好事！ 备份数据库两个主要方法是用mysqldump程序或直接拷贝数据库文件（如用cp cpio或tar等） 每种方法都有其优缺点 mysqldump与MySQL服务器协同操作 直接拷贝方法在服务器外部进行 并且你必须采取措施保证没有客户正在修改你将拷贝的表 如果你想用文件系统备份来备份数据库 也会发生同样的问题 如果数据库表在文件系统备份过程中被修改 进入备份的表文件主语不一致的状态 而对以后的恢复表将失去意义 文件系统备份与直接拷贝文件的区别是对后者你完全控制了备份过程 这样你能采取措施确保服务器让表不受干扰 mysqldump比直接拷贝要慢些 mysqldump生成能够移植到其它机器的文本文件 甚至那些有不同硬件结构的机器上 直接拷贝文件不能移植到其它机器上 除非你正在拷贝的表使用MyISAM存储格式 ISAM表只能在相似的硬件结构的机器上拷贝 在MySQL 中引入的MyISAM表存储格式解决了该问题 因为该格式是机器无关的 所以直接拷贝文件可以移植到具有不同硬件结构的机器上 只要满足两个条件 另一台机器必须也运行MySQL 或以后版本 而且文件必须以MyISAM格式表示 而不是ISAM格式 不管你使用哪种备份方法 如果你需要恢复数据库 有几个原则应该遵守 以确保最好的结果 定期实施备份 建立一个计划并严格遵守 让服务器执行更新日志 当你在崩溃后需要恢复数据时 更新日志将帮助你 在你用备份文件恢复数据到备份时的状态后 你可以通过运行更新日志中的查询再次运用备份后面的修改 这将数据库中的表恢复到崩溃发生时的状态 以文件系统备份的术语讲 数据库备份文件代表完全倾倒（full dump） 而更新日志代表渐进倾倒（incremental dump） 使用一种统一的和易理解的备份文件命名机制 象backup buckup 等不是特别有意义 当实施你的恢复时 你将浪费时间找出文件里是什么东西 你可能发觉用数据库名和日期构成备份文件名会很有用 例如 %mysqldump samp_db >/usr/archives/mysql/samp_db %mysqldump menagerie >/usr/archives/mysql/menagerie 你可能想在生成备份后压缩它们 备份一般都很大！你也需要让你的备份文件有过期期限以避免它们填满你的磁盘 就象你让你的日志文件过期那样 用文件系统备份备份你的备份文件 如果遇上了一个彻底崩溃 不仅清除了你的数据目录 也清除了包含你的数据库备份的磁盘驱动器 你将真正遇上了麻烦 也要备份你的更新日志 将你的备份文件放在不同于用于你的数据库的文件系统上 这将降低由于生成备份而填满包含数据目录的文件系统的可能性 用于创建备份的技术同样对拷贝数据库到另一台机器有用 最常见地 一个数据库被转移到了运行在另一台主机上的服务器 但是你也可以将数据转移到同一台主机上的另一个服务器 使用mysqldump备份和拷贝数据库 当你使用mysqldumo程序产生数据库备份文件时 缺省地 文件内容包含创建正在倾倒的表的CREATE语句和包含表中行数据的INSERT语句 换句话说 mysqldump产生的输出可在以后用作mysql的输入来重建数据库 你可以将整个数据库倾倒进一个单独的文本文件中 如下 %mysqldump samp_db >/usr/archives/mysql/samp_db 输出文件的开头看起来象这样 # MySQL Dump # # Host: localhost Database: samp_db # # Server version alpha log # # Table structure for table absence # CREATE TABLE absence( student_id int( ) unsigned DEFAULT NOT NULL date date DEFAULT NOT NULL PRIMARY KEY (student_id date) ); # # Dumping data for table absence # INSERT INTO absence VALUES ( ); INSERT INTO absence VALUES ( ); INSERT INTO absence VALUES ( ); 文件剩下的部分有更多的INSERT和CREATE TABLE语句组成 如果你想压缩备份 使用类似如下的命令 %mysqldump samp_db | gzip >/usr/archives/mysql/samp_db gz 如果你要一个庞大的数据库 输出文件也将很庞大 可能难于管理 如果你愿意 你可以在mysqldump命令行的数据库名后列出单独的表名来倾到它们的内容 这将倾倒文件分成较小 更易于管理的文件 下例显示如何将samp_db数据库的一些表倾到进分开的文件中 %mysqldump samp_db student score event absence >grapbook sql %mysqldump samp_db member president >hist league sql 如果你生成准备用于定期刷新另一个数据库内容的备份文件 你可能想用 add drop table选项 这告诉服务器将DROP TABLE IF EXISTS语句写入备份文件 然后 当你取出备份文件并把它装载进第二个数据库时 如果表已经存在 你不会得到一个错误 如果你倒出一个数据库以便能把数据库转移到另一个服务器 你甚至不必创建备份文件 要保证数据库存在于另一台主机 然后用管道倾倒数据库 这样mysql能直接读取mysqldump的输出 例如 你想从主机拷贝数据库samp_db到 可以这样很容易做到 %mysqladmin h create samp_db %mysqldump samp_db | mysql h samp_db 以后 如果你想再次刷新上的数据库 跳过mysqladmin命令 但要对mysqldump加上 add drop table以避免的得到表已存在的错误 %mysqldump add drop table samp_db | mysql h samp_db mysqldump其它有用的选项包括 flush logs和 lock tables组合将对你的数据库检查点有帮助 lock tables锁定你正在倾倒的所有表 而 flush logs关闭并重新打开更新日志文件 新的更新日志将只包括从备份点起的修改数据库的查询 这将设置你的更新日志检查点位备份时间 （然而如果你有需要执行个更新的客户 锁定所有表对备份期间的客户访问不是件好事 ） 如果你使用 flush logs设置检查点到备份时 有可能最好是倾倒整个数据库 如果你倾倒单独的文件 较难将更新日志检查点与备份文件同步 在恢复期间 你通常按数据库为基础提取更新日志内容 对单个表没有提取更新的选择 所以你必须自己提取它们 缺省地 mysqldump在写入前将一个表的整个内容读进内存 这通常确实不必要 并且实际上如果你有一个大表 几乎是失败的 你可用 quick选项告诉mysqldump只要它检索出一行就写出每一行 为了进一步优化倾倒过程 使用 opt而不是 quick opt选项打开其它选项 加速数据的倾倒和把它们读回 用 opt实施备份可能是最常用的方法 因为备份速度上的优势 然而 要警告你 opt选项确实有代价 opt优化的是你的备份过程 不是其他客户对数据库的访问 opt选项通过一次锁定所有表阻止任何人更新你正在倾倒的任何表 你可在一般数据库访问上很容易看到其效果 当你的数据库一般非常频繁地使用 只是一天一次地调节备份 一个具有 opt的相反效果的选项是 dedayed 该选项使得mysqldump写出INSERT DELAYED语句而不是INSERT语句 如果你将数据文件装入另一个数据库并且你想是这个操作对可能出现在该数据库中的查询的影响最小 delayed对此很有帮助 press选项在你拷贝数据库到另一台机器上时很有帮助 因为它减少网络传输字节的数量 下面有一个例子 注意到 press对与远端主机上的服务器通信的程序才给出 而不是对与本地主机连接的程序 %mysqldump opt samp_db | mysql press h samp_db mysqldump有很多选项 详见《MySQL参考手册》 使用直接拷贝数据库的备份和拷贝方法 另一种不涉及mysqldump备份数据库和表的方式是直接拷贝数据库表文件 典型地 这用诸如cp tar或cpio实用程序 本文的例子使用cp 当你使用一种直接备份方法时 你必须保证表不在被使用 如果服务器在你则正在拷贝一个表时改变它 拷贝就失去意义 保证你的拷贝完整性的最好方法是关闭服务器 拷贝文件 然后重启服务器 如果你不想关闭服务器 要在执行表检查的同时锁定服务器 如果服务器在运行 相同的制约也适用于拷贝文件 而且你应该使用相同的锁定协议让服务器 安静下来 假设服务器关闭或你已经锁定了你想拷贝的表 下列显示如何将整个samp_db数据库备份到一个备份目录（DATADIR表示服务器的数据目录） %cd DATADIR %cp r samp_db /usr/archive/mysql 单个表可以如下备份 %cd DATADIR/samp_db %cp member * /usr/archive/mysql/samp_db %cp score * /usr/archive/mysql/samp_db 当你完成了备份时 你可 lishixinzhi/Article/program/MySQL/201311/29384
浅谈MySQL数据库备份的几种方法
mysql常见的备份方式有:mysqldump、mysqlhotcopy、BACKUP TABLE 、SELECT INTOOUTFILE，又或者备份二进制日志（binlog），还可以是直接拷贝数据文件和相关的配置文件。MyISAM表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。Innodb 所有的表都保存在同一个数据文件 ibdata1中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，或者用mysqldump。1.mysqldump备份mysqldump 是采用SQL级别的备份机制，它将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之间升级时相对比较合适，这也是最常用的备份方法。示例:mysqldump -uroot -p database table > /home/jobs/back.sqlmysqldump也可做增量备份,mysqldump相关参数网上较多,就不在此一一赘述了2.mysqlhotcopy备份【如果是企业版的mysql可以用mysqlbackup当然是要收费的】mysqlhotcopy 是一个 PERL 程序。它使用 LOCK TABLES、FLUSHTABLES 和 cp 或 scp来快速备份数据库。它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件（包括数据表定义文件、数据文件、索引文件）所在的机器上。mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在 类Unix 和 NetWare 系统上。mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。示例： root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=root-p=123456 database /tmp (把数据库目录 database 拷贝到 /tmp下)root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=root -p=123456db_name_1 ... db_name_n /tmproot#/usr/local/mysql/bin/mysqlhotcopy-h=localhost -u=root -p=123456 db_name./regex//tmp更详细的使用方法请查看手册，或者调用下面的命令来查看 mysqlhotcopy 的帮助：perldoc /usr/local/mysql/bin/mysqlhotcopy注意，想要使用 mysqlhotcopy，必须要有SELECT、RELOAD(要执行 FLUSH TABLES) 权限，并且还必须要能够有读取 datadir/db_name 目录的权限。还原mysqlhotcopy 备份出来的是整个数据库目录，使用时可以直接拷贝到 mysqld指定的 datadir (在这里是 /usr/local/mysql/data/)目录下即可，同时要注意权限的问题，如下例： root#cp-rf db_name /usr/local/mysql/data/root#chown -R nobody:nobody/usr/local/mysql/data/ (将 db_name 目录的属主改成 mysqld 运行用户)3.SQL 语法备份3.1 备份BACKUP TABLE 语法其实和 mysqlhotcopy的工作原理差不多，都是锁表，然后拷贝数据文件。它能实现在线备份，但是效果不理想，因此不推荐使用。它只拷贝表结构文件和数据文件，不同时拷贝索引文件，因此恢复时比较慢。例子： BACK TABLE tbl_name TO ‘/tmp/db_name/‘;注意，必须要有 FILE权限才能执行本SQL，并且目录 /tmp/db_name/ 必须能被 mysqld 用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。恢复用 BACKUP TABLE 方法备份出来的文件，可以运行 RESTORE TABLE 语句来恢复数据表。例子： RESTORE TABLE FROM ‘/tmp/db_name/‘;权限要求类似上面所述。3.2 SELECT INTO OUTFILE 则是把数据导出来成为普通的文本文件，可以自定义字段间隔的方式，方便处理这些数据。例子：SELECT INTO OUTFILE ‘/tmp/db_name/tbl_name.txt‘ FROM tbl_name;注意，必须要有FILE 权限才能执行本SQL，并且文件 /tmp/db_name/tbl_name.txt 必须能被 mysqld用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。用 SELECT INTO OUTFILE 方法备份出来的文件，可以运行 LOAD DATA INFILE 语句来恢复数据表。例子： LOADDATA INFILE ‘/tmp/db_name/tbl_name.txt‘ INTO TABLEtbl_name;权限要求类似上面所述。倒入数据之前，数据表要已经存在才行。如果担心数据会发生重复，可以增加 REPLACE关键字来替换已有记录或者用 IGNORE 关键字来忽略他们。4.启用二进制日志(binlog)采用 binlog 的方法相对来说更灵活，省心省力，而且还可以支持增量备份。启用 binlog 时必须要重启 mysqld。首先，关闭 mysqld，打开 my.cnf，加入以下几行：server-id = 1log-bin = binloglog-bin-index = binlog.index然后启动 mysqld 就可以了。运行过程中会产生 binlog.000001 以及 binlog.index，前面的文件是 mysqld记录所有对数据的更新操作，后面的文件则是所有 binlog 的索引，都不能轻易删除。关于 binlog 的信息请查看手册。需要备份时，可以先执行一下 SQL 语句，让 mysqld 终止对当前 binlog的写入，就可以把文件直接备份，这样的话就能达到增量备份的目的了： FLUSH LOGS;如果是备份复制系统中的从服务器，还应该备份master.info 和 relay-log.info 文件。备份出来的 binlog 文件可以用 MySQL 提供的工具 mysqlbinlog 来查看，如：/usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001该工具允许你显示指定的数据库下的所有SQL 语句，并且还可以限定时间范围，相当的方便，详细的请查看手册。恢复时，可以采用类似以下语句来做到： /usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001| mysql -uyejr -pyejr db_name把 mysqlbinlog 输出的 SQL 语句直接作为输入来执行它。如果你有空闲的机器，不妨采用这种方式来备份。由于作为 slave 的机器性能要求相对不是那么高，因此成本低，用低成本就能实现增量备份而且还能分担一部分数据查询压力，何乐而不为呢？具体方案：一、主从同步可以参考http://kerry.blog.51cto.com/172631/110206二、增量备份：每天中午12点和晚上12点做一次全备，每隔一小时备份binlog,也就是增量备份，具体操作如下：Linux下开启binlog/etc/my.cnf中的mysqld部分加入:[mysqld]log-bin=../logs/mysql-binmax-binlog-size=50Mwindows下开启binlog%mysql%/my.ini中的mysqld部分加入:[mysqld]log-bin =../logs/mysql-binmax-binlog-size=50M完整备份脚本 （仅提供部分作参考）如果数据库数据量比较大，可以一天全备一次, 再每隔一小时增量备份一次；#!/bin/sh# mysql data backup script ## use mysqldump --help,get more detail.BakDir=/backup/mysqlLogFile=/backup/mysql/mysqlbak.logDATE=`date +%Y%m%d`echo " " >> $LogFileecho " " >> $LogFileecho "-------------------------------------------" >> $LogFileecho $(date +"%y-%m-%d %H:%M:%S") >> $LogFileecho "--------------------------" >> $LogFilecd $BakDirDumpFile=$DATE.sqlGZDumpFile=$DATE.sql.tgzmysqldump --quick --all-databases --flush-logs--delete-master-logs --lock-all-tables> $DumpFileecho "Dump Done" >> $LogFiletar czvf $GZDumpFile $DumpFile >> $LogFile 2>&1echo "[$GZDumpFile]Backup Success!" >> $LogFilerm -f $DumpFile#delete previous daily backup files:采用增量备份的文件,如果完整备份后,则删除增量备份的文件.cd $BakDir/dailyrm -f *cd $BakDirecho "Backup Done!"echo "please Check $BakDir Directory!"echo "copy it to your local disk or ftp to somewhere !!!"ls -al $BakDir上面的脚本把mysql备份到本地的/backup/mysql目录,增量备份的文件放在/backup/mysql/daily目录下.增量备份增量备份的数据量比较小,但是要在完整备份的基础上操作增量备份使用bin log,脚本如下:#!/bin/sh# mysql binlog backup script/usr/bin/mysqladmin flush-logsDATADIR=/var/lib/mysqlBAKDIR=/backup/mysql/daily###如果你做了特殊设置,请修改此处或者修改应用此变量的行:缺省取机器名,mysql缺省也是取机器名HOSTNAME=`uname -n`cd $DATADIRFILELIST=`cat $HOSTNAME-bin.index`##计算行数,也就是文件数COUNTER=0for file in $FILELISTdoCOUNTER=`expr $COUNTER + 1 `doneNextNum=0for file in $FILELISTdobase=`basename $file`NextNum=`expr $NextNum + 1`if [ $NextNum -eq $COUNTER ]thenecho "skip lastest"elsedest=$BAKDIR/$baseif(test -e $dest)thenecho "skip exist $base"elseecho "copying $base"cp $base $BAKDIRfifidoneecho "backup mysql binlog ok"增量备份脚本是备份前flush-logs,mysql会自动把内存中的日志放到文件里,然后生成一个新的日志文件,所以我们只需要备份前面的几个即可,也就是不备份最后一个.因为从上次备份到本次备份也可能会有多个日志文件生成,所以要检测文件,如果已经备份过,就不用备份了.数据还原：先还原最近的完全备份数据：mysql -hhostname -uusername -ppassword databasename < backupfile.sql再还原binlog ：./mysqlbinlog --start-date="2016-04-10 17:30:05" --stop-date="2016-04-10 17:41:28" /usr/local/mysql/data/mysql-bin.000002 |mysql -u root -p1234565.拷贝文件直接备份数据文件相较前几种方法，备份数据文件最为直接、快速、方便，缺点是基本上不能实现增量备份。为了保证数据的一致性，需要在靠背文件前，执行以下 SQL 语句： FLUSH TABLES WITH READLOCK;也就是把内存中的数据都刷新到磁盘中，同时锁定数据表，以保证拷贝过程中不会有新的数据写入。这种方法备份出来的数据恢复也很简单，直接拷贝回原来的数据库目录下即可。注意，对于 Innodb 类型表来说，还需要备份其日志文件，即 ib_logfile* 文件。因为当 Innodb 表损坏时，就可以依靠这些日志文件来恢复。6.利用rsync备份rsync作为同步工具也可以用来做备份,但要配置服务器端和客户端示例rsync -vzrtopg --progress --delete root@192.168.1.3::root /tmp/相关rsync配置可参考http://fanqiang.chinaunix.net/a6/b7/20010908/1305001258.html缺点是rsync是根据文件修改时间做的增量备份,所以备份数据库都是全备,并且配置比较麻烦.7.利用BigDump工具导入超大MySQL数据库备份文件常用的 MySQL 数据库恢复工具（也能进行备份操作）是 phpMyAdmin，这是一个开源、免费的工具，大多数主机商（例如 Hawkhost）都会免费提供 。相信很多站长也用过 phpMyAdmin 来进行网站数据库的备份和恢复，确实很方便，并且有多国语言界面。不过，有一种情况可能你还没碰到，就是当你的数据库体积比较大时，例如 SQL 备份文件大于 2MB，甚至大于 10MB，这个时候如果你通过 phpMyAdmin 来进行数据库的恢复，就会出错，显示如下的提示：这是因为你的 SQL 文件体积太大，超过了 phpMyAdmin 的处理能力，这种情况在网络速度比较慢的情况下尤为突出，例如站长在周末晚上8点这个网络拥挤的时段尝试使用 phpMyAdmin 来恢复大型 MySQL 数据库备份，就容易遇到这种问题。很显然 phpMyAdmin 只适用于恢复比较小的 SQL 文件备份。对于超大 MySQL 数据库备份的恢复，你必须换一个专用的恢复工具，那就是：BigDump！工具下载地址http://www.jb51.net/codes/37147.html8.使用bacula(www.bacula.org)进行备份 zZbacula采用模块化设计，采用c/s构架，理论上可以把任意n台主机的资料备份到任意n台中，而你不需要在每台机器上都写一个配置文件控制他们运作，所有主要的工作都在一台director上控制。登陆上director你就可以知道什么备份正在运行，什么备份成功了，什么备份失败了，所有的log也会集中到你指定的地方，让管理工作更简单一点。恢复的时候也很简单，简单运行几个命令你就可以把指定的备份恢复。支持完全备份，差异备份，增量备份；支持把备份写到硬盘文件中，也支持写到磁带中。支持平台相当多，设置包括win平台（备份win，还不支持备份到win）。当然也有一些缺点，比如对并发备份支持未经彻底测试，作者宣称最好不要尝试，除非你自己经过测试。还有一点就是文档中没有一个quick start。。文档太详细了点，没有点耐心读不完。。1,前期准备bacula有三个模块组成。一个是Director，用于指挥整个系统运行，job schedule,通知另外两个模块工作。一个是Storage Daemon，它是存储端，负责把网络中传来的数据备份到本机,恢复的时候负责把数据传出去。最后一个是File Daemon，备份时把文件传出，恢复时接受数据并恢复。其实上面的三个模块并不能让bacula运行，另外一个模块是数据库模块。这个模块可以通过SQLite（编译进bacula），也可以使用MySql和PostgreSql,作者推荐的是mysql。还需要一些第三方库才能编译：GZIP和Readline。文档中没有说明，但其实还需要另外一个软件才能保证正常运行：ntp。因为差异备份和增量备份都依赖于文件修改时间来决定是否备份。单机备份问题不大，网络备份就需要考虑各个主机的时间差异了。所以我推荐所有主机每天运行两次ntpdate来调准时间。如果你在sjtu网络里面，可以使用dns.sjtu.edu.cn来调校时间。如果你使用的是磁带机备份，还需要检查一下你的磁带机是否被支持。而且最好去阅读文档中的Understanding Pools, Volumes and Labels一节。否则配置的时候你会搞得晕乎乎的。2，编译编译过程很简单，文档也很详细，就不具体介绍了。注意一点是被备份机器上可以使用--enable-client-only编译。3，数据库建立下面说说mysql的建立过程。首先在代码根目录中cd src/cats/./grant_mysql_privileges./create_mysql_database./make_mysql_tables如果mysql不是在本机上，可以增加-h参数指定。默认采用空密码的root用户，可以用-p参数使其采用密码验证。如果要采用其它用户就只能修改脚本了，很简单的。默认建立的bacula用户，而且是空密码。推荐还是修改密码。bacula可以使用任意多的数据库，也就是说你可以使用两个数据库，然后再让这两个数据库互相备份。4，运行File Daemon(fd)配置前先说明一点需要注意的,配置中指定主机地址时，最好使用ip，我配置时使用主机名貌似不可以。。而且要是对外的ip，用127.0.0.1不行fd运行在被备份主机上。配置相当简单，指定哪个Director可以运行调度它，密码是什么，fd的名字，工作目录，log往哪里发就可以了。修改修改标配就可以了。5，运行Storage Daemon(sd)sd运行在接受备份的机器上。配置也相当简单，只是比fd多出了一个device用于指定使用什么硬件备份数据。可以把多个数据备份到一个device，如果是磁带机备份bacula在恢复的时候会告诉你要使用哪个磁带。因为我使用的是文件备份的模式，所以就给每个备份配置一个device，把不同的备份放到不同目录去，下面是一个简单文件备份device配置Device {Name = dbdevMedia Type = File #这个随便写，但是在配置Director中的Storage时，必须写一样的Archive Device = /var/bak/db#备份到哪个目录，必须存在LabelMedia = yes; # 自动labelRandom Access = Yes;AutomaticMount = yes;
对mysql的数据进行备份与恢复的几种方式
备份IP为192.168.1.100某个库： D:\APM\APMServ5.2.6\MySQL5.1\bin mysqldump -h 192.168.1.100 -u root -p ucenter d:\sql\uc_20130306.sql Enter password: **** 备份某个库下的某个表: mysqldump -u root -p密码 dbname tablenamed:\test.sql 备份全库: m 备份IP为192.168.1.100某个库：D:\APM\APMServ5.2.6\MySQL5.1\bin>mysqldump -h 192.168.1.100 -u root -p ucenter >d:\sql\uc_20130306.sqlEnter password: ****备份某个库下的某个表:mysqldump -u root -p密码 dbname tablename>d:\test.sql备份全库:mysqldump -u root -p密码 –all-databases >d:\test.sql备份dbname 数据库的结构:mysqldump -u root -p -d –add-drop-table dbname >d:\sql\a.sql说明：-d 没有数据 –add-drop-table 在每个create语句之前增加一个drop table导入数据库：D:\APM\APMServ5.2.6\MySQL5.1\bin>mysql _u root _p [dbname] 参数说明：Dbname参数表示数据库名称。该参数可选，可以指定数据库名，也可以不指定。指定数据库名时，表示还原该数据库下的表。不指定数据库名时，表示还原特定的一个数据库
如何使用MYSQL数据库进行备份数据恢复
数据库毁坏发生的原因有许多，且程度各不相同。如果幸运的话，可能是一两个表的小毁坏（例如，如果您的机器由于断电而暂时停机）。如果不是这 样，可能需要置换整个的数据目录（例如，如果某个磁盘瘫痪而且数据目录在它上）。在其他情况下也需要恢复操作，例 数据库毁坏发生的原因有许多，且程度各不相同。如果幸运的话，可能是一两个表的小毁坏（例如，如果您的机器由于断电而暂时停机）。如果不是这 样，可能需要置换整个的数据目录（例如，如果某个磁盘瘫痪而且数据目录在它上）。在其他情况下也需要恢复操作，例如，当用户错误地删除数据库或表时，或者 错误地删除表的内容时。不论这些不幸的事件发生是由于什么原因，都需要恢复它们。如果表被毁坏但没有丢失，可试着用myisamchk 或isamchk 来修复它们。如果修复实用程序能修复它们，就根本没有必要使用备份文件。如果表被丢失或不能修复，则需要恢复它们。恢复过程包括两个信息源：备份文件和更新日志。备份文件将表恢复到进行该备份时的状态。但是，在备份和故障发生这段时间中，表通常已经被修改。 更新日志包含了用来完成这些修改的查询。可以通过将更新日志作为对mysql的输入来重复这些查询（这就是为什么需要更新日志的原因。如果您还没有使更新 日志有效，现在赶快做，并在进一步读取之前生成一个新的备份）。恢复过程根据必须恢复的信息的多少而变化。事实上，恢复整个数据库比恢复单个的表要容易，因为对数据库应用更新日志比对表要容易。恢复整个数据库首先，如果要恢复的数据库是含有授权表的mysql数据库，将需要使用--skip-grant-tables选项运行服务器。否则，服务器将 抱怨无法找到授权表。在恢复表之后，执行mysqladmin flush-privileges 来告诉服务器加载授权表，并用它们启动。将原数据库目录的内容拷贝到其他的地方。例如，您可能会在稍后用它们进行崩溃表的事后分析检查（post-mortem examination）。用最新的备份文件重新加载数据库。如果您打算使用由mysqldump 加载的文件，则需要将它们作为mysql的输入。如果打算使用从数据库中直接拷贝的文件（如，用tar 或c p），则将它们直接拷贝回到该数据库目录中。但是，在这种情况下，应该在拷贝这些文件之前关闭服务器，然后再重新启动它。用更新日志重做在进行备份后又修改了数据库表的查询。对于所有可用的更新日志，可使用它作为mysql的输入。指定--one- database 选项，使mysql只对想要恢复的数据库执行查询。如果您知道需要使用所有的更新日志文件，可在包含日志的目录中使用下列命令：% ls-t-r-l update.(0-9)* | xargs cat | mysql--one-database db_namels 命令产生更新日志文件的单列列表，更新日志文件根据服务器生成的顺序进行排序（要知道，如果您修改了其中的任何文件，排序的顺序都将改变，这将导致更新日志按错误的顺序使用）。您很可能必须使用某些更新日志。例如，如果自备份以来所产生的日志命名为update.392、pdate.393 等等，可以重新运行它们中的命令： % mysql--one-database db_name 如果正在运行恢复并打算使用更新日志恢复由于失策的DROP DATA BASE、DROPTABLE或DELETE 语句而丢失的信息，应确保先从更新日志中删除这些语句。恢复单个的表恢复单个表是很困难的。如果有通过mysqldump 生成的备份文件并且它恰好不包含您想要的表数据，则需要抽取相关的行并用它们作为mysql的输入，这部分较容易。困难的是抽取应用于该表的更新日志的片 段。您会发现： mysql_find_rows 实用程序对这方面有帮助，它可以从更新日志中抽取多行查询。另一种可能性是用另一个服务器恢复整个数据库，然后将所要的该表的文件拷贝到原始数据库中。这实际很容易！在将文件拷贝回数据库目录时，应确保原始数据库的服务器关闭。 ，
MySql数据库备份的几种方式
备份数据库中的某个表$> mysqldump -u root -h host -p dbname tbname1, tbname2 > backdb.sql备份多个数据库$> mysqldump -u root -h host -p --databases dbname1, dbname2 > backdb.sql备份系统中所有数据库$> mysqldump -u root -h host -p --all-databases > backdb.sql直接复制整个数据库目录(对于InnoDB存储引擎不适用)备份windowns: installpath/mysql/datalinux: /var/lib/mysql在复制前需要先执行如下命令：MYSQL> LOCK TABLES;# 在复制过程中允许客户继续查询表，MYSQL> FLUSH TABLES;# 将激活的索引页写入硬盘。mysqlhotcopy工具备份备份数据库或表最快的途径，只能运行在数据库目录所在的机器上，并且只能备份MyISAM类型的表。要使用该备份方法必须可以访问备份的表文件。$> mysqlhotcopy -u root -p dbname /path/to/new_directory;#将数据库复制到new_directory目录。mysql命令导入sql文件还原$> mysql -u root -p [dbname] < backup.sql# 执行前需要先创建dbname数据库，如果backup.sql是mysqldump创建的备份文件则执行是不需要dbname。MYSQL> source backup.sql;# 执行source命令前需要先选择数据库。直接复制数据库目录还原注： 该方式必须确保原数据库和待还原的数据库主版本号一致，并且只适用于MyISAM引擎的表。关闭mysql服务。将备份的文件或目录覆盖mysql的data目录。启动mysql服务。对于linux系统，复制完文件后需要将文件的用户和组更改为mysql运行的用户和组。mysqlhotcopy快速恢复停止mysql服务，将备份数据库文件复制到存放数据的位置（mysql的data文件夹），重先启动mysql服务即可(可能需要指定数据库文件的所有者)。$> cp -R /usr/backup/test /usr/local/mysql/data# 如果恢复的数据库已经存在，则使用DROP语句删除已经存在的数据库之后，恢复才能成功，还需要保证数据库版本兼容。相同版本数据库之间迁移$> mysqldump -h www.abc.com -uroot -p password dbname | $> mysqldump -h www.bcd.com -uroot -p password# 将服务器www.abc.com的数据库dbname迁移到服务器www.bcd.com的相同版本数据库上。不同版本的mysql数据库之间的迁移备份原数据库。卸载原数据库。安装新数据库。在新数据库中还原备份的数据库数据。数据库用户访问信息需要备份mysql数据库。默认字符集问题，MySQL4.x中使用latin1作为默认字符集，mysql5.x使用utf8作为默认字符集。如果有中文数据需要对默认字符集进行更改。不同数据库之间的迁移MyODBC工具实现MySQL和SQL Server之间的迁移。MySQL Migration Toolkit工具。表的导出和导入SELECT ...... INTO OUTFILE 导出文本文件,该方法只能导出到数据库服务器上，并且导出文件不能已存在。MYSQL> SELECT ...... INTO OUTFILE filename [OPTIONS]MYSQL> SELECT * FROM test.person INTO OUTFILE "C:\person0.txt";# 将表person里的数据导入为文本文件person0.txt。mysqldump文件导出文本文件(和INTO OUTFILE不一样的是该方法所有的选项不需要添加引号)$> mysqldump -T path -u root -p dbname [tables] [OPTIONS]# -T参数表明导出文本文件。path导出数据的目录。$> mysqldump -T C:\test person -u root -p# 将test表中的person表导出到文本文件。执行成功后test目录下会有两个文件，person.sql和person.txtmysql命令导出文本文件MYSQL> mysql -u root -p --execute="SELECT * FROM person;" test > C:\person3.txt;# 将test数据库中的person表数据导出到person3.txt文本文件中。--vartical参数可以将一行分为多行显示。MYSQL> mysql -u root -p --vartical --execute="SELECT * FROM person;" test > C:\person3.txt;# --html将表导出为html文件，--xml文件将表导出为xml文件LOAD DATA INFILE导入文本文件MYSQL> LOAD DATA INFILE ‘filename.txt‘ INTO TABLE tablename [OPTIONS] [IGNORE number LINES];# [IGNORE number LINES]表示忽略行数MYSQL> LOAD DATA INFILE ‘C:\person0.txt‘ INTO TABLE test.person;mysqlimport导入文本文件$> mysqlimport -u root -p dbname filename.txt [OPSTONS]# 导入的表名有文件名决定，导入数据之前表必须存在$> mysqlimport -uroot -p test C:\backup\person.txt# 将数据导入到test数据库的person表中。使用mysqlbinlog恢复数据$> mysqlbinlog [option] filename | mysql -u user -p password# filename为二进制日志文件，$> mysqlbinlog --stop-date="2013-03-30 15:27:47" D:\MySQL\log\binlog\binlog.000008 | mysql -u root -p password# 根据日志文件binlog.000008将数据恢复到2013-03-30 15:27:47以前的操作。启动二进制日志log-bin = path/filename #日志文件存储目录和文件名expire_log_days = 10 #日志自动删除时间max_binlog_size = 100M # 日志文件最大大小查看二进制日志MYSQL> SHOW VARIABLES LIKE ‘log_%‘;MYSQL> SHOW BINARY LOGS;$> mysqlbinlog filename# filename为二进制日志文件名。删除二进制日志MYSQL> RESET MASTER; #删除所有二进制日志MYSQL> PURGE {MASTER | BINARY} LOGS TO ‘log_name‘; #删除文件编号小于log_name编号的文件MYSQL> PURGE {MASTER | BINARY} LOGS BEFORE ‘date‘; #删除指定日期以前的文件暂时停止二进制日志（不需要重启mysql服务）MYSQL> SET sql_log_bin = {0|1} #暂停或启动二进制日志。MySql数据库备份的几种方式标签：userbaseload datamaster服务器reset表数据sql存储
linux中mysql如何备份与恢复(mysql备份和恢复数据库命令)
把以前写的一个发你看看
脚本要求：编写shell脚本，每天凌晨1点备份td_oa库，到mysql-back目录，并将备份文件压缩，压缩名称为备份的日期，只保留连续七天的备份文件
#!/bin/bash
mysql-uroot-p123456-e"flushtableswithreadlock;"锁住表
/usr/local/mysql/bin/mysqlmp-uroot-p123456td_oa--flush-logs--single-transaction
<td_oa.sql&< dev null#如果启动了binlog，--flush-logs刷新日志，--single-transaction保证数据的一致性
mysql-uroot-p123456-e"unlocktables;"解锁
a=`/bin/date%Y-%m-%d`#在这里加上时间，压缩的时候加上时间，会失败。
echo$a
cd/gxl
/bin/tar-czf$a.tar/fjp/td_oa.sql
b="$a.tar"
cp-p$b/root/fjp
forcin`find/root/fjp-ctime7`
do
/bin/rm-rf$c
done
</td_oa.sql&
mysql中备份和还原数据库的语句什么啊
mysql数据库备份：mysqldump -uDB_USER -pDB_PASSWD DB_NAME > ****_backup.sql如果只是想备份库中某些表：mysqldump -uDB_USER -pDB_PASSWD DB_NAME table01 table02 > ****_backup.sqlmysql数据恢复还原：mysql -uDB_USER -pDB_PASSWD DB_NAME < ****_backup.sql
一、Mysql数据库备份指令格式：
mysqldump -h主机名 -P端口 -u用户名 -p密码 (–database) 数据库名 > 文件名.sql
注：直接cmd执行该指令即可，不需要先mysql -u root -p链接数据库
1、备份MySQL数据库的命令
mysqldump -hhostname -uusername -ppassword databasename > backupfile.sql
2、备份MySQL数据库为带删除表的格式，能够让该备份覆盖已有数据库而不需要手动删除原有数据库。
mysqldump -–add-drop-table -uusername -ppassword databasename > backupfile.sql
二、数据库还原有三种方式：source命令、mysql、gunzip命令
1、source 命令
进入mysql数据库控制台，
mysql -u root -p
mysql>use 数据库
然后使用source命令，后面参数为脚本文件（如这里用到的.sql）
mysql>source /home/work/db/bkdb.sql
2、mysql
mysql -hhostname -uusername -ppassword databasename < backupfile.sql
3、gunzip
gunzip < backupfile.sql.gz | mysql -uusername -ppassword databasename
MySQL 常用备份工具流程解析
下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程。
MySQL 常见的备份工具主要分为三种：
这里先说一下 binlog 备份，它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复。
mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句。mysqldump 的备份流程大致如下：
从上面可以看出在 mysqldump 备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK），直到备份结束。当然我们可以选一个从库进行备份，这样就不会影响线上业务。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的。
但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸。例如，使用 mysqldump 常见的问题有：
所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么操作，会对现有数据造成什么影响。
Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里不再单独介绍。
Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下：
Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题。
使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析。
通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首选；mysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响。
备份策略主要有：全量备份和增量备份，再加上 binlog 备份。
目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同，全量备份的频率不同。备份程序主要架构如下：
说明：
Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中，数据库可以进行正常的读写或者其他变更操作，但是偶尔也会遇见备份引起的元数据锁，或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。
说明：以下对 Percona XtraBackup 的分析都是基于 2.4.23 的版本，其他版本会略有差别，但是关键步骤基本相同。
XtraBackup 在备份开始时，会创建一个后台线程，专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部，找出当前的 checkpoint lsn ，然后从该 lsn 后顺序拷贝所有的 redo log ，包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成，才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下：
在拷贝ibd文件之前，会先扫描数据库的数据文件目录，获取ibdata1，undo tablespaces及所有的ibd文件列表，并会记录相应的 space id，因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容，以及对应的redo log条目。然后开始循环拷贝ibdata1，undo tablespaces及所有的ibd文件。 这里可通过设置--parallel进行多线程备份，提高物理文件的拷贝效率。不设置则默认为1。
在所有ibd文件拷贝完成后，XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂，因为备份非ibd文件前需要加锁，具体是否会加锁主要受到--no-lock 参数设置的影响。
若是设置了--no-lock为TRUE，则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁，但是若备份过程中对non-InnoDB表执行了DDL或者DML操作， 这会导致备份的不一致，恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE，默认值是FALSE，也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。
下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑：
流程图如下：
总结来看：
1）若--no-lock为FALSE（默认值），则先施加全局读锁，然后再进行拷贝文件，另外若 --safe-slave-backup 设置为TRUE ，则会在加全局锁之前关闭SQL_THREAD线程；
2）若--no-lock为TRUE，则不会施加锁，直接进行拷贝文件。
加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码，如下：
lock_tables_maybe 函数简化处理流程如下：
1）若备份实例上已经加锁（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者设置lock-ddl-per-table 则直接返回；
2）若支持备份锁，则执行LOCK TABLES FOR BACKUP；
3）若不支持备份锁，则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置，在执行该操作前会判断是否有执行中的DDL/DML，以及等待超时时间，是否kill 对应的未结束的事务等。
从上文中我们还看到一个参数--safe-slave-backup ，该参数的主要作用是：
若是在从库执行的备份操作时设置了该参数，可以防止因从库同步主库操作，而导致XtraBackup长时间请求不到锁而造成备份失败。
若是设置了 --safe-slave-backup 为TRUE，那么会执行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件，Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成，这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。
备份完非 ibd 文件后，将会备份 slave 和 binlog 信息。
mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1
需要注意，在支持备份锁的实例上备份，指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁（ LOCK BINLOG FOR BACKUP），这会阻塞任何会更改 binlog 位点的操作。
备份完数据库的所有文件和binlog等相关信息，备份工作就基本完成了，之后主要执行的操作如下：
1）执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘；
2）停止redo log复制线程；
3）释放全局读锁（备份锁），binlog锁；
4）开启SQL_THREAD；
5）拷贝ib_buffer_pool和ib_lru_dump文件；
6）生成配置文件backup-my.cnf；
7）打印备份信息到xtrabackup_info文件，这些信息主要包含备份时使用的参数信息，备份起止时间，binlog位点信息，以及将会回到的lsn点。
下面是xtrabackup_info记录的部分内容：
加锁对应的函数是 mdl_lock_tables ，释放锁对应的函数是 mdl_unlock_all，主要是执行COMMIT，结束 mdl_lock_tables 中开启的显式事务，来释放MDL锁。mdl_lock_tables 流程如下：
上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的，因为 MySQL 5.7 新增了一个叫做 Sorted Index Builds 的功能，这会导致某些 DDL 操作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁，阻止 DDL 操作。
另外，若备份时指定了--lock-ddl或--lock-ddl-per-table，则在备份非 ibd 文件时就不是再有加锁操作。
注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行，Percona Server for MySQL已经在 5.6.16-64.0 版本开始支持这种更加轻量的备份锁。
Q1: 使用 XtraBackup 备份的文件进行恢复时，恢复到哪个时间点？ A1：恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点，因为这时任何改变 binlog 位点的操作都会被阻塞，redo log和binlog 是一致的。
Q2: 在开启 binlog 的情况下，MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的，为什么XtraBackup 不用备份binlog？
A2：因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改变binlog位点的操作，这样只需要根据redo log将有commit log 的事务提交，没有commit log的事务进行回滚即可。
Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些？
A3：通过分析备份流程可以发现备份 binlog 位点信息（加binlog锁）是发生在停止 redo 拷贝线程前，而释放锁是在停止 redo 拷贝线之后，所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息，未提交的事物也就没有对应的 commit log 的信息，即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ，但是事务无法提交，也就没有 commit log 的信息的，最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。
Q4：Percona XtraBackup什么时候会加锁，以及影响加锁时间长度的因素有哪些？
A4：上面进行了分析，加锁操作只在备份非 ibd 文件时执行，加锁时长主要和非事务表的数量和大小有关，非事务表的数量越多，体积越大，拷贝文件所用的时间越长，那么加锁时间也就越长。也会和 redo log 生成的速度有关，只是 redo log 刷盘受到多个因素的影响，未及时刷盘的 redo log 一般很小。
Q5：Percona XtraBackup 和mysqldump选择哪个更好？
A5：通过上面的的解析，若是整个实例备份，首先选择 Percona XtraBackup ，因为对数据库的影响最小。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump 。注意，对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务。