MySQL数据库-备份恢复（6）
使用mysqldump加拷贝binlog的方式实现mysql增量备份
1. 主备模式下，一般使用备库来做数据库的备份；
2. 增量备份一定要基于完全备份之上。也就是说，在增量备份之前，一定要存在一个完全备份；
3. 完全备份首先要判断读取的master配置和重演master的配置是否相等，如果不相等表示存在读取了master的数据，但是还没有重演到slave的数据；
4. 在3中相等的情况下，停止复制线程，然后flush tables with read lock锁住备库；
5. 成功锁定之后，使用flush logs切换到新的binlog，并且记录下来（比如就是mysql-bin.000004，它就是我们增量备份的起点）；
6. 保持4中锁定，再使用mysqldump导出库；
7. 完全备份结束，此时我们拥有了一个导出文件和5中记录的binlog文件名；
8. 接下来可以释放4中持有的锁定，然后启动复制线程；
生产工作一段时间（比如24小时）后，此时我们需要增量备份了。
很明显，我们上次备份时备库切换到了新的binlog上，这样我们直接拷贝包括新的binlog文件开始的所有binlog文件即可。
但是正在被使用的那个binlog文件，我们直接拷贝的话，就必然有数据一致性的问题。
所以，我们在拷贝之前，必然要停止复制，然后锁住数据库，再切换到新的binlog（比如是mysql-bin.000015），然后拷贝到上一个mysql-bin.000014即可。
这样此次增量备份我们仅仅拷贝了004号到014号的11个文件。而下一次增量备份，我们就直接从mysql-bin.000015开始了。
ps，mysql的备份确实比较“弱”，上面的增量方案也只适用于一些小库，如果数据库超过百gb，那么这种方案在实施过程中还是有不少麻烦。
网上比较火的percona-xtrabackup备份工具，个人认为可控性不强，很容易报错，也不怎么推荐。
Oracle官方付费的backup工具也没有接触过。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：15130次
积分：1312
积分：1312
排名：千里之外
原创：122篇
(3)(52)(2)(56)(14)比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
MYSQL自动备份
策略的方案
　　目前流行几种备份方式：
　　一、逻辑备份：使用自带的mysqldump工具进行备份。备份成sql文件形式。
　　优点：最大好处是能够与正在运行的mysql自动协同工作，
　　在运行期间可以确保备份是当时的点，它会自动将对应操作的表锁定，不允许其他用户修改(只能访问)。可能会阻止修改操作。sql文件通用方便移植。
　　缺点：备份的速度比较慢。如果是数据量很多的时候。就很耗时间。如果处在提供给用户服务状态，在这段长时间操作过程中，意味着要锁定表(一般是读锁定，只能读不能写入数据)。那么服务就会影响的。
　　备注：所谓的与mysql服务器能够自动协同工作，实际上是指加参数来控制mysql服务器，比如锁定所有表只能进行读，不能进行写操作。
　　--lock-all-tables
　　二、物理备份：直接拷贝mysql的数据目录。缺点，你不能去操作正在运行的mysql服务器(在拷贝的过程中有用户通过应用程序访问更新数据，这样就无法备份当时的数据)可能无法移植到其他机器上去。
　　直接拷贝只适用于myisam类型的表。这种类型的表是与机器独立的。但实际情况是，你设计数据库的时候不可能全部使用myisam类型表。你也不可能：因为myisam类型表与机器独立，方便移植，于是就选择这种表，这并不是选择它的理由。
　　更多的情况是，你会根据业务特点(比如你需要支持事务机制就必须使用innodb)，查询速度和服务性能来选择表类型的。
　　必须保证表不被使用中。
　　如果服务器在你则正在拷贝一个表时改变它，拷贝就失去意义。
　　如果数据库表在文件系统备份过程中被修改，进入备份的表文件主语不一致的状态，而对以后的恢复表将失去意义。
　　保证你的拷贝完整性的最好方法是：关闭服务器，拷贝文件，然后。
　　或者是，要锁定对应的表(对前端用户造成访问问题)。
　　解释直接拷贝文件，为什么不具备可移植性？
　　Mysqldump 产生可移植到其他机器、甚至具有不同硬件结构的机器上的文本文件。直接拷贝文件不能够移植到其他机器上，除非要拷贝的表使用MyISAM格式。 表只能在具有相同硬件结构的机器之间进行拷贝。例如，将文件从S PARC 的Solaris 机器拷贝到 的Solaris 机器(或者相反)是行不通的。由MySQL3.23 引进的MyISAM 表存储格式可以解决这个问题，因为该格式与机器独立。因此，如果以下两个条件都满足的话，直接拷贝文件可以移植到具有不同硬件结构的机器上：即另一台机器上也必须运行MySQL3.23 以上的版本，并且文件必须表示成MyISAM 表，而不是ISAM 表。
　　三、双机热备份：mysql数据库没有增量备份的机制。当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制(也就是双机热备)。
　　优点：适合数据量大的时候。现在明白了。大的公司对于mysql数据备份，都是采用热机备份。搭建多台数据库服务器，进行主从复制。
　　主从复制经常遇到的问题就是，如何保证数据不堵塞，不延迟。这个问题还是可以容忍的，有一些可以改善。毕竟有得有失的。这已经是很省心省力的方式了。
　　================================================
　　我目前应该使用什么样的备份策略的权衡：
　　物理备份，恢复快，当然最好是存储在一个机器上。我现在是用物理备份还是逻辑备份为好呢？
　　考虑到以后会迁移平台。为了保证通用性。恢复速度1分钟左右的差距我是可以容忍的。所以我为了跨平台，我更加愿意使用逻辑备份。存储sql文件形式。
　　双热机备份方式，目前硬件没有多个。技术人员有限，需要人力去维护，比较麻烦。所以排除在外。
　　四、方案：
　　1、总体策略：写个定时执行任务。定时在晚上或凌晨(考虑数据库服务器在运行中不能停机)
　　代码中做成备份成功后，把以前的删掉。避免很多数据占据。
　　2、考虑到初期数据量这么小。使用mysqldump进行备份吧。设置在凌晨几点(4-6点这个时候基本上没什么人访问)的时候自动备份。
　　3、使用逻辑备份方式：恢复速度1分钟左右的差距我是可以容忍的。所以我为了跨平台，我更加愿意使用逻辑备份。存储sql文件形式。
　　4、每天都进行备份。由于是在凌晨的时候mysqldump去锁定，访问数据库服务器。对服务器几乎没什么影响。所以每天备份。每天都一个sql文件。那么将会很多文件。
　　所以，每次备份成功后。删除以前的文件。保留最近一个星期的备份sql文件。
　　备份工具的路径：/usr/bin/mysqldump
　　备份数据保存路径：/data/backdata/
　　五、备份脚本的编写
　　思路：
　　1、在shell脚本中调用mysqldump生成备份文件(这个工具可以生成sql文件到磁盘上去);
　　2、为了方便以后查找。每次备份的记录记录成日志形式。几点进行了备份操作，生成了什么文件名称。这样可以方便以后查阅哪天是否没有成功备份删除的文件作为日志信息也记录下来。
　　3、让下的crontab进程调用脚本执行。
　　命令：crontab -e
　　打开的文件中加入代码：0 05 * * * 脚本的路径/mysqlback.sh
　　mysqlback.sh的内容：
　　# /bin/bash DB_NAME="****" DB_USER="****" DB_PASS="****" BIN_DIR="/usr/bin" BACK_DIR="/data/backdata" DATE="mysql-`date +'%Y%m%d-%H:%M:%S'`" LogFile="$BACK_DIR"/dbbakup.log #日志记录保存的目录 BackNewFile=$DATE.sql $BIN_DIR/mysqldump --opt --force -u$DB_USER -p$DB_PASS $DB_NAME & $BACK_DIR/$DATE.sql echo ----------"$(date +"%y-%m-%d %H:%M:%S")"------------ && $LogFile echo createFile:"$BackNewFile" && $LogFile #find "/data/backdata/" -cmin +1 -type f -name "*.sql" -print & deleted.txt find "/data/backdata/" -ctime +7 -type f -name "*.sql" -print & deleted.txt echo -e "delete files:\n" && $LogFile #循环删除匹配到的文件 cat deleted.txt | while read LINE do rm -rf $LINE echo $LINE&& $LogFile done echo "---------------------------------------------------------------" && $LogFile
[ 责任编辑：jj ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte用户名：icy2013
文章数：119
评论数：22
访问量：47782
注册日期：
阅读量：1297
阅读量：3317
阅读量：454589
阅读量：1139240
51CTO推荐博文
三种备份方式完全备份命令1，实现逻辑角度的热备份、温备温备# mysqldump --master-data=2 --all-databases --lock-all-tables & /backup/all.sql热备# mysqldump --master-data=2 --single-transaction --all-databases & /backup/all.sql2，实现物理层面的几乎完全热备份# cp -r * /backup/3,xtrabackup实现完全热备份和增量备份# innobackupex --user=testuser --password=testpwd --host=localhost /backup/需要注意的地方1、个人认为mysqldump的温备是最简单的备份方式，就是速度慢了点，适合对少量数据备份。# mysqldump --master-data=2 --all-databases --lock-all-tables & /backup/all.sql2、mysqldump备份的时候如果在终端使用了读锁命令，备份完了别忘了解锁mysql& flush tmysql&3、基于逻辑卷的备份，同样如此，在创建快照的时候，肯定会有对表的读锁请求，快照创建完了，就应该立马释放读锁。4、数据库在被初始化了之后，初始化生成的表会有多种存储引擎，那么，有人就会问，我们备份myisam引擎的表时，需要对表进行加锁，才能备份到完整的数据，那这些自动生成的拥有各种引擎的表，我们复合备份呢。我来给你解惑：XtraBackup 是一个用来备份
数据库的开源工具。因此，让它去备份myisam引擎的表，也需要加锁，这样就实现不了热备了。所以，我们在使用mysql时，一定要将默认的存储引擎修改为innodb，最好将这个参数也启用起来掉：innodb_file_per_table=1。而当我们去做备份的时候，其实不用去管那些数据库初始化生成的那些表会不会被完全备份，因为，我们做备份恢复的时候，需要重新初始化的，这些数据都是自动生成的，不需要想太多，只需要在初始化完了之后将存储引擎改为innodb就好说了。一，实现逻辑角度的热备份（施加锁时，也有温备一说）1，前提1.1最好将数据文件单独存放在一个逻辑卷上，然后二进制文件再另外存放在与数据文件不是一个磁盘的地，最好放在非同一个上，这样做最保险。1.2 mysql的安装过程不再演示，详细请看其他博客。1.3 编辑配置文件，设置数据目录和二进制文件目录# vim /f
log-bin=/binlog/mysql-bin二进制文件的目录和默认文件名前缀
/binlog二进制文件存放目录，必须修改属组属主为mysql，否则服务启动会报错，/mydata/data
数据目录同样如此。
datadir = /mydata/data数据目录，mydata是逻辑卷的挂载点，data是数据库文件目录
创建备份目录
# mkdir /backup
# mkdir /binlog
# chown -R mysql.mysql /mydata/data
# chown -R mysql.mysql /binlog假设已经安装完毕，配置完毕，下面说步骤2，步骤2.1 初始化，设置数据文件，二进制文件的权限。# cd /usr/local/mysql
# scripts/mysql_install_db --user=mysql --datadir=/mydata/data/mydata/data是数据目录，/mydata是逻辑卷的挂载点# ls /binlog/binlog是二进制文件的存放目录。2.2初始化完毕，启动服务# service mysqld start2.3登录，做一些操作之后，进行完全热备份。# mysql
&创建数据库
&选择数据库
& create table tb1;创建一张表
&查看当前二进制文件所在位置，然后进行完全备份
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)另起一终端，进行完全备份# mysqldump --master-data=2 --single-transaction --all-databases & /backup/all.sql如果有给用户设定权限，不要忘了-u -h -p--master-data=2 表示将备份时刻所在的二进制文件的位置在备份出的中注释出来，方便之后查阅。--single-transaction 通过给数据创建快照，实现了热备份的功能，服务会启动一个超级事务，来处理这种机制--all-databases 备份所有数据库--master-data=0 表示不启用此功能--master-data=1 表示启用，但是以语句的形式显示，我们一般使用注释出来。记住此时所在的二进制文件的位置，如上表，mysql-bin.000001 409，做增量备份的时候要用到这个位置。忘记了也没关系，可以使用一下命令查找# less /backup/all.sql可以看到下面一行-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=409;mysqldump还有一种完全备份方式，在备份时给所有的表施加读锁，使数据只读不能写，因此称为温备。# mysqldump --master-data=2 --lock-all-tables --all-databases --events & /backup/all.sql--lock-all-tables也可以在终端使用命令flush t,但这种方式在备份完了之后还需要执行命令：unlock tables;,很明显，既然能在备份的时候一次指定读锁，这种方式明显麻烦，还是用简单的好。2.4系统崩溃前的写操作当前所在二进制文件是mysql-bin.000001，生产中我们在备份的时候，数据库肯定还有写操作在进行，所以，二进制文件肯定不会就到现在所在的位置，我们要刷新日志，然后对该二进制文件进行增量备份。我们在这里模拟，还有写操作在进行。&
& create table tb2(id int);
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |
+------------------+----------+--------------+------------------+假设，二进制文件在此时结束，我们刷新日志，表示它结束。&生产中，我们可能做任务计划的时候每天都要让日志刷新，这里就相当与模拟的任务计划中的刷新计划，方便我们对二进制文件的管理。我们会看到在二进制目录下新增了一个二进制文件mysql-bin.000002 &
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000002 |
+------------------+----------+--------------+------------------+2.5对mysql-bin.000001进行增量备份# cd /binlog
mysql-bin.000001
mysql-bin.index
# mysqlbinlog --start-position=409 --stop-position=494 mysql-bin.000001 & /backup/01.sql别忘了完全备份结束后的二进制文件所在的位置和我们模拟的二进制文件的结束的位置。注意，增量备份时，如果二进制文件过多，可以先cp二进制文件到备份目录下，然后统一导出，那样速度快一点。2.6继续对数据库进行修改，然后模拟数据库崩溃& create table tb3(id int);
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000002 |
+------------------+----------+--------------+------------------+我们已经在二进制文件mysql-bin.000002 的上了。假设，此时数据库崩溃，想一下，我们该如何应对。2.7首先，我们让服务离线，导出增量备份后，还没有备份的数据。# service mysqld stop# mysqlbinlog /binlog/mysql-bin.000002 & /backup/02.sql2.8模拟数据库崩溃# rm -rf /mydata/data/*# rm -rf /binlog/*2.9重新初始化服务，登录并设置不记录二进制文件# cd /usr/local/mysql
# scripts/mysql_install_db --user=mysql --datadir=/mydata/data
# rm -f /binlog/* 初始化的二进制文件没用，删不删都可
# service mysqld start
& set global sql_log_bin=0;我们要进行备份恢复，因此此时的二进制文件没有，所以，关掉二进制记录程序可以节省空间。注意log_bin 和的区别，前者是是否开启二进制日志功能，后者是是否记录二进制文件。开启了前者，后者不开启照样不会记录。3.0恢复数据两种方式：登录恢复和非登录恢复。登录恢复：& source /backup/all.sql
+--------------+
| Tables_in_db |
+--------------+
+--------------+可以看到完全备份时的状态，数据库db中只有一个表& source /backup/01.sql
+--------------+
| Tables_in_db |
+--------------+
+--------------+此时两张表& source & /backup/02.sql
+--------------+
| Tables_in_db |
+--------------+
+--------------+3.1恢复完毕，开启二进制日志记录功能，并重启服务& set global sql_log_bin=1;
# service mysqld restart二、基于实现物理层面的几乎热备份为什么说是几乎完全热备份呢，是因为在在创建快照卷的时候，要确保那一刻的数据是静止的，所有要实现申请所有表的读锁状态。快照创建完了，可以立马释放读锁。之后就是热备份了，而整个过程却并非是完全热备的。1、准备工作都一样，设置数据目录，二进制文件和备份目录，依然跟上边一样。数据目录二进制文件目录备份目录数据目录必须是一个逻辑卷的 挂载点，因为我们要基于实现热备，要对这个目录下的数据创建快照。2、请求读锁表& flush t不要退出，退出后读锁自动释放。&
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |
+------------------+----------+--------------+------------------+查看当前二进制日志所在的位置，这个一定要记住，因为物理备份的数据没有对二进制文件操作，增量备份的数据依赖于这个状态所在的位置。也可以通过命令# mysql -ullm -ppass -e '' & /tmp/master.sql 将之保存下来& show engine innodb status\G注意，请求读锁需要一段时间，不要急着给逻辑卷创建快照，等到缓存中的数据不再变更，再创建快照，否则，数据可能还会有所丢失。3、另启一终端，对逻辑卷创建快照。# lvcreate -s -p r -L 100M -n lv2-snap /dev/myvg/lv2
# mkdir /lv2-snap
# mount /dev/myvg/lv2-snap /lv2-snap/
# ls /lv2-snap/Data4、释放读锁&5、基于的物理备份# cd /mydata/data# cp -r * /backup/快慢由数据大小决定。6、依照第二部读锁表时记录的二进制文件所在位置进行增量备份，直到数据库崩溃。备份完了就可以恢复了。7、对数据恢复第一步就是将备份目录中的文件完全拷贝到数据目录下，别忘了修改数据目录的权限，然后进行增量恢复即可。步骤同。三、基于的热备安装工具包percona-xtrabackup-2.0.3-470.rhel5.i386.rpm，直接谷歌xtrabackup安装的时候可能遇到问题，提示依赖包没装，就需要确保、perl-DBI和已正确安装。1、一键安装xtrabackup# rpm -ivh percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm2、创建一个具有备份权限的最小权限用户。mysql& create user 'testuser'@'localhost' identified by 'testpwd';
mysql& revoke all privileges,grant option from 'testuser'@'localhost';注意，这里的'testuser'@'localhost'必须有localhost，否则会报错：ERROR 1269 (HY000): Can't revoke all privileges for one or more of the requested users
mysql& grant reload,lock tables,replication client on *.* to 'testuser'@'localhost';
reload,lock tables,replication client 备份的最小权限。
mysql&3、对数据库修改，以在恢复的时候做证明。mysql& create database db1;
mysql& use db1;
mysql& create table tb1(id int);
+------------------+----------+--------------+------------------+
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 |
+------------------+----------+--------------+------------------+这个位置在备份目录下的文件/backup/_15-02-36/xtrabackup_binlog_info中有记录备份完后可以看到4、以创建好的用户的身份进行完全备份# innobackupex --user=testuser --password=testpwd --host=localhost /backup/5、退出登录，停掉服务，模拟数据库崩溃# service mysqld stop我经常忘记停止服务，希望你不会跟我一样。如忘记了停止服务，可以killall mysqld。# rm -rf /mydata/data/*注意，二进制日志目录下的文件可别删除，有大用处。6、恢复前准备注意，与的恢复和基于的恢复不同的是，恢复不需要重新初始化数据库，初始化之后，反而会出问题，而却需要对备份进行准备恢复的处理。# innobackupex --apply-logpply-log /backup/_15-02-36--apply-log提交已提交的事务，回滚未回滚的事务7、直接恢复# innobackupex --copy-back /backup/_15-02-368、登录验证mysql& use db1;
+---------------+
| Tables_in_db1 |
+---------------+
+---------------+9、增量备份接着上边的做，再创建一表mysql& create table tb2(id int);增量备份# innobackupex --incremental /backup --incremental-basedir=/backup/_15-34-3010、恢复前准备# innobackupex --apply-log --redo-only /backup/_15-34-30
先对完全备份做准备
--apply-log 提交已提交的，撤销未提交的
--redo-only 对数据重放，“重放”之后，所有的备份数据将合并到完全备份上。
# innobackupex --apply-log --redo-only /backup/_15-34-30
--incremental-dir=/backup/_15-47-29对增量备份做准备11、退出服务，关闭服务，模拟崩溃# service mysqld stop
# rm -rf /mydata/data/*12、做备份恢复# innobackupex --copy-back /backup/_15-34-30 13、启动前别忘了修改数据目录下文件的权限，否则无法启动服务# chown -R mysql.mysql /mydata/data/*
# service mysqld start14、登录查看恢复是否成功mysql&
+---------------+
| Tables_in_db1 |
+---------------+
+---------------+发现我们增量备份的第二张表也回来了。Xtrabackup小结：与和基于的备份相同，当数据真正出现问题的时候，我们备份的只是当前一段时间之前的数据，比如我们备份的是昨天的数据。而要将数据恢复到今天中午之前，就不能再使用这种方式进行备份了，通过样需要使用二进制文件进行备份，即使用导出二进制文件，后续工作不再总结，都在中做了总结，不会请看上边mysqldump2.5中的内容。同时罗嗦一句，二进制文件重要非常，一定要妥善管理，不要一失足成千古恨。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)