linuxsir首页 LinuxSir.Org | Linux、BSD、Solaris、Unix | 开源传万世,因有我参与欢迎您!
网站首页 | 设为首页 | 加入收藏
您所在的位置:主页 > Linux数据库 >

MySQL数据库备份实例详解

时间:2019-01-26  来源:未知  作者:admin666
备份账号所需要的权限 : SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT, SHOW VIEW, PROCESS 如果使用--tab参数则还需要:FILE权限 3. 演示 首先创建备份用户
create user 'backup'@'localhost' identified by '123456';
赋予用户备份权限
grant select,reload,lock tables,replication client,show view,event,process on *.* to 'backup'@'localhost';
使用mysqldump进行全量备份 备份某个数据库
[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events mc_orderdb mc_orderdb.sql
如果遇到以下问题
mysqldump: Error: Binlogging on server not active

MySQL中二进制日志功能默认是关闭,去/etc/my.cnf 文件中加入下面配置,开启log_bin(数据库的操作日志)功能,然后重启mysql即可解决问题

log_bin=mysql-bin

之后使用 systemctl start mysql 重启服务器,报错

Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
解决方法:

在设置 log-bin 的时候同时需要设置 server-id 变量,即在配置文件中添加:

[mysqld] 
log-bin=mysql 
server-id=1 

然后再次重启即可

装mysql,运行一段时间后,在mysql目录下出现一堆类似mysql-bin.000***,从mysql-bin.000001开始一直排列下来,而且占用了大量硬盘空间,高达几十个G. 对于这些超大空间占用量的文件我们应该怎么办呢?
那么mysql数据库文件夹中的mysql-bin.00001是什么文件?
mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。
这些形如mysql-bin.00001的文件主要是用来做什么的呢?
1:数据恢复
如果你的数据库出问题了,而你之前有过备份,那么可以看日志文件,找出是哪个命令导致你的数据库出问题了,想办法挽回损失。
2:主从服务器之间同步数据 
主服务器上所有的操作都在记录日志中,从服务器可以根据该日志来进行,以确保两个同步。
如果不想要这些文件应该怎么做呢?
1:只有一个mysql服务器,那么可以简单的注释掉这个选项就行了。
vi /etc/my.cnf把里面的 log-bin 这一行注释掉,重启mysql服务即可。
2:如果你的环境是主从服务器,那么就需要做以下操作了。 
A:在每个从属服务器上,使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
B:使用SHOW MASTER LOGS获得主服务器上的一系列日志。
C:在所有的从属服务器中判定最早的日志,这个是目标日志,如果所有的从属服务器是更新的,就是清单上的最后一个日志。
D:清理所有的日志,但是不包括目标日志,因为从服务器还要跟它同步。
简单地说,这些MySQL目录下的形如mysql-bin.000***的文件时MySQL的事务日志。
删除复制服务器已经拿走的binlog是安全的,一般来说网络状况好的时候,保留最新的那一个足以。

再次执行之前的备份命令,即可成功被封mc_orderdb数据库下的所有表,我们可以查询一下备份的SQL文件中是否包含所有表

[root@localhost db_backup]# grep "CREATE TABLE" mc_orderdb.sql
CREATE TABLE `order_cart` (
CREATE TABLE `order_customer_addr` (
CREATE TABLE `order_detail` (
CREATE TABLE `order_master` (
CREATE TABLE `region_info` (
CREATE TABLE `shipping_info` (
CREATE TABLE `warehouse_info` (
CREATE TABLE `warehouse_proudct` (
[root@localhost db_backup]# 

通过上面结果可以看出我们的几个表都在其中

备份某个数据库下的某个表
[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events mc_orderdb order_master order_master.sql
Enter password: 
[root@localhost db_backup]# ls
mc_orderdb.sql order_master.sql
备份MySQL实例下的所有数据库
[root@localhost db_backup]# mysqldump -ubackup -p --master-data=1 --single-transaction --routines --triggers --events --all-databases mc.sql
Enter password: 
[root@localhost db_backup]# ls
mc_orderdb.sql mc.sql order_master.sql

由于master-data的值设置为1,change master命令并没有被注释掉,如果我们使用这个命令进行恢复,change master命令就会被执行,在一些情况下可能会造成一些错误,所以建议使用时最好还是设置为2

可以通过下面的命令查看,备份文件中包含哪些数据库

[root@localhost db_backup]# grep "Current Database" mc.sql
-- Current Database: `mc_orderdb`
-- Current Database: `mc_productdb`
-- Current Database: `mc_userdb`
-- Current Database: `mysql`
[root@localhost db_backup]# 
使用-tab参数指定备份文件的??置

首先在/tmp 目录下建立一个mc_orderdb目录用来存放指定的备份文件,之所以使用在此目录下建立目录,是因为使用--tab参数时,用户必须对目标目录有可写权限,而tmp目录对任何用户都有可写权限

[root@localhost db_backup]# mkdir -p /tmp/mc_orderdb

现在我们可以使用--tab参数指定备份路径

[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events --tab="/tmp/mc_orderdb" mc_orderdb 
Enter password: 
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
mysqldump: Got error: 1045: Access denied for user 'backup'@'localhost' (using password: YES) when executing 'SELECT INTO OUTFILE'

可以发现,报错了,其实我们在这之前还缺少一步,由于用户需要有写文件的权限,所以我们还需要对备份用户赋予file权限

mysql grant file on *.* to 'backup'@'localhost';
Query OK, 0 rows affected (0.00 sec)

我们再次执行上面的备份命令

[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events --tab="/tmp/mc_orderdb" mc_orderdb 
Enter password: 
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=347;
mysqldump: Got error: 1290: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement when executing 'SELECT INTO OUTFILE'

可以很清楚地从提示看到是因为mysql服务启用了 secure-file-priv,所以才无法执行。
那么 secure-file-priv又是什么呢,应该如何解决才能是它可以备份呢?
--secure-file-priv=name :
Limit LOAD DATA, SELECT ... OUTFILE, and LOAD_FILE() to files within specified directory

可以看到secure-file-priv参数是用来限制LOAD DATA, SELECT OUTFILE, and LOAD_FILE()传到哪个指定目录的。

当secure_file_priv的值为null ,表示限制mysqld 不允许导入|导出

当secure_file_priv的值为/tmp/ ,表示限制mysqld 的导入|导出只能发生在/tmp/目录下

当secure_file_priv的值没有具体值时,表示不对mysqld 的导入|导出做限制

查看数据库当前该参数的值

mysql show global variables like '%secure%'; 
+--------------------------+-----------------------+
| Variable_name | Value |
+--------------------------+-----------------------+
| require_secure_transport | OFF |
| secure_auth | ON |
| secure_file_priv | /var/lib/mysql-files/ |
+--------------------------+-----------------------+
3 rows in set (0.00 sec)

清楚地看到secure_file_priv 的值是NULL,说明此时限制导入导出的
所以应该改变该参数
可是查看了mysql.cnf中居然没有对这个参数进行设定,就说明这个参数默认便是null
所以再mysql.cnf中的[mysqld]加入secure_file_priv =

[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir=/home/mysql/data # mysql数据存放的目录
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
log_bin=mysql-bin
server-id=1 
secure_file_priv =

再重启mysql服务

[root@localhost tmp]# systemctl restart mysqld

然后再查一下此时参数的值

mysql show global variables like '%secure%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| require_secure_transport | OFF |
| secure_auth | ON |
| secure_file_priv | |
+--------------------------+-------+
3 rows in set (0.01 sec)

已经是我们要的结果 ,现在我们再次执行备份命令

[root@localhost tmp]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events --tab="/tmp/mc_orderdb" mc_orderdb 
Enter password: 
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=154;
mysqldump: Got error: 1: Can't create/write to file '/tmp/mc_orderdb/order_cart.txt' (Errcode: 13 - Permission denied) when executing 'SELECT INTO OUTFILE'

结果还是权限被拒绝,无法写入,我们可以查询一下目录mc_orderdb的权限,

[root@localhost tmp]# ls -lh mc_orderdb/
total 4.0K
-rw-r--r-- 1 root root 1.9K Jan 10 10:51 order_cart.sql

可以发现,是root用户建立的目录,我们需要修改其所属用户为mysql用户,然后再次执行备份命令

[root@localhost tmp]# chown mysql:mysql mc_orderdb
[root@localhost tmp]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events --tab="/tmp/mc_orderdb" mc_orderdb 
Enter password: 
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=154;
-- Dumping events for database 'mc_orderdb'
-- Dumping routines for database 'mc_orderdb'
[root@localhost tmp]# 

可以发现,修改成功后即可备份成功

进入该目录下会发现mc_orderdb数据库下的每个表都有两种文件,一种.sql结尾记录是表结构,一种是.txt结尾的表数据

[root@localhost tmp]# cd mc_orderdb/
[root@localhost mc_orderdb]# ls
order_cart.sql order_customer_addr.sql order_detail.sql order_master.sql region_info.sql shipping_info.sql warehouse_info.sql warehouse_proudct.sql
order_cart.txt order_customer_addr.txt order_detail.txt order_master.txt region_info.txt shipping_info.txt warehouse_info.txt warehouse_proudct.txt
mysqldump如何使用全备where参数

假设我们要对订单id为1000到1050的主表进行修改,修改之前,我们需要先对数据进行备份,这里我们就可以使用where参数来完成此需求

执行命令进行备份
[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --where "order_id 1000 and order_id 1050" mc_orderdb order_master order_master_1000_1050.sql
Enter password: 

查看备份文件可以发现,订单id是从1001开始的

在日程工作中我们不可能一直手工备份,所以我们需要将备份进行脚本话,然后使用计划任务去执行脚本

定义备份脚本
#!/bin/bash
###############Basic parameters##########################
DAY=`date +%Y%m%d` # 记录发生备份的当前日期
Environment=$(/sbin/ifconfig | grep "inet" | head -1 |grep -v "127.0.0.1" | awk '{print $2;}' ) # 当前主机的IP
USER="backup"
PASSWD="123456"
HostPort="3306"
MYSQLBASE="/home/mysql/"
DATADIR="/home/db_backup/${DAY}" # 备份存放的目录(/home/db_backup目录下的以日期命名的子目录中)
MYSQL=`/usr/bin/which mysql` # 定义mysql命令的目录
MYSQLDUMP=`/usr/bin/which mysqldump` # 定义mysqldump命令的目录
mkdir -p ${DATADIR} # 创建存储目录
# 定义备份函数,使用到上面定义的变量
Dump(){
 ${MYSQLDUMP} --master-data=2 --single-transaction --routines --triggers --events -u${USER} -p${PASSWD} -P${HostPort} ${database} ${DATADIR}/${Environment}-${database}.sql
 cd ${DATADIR}
 gzip ${Environment}-${database}.sql # 对文件进行了压缩
# 利用for循环对当前服务器下的每一个数据库(排除了一些系统视图所在的数据库)分别来调用上面的Dump函数来进行备份
for db in `echo "SELECT schema_name FROM information_schema.schemata where schema_name not in ('information_schema','sys','performance_schema')" | ${MYSQL} -u${USER} -p${PASSWD} --skip-column-names`
 database=${db}
 Dump
done
执行脚本文件
[root@localhost home]# bash backup.sh 
mysql: [Warning] Using a password on the command line interface can be insecure.
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@localhost home]# cd db_backup/
[root@localhost db_backup]# ls
20190110 mc_orderdb.sql mc.sql order_master_1000_1050.sql order_master.sql
[root@localhost db_backup]# cd 20190110/
[root@localhost 20190110]# ls
172.17.0.1-mc_orderdb.sql.gz 172.17.0.1-mc_productdb.sql.gz 172.17.0.1-mc_userdb.sql.gz 172.17.0.1-mysql.sql.gz

可以看到结果已备份,可以使用crontab命令定时执行此脚本

如何恢复mysqldump备份的数据库

方法一:

mysql -u -p dbname backup.sql

方法二:

mysql source /tmp/backup.sql

使用mysqldump备份时,恢复的速度完全取决于MySQL实例执行SQL的速度和服务器的IO性能,并且恢复过程是单线程的,所以对于非常大的数据集来说,要恢复的话可能需要很长的时间

把刚才的全备数据恢复到bak数据库中

创建bak_orderdb数据库

[root@localhost db_backup]# mysql -uroot -p -e"create database bak_orderdb"
Enter password: 

将mc_orderdb备份的数据恢复到bak数据库中

[root@localhost db_backup]# mysql -uroot -p bak_orderdb mc_orderdb.sql
Enter password: 
[root@localhost db_backup]# 

检验恢复结果的正确性

mysql SELECT COUNT(*) FROM mc_orderdb.order_master;
+----------+
| COUNT(*) |
+----------+
| 10010 |
+----------+
1 row in set (0.00 sec)
mysql SELECT COUNT(*) FROM bak_orderdb.order_master;
+----------+
| COUNT(*) |
+----------+
| 10010 |
+----------+
1 row in set (0.00 sec)
模拟误操作并恢复数据

假设我们现在不小心删除了mc_orderdb下的order_master中的10条数据,我们现在需要通过刚刚恢复的备份数据库把这10条数据恢复回来

mysql DELETE FROM mc_orderdb.order_master LIMIT 10;
Query OK, 10 rows affected (0.01 sec)
mysql SELECT COUNT(*) FROM mc_orderdb.order_master;
+----------+
| COUNT(*) |
+----------+
| 10000 |
+----------+
1 row in set (0.00 sec)

首先查出被误删的数据
SELECT a.* FROM bak_orderdb.order_master a LEFT JOIN mc_orderdb.order_master b ON a.order_id=b.order_id WHERE b.order_id IS NULL;
然后执行insert语句将查出的数据插入回去

完整语句为

INSERT INTO mc_orderdb.order_master(
order_id,order_sn,customer_id,shipping_user,province,city,district,address,
payment_method,order_money,district_money,shipping_money,payment_money,
shipping_comp_name,shipping_sn,create_time,shipping_time,pay_time,receive_time,
order_status,order_point,invoice_title,modified_time)
SELECT a.* FROM bak_orderdb.order_master a 
LEFT JOIN mc_orderdb.order_master b ON a.order_id=b.order_id
WHERE b.order_id IS NULL;

执行结果:

mysql INSERT INTO mc_orderdb.order_master(
 - order_id,order_sn,customer_id,shipping_user,province,city,district,address,
 - payment_method,order_money,district_money,shipping_money,payment_money,
 - shipping_comp_name,shipping_sn,create_time,shipping_time,pay_time,receive_time,
 - order_status,order_point,invoice_title,modified_time)
 - SELECT a.* FROM bak_orderdb.order_master a 
 - LEFT JOIN mc_orderdb.order_master b ON a.order_id=b.order_id
 - WHERE b.order_id IS NULL;
Query OK, 10 rows affected (0.03 sec)
Records: 10 Duplicates: 0 Warnings: 0
mysql SELECT COUNT(*) FROM mc_orderdb.order_master;
+----------+
| COUNT(*) |
+----------+
| 10010 |
+----------+
1 row in set (0.00 sec)

对于一些静态型数据我们可以这样进行,但是对于一些时刻有数据在往表里写的数据还原,就不能使用这种方式了

对于生产环境中,时刻有数据写入的表如何进行数据恢复呢?

mysqldump单表备份恢复(使用了--tab参数备份的结果集)

需要进入mysql客户端中

先恢复表结构

mysql source /tmp/mc_orderdb/region_info.sql;

再导入数据

mysql load data infile '/tmp/mc_orderdb/region_info.txt' info table region_info;
如何进行指定时间点的恢复

进行某一时间点的数据恢复,恢复到误操作的时间

先决条件:

具有指定时间点前的mysqldump的全备
具有全备到指定时间点的mysql二进制日志

首先我们需要有个数据库的全备,此处我们对mc_orderdb 数据库进行全备

[root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events mc_orderdb mc_orderdb.sql

然后我们模拟一下生产环境中对数据库的操作,这样才能看到时间点恢复的效果

我们到mc_orderdb数据库中新建一个统计表 t, uid列是用户id,cnt 是用户的总消费金额,将统计结果插入表t中后,模拟误操作,删除表t中的100行数据

mysql use mc_orderdb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql create table t(id int auto_increment not null,uid int,cnt decimal(8,2),primary key (id));
Query OK, 0 rows affected (0.02 sec)
mysql insert into t(uid,cnt) select customer_id,sum(order_money) from order_master group by customer_id;
Query OK, 6314 rows affected (0.05 sec)
Records: 6314 Duplicates: 0 Warnings: 0
mysql select count(*) from t;
+----------+
| count(*) |
+----------+
| 6314 |
+----------+
1 row in set (0.00 sec)
mysql delete from t limit 100;
Query OK, 100 rows affected (0.01 sec)
mysql select count(*) from t;
+----------+
| count(*) |
+----------+
| 6214 |
+----------+
1 row in set (0.01 sec)

先恢复一个最近的全备,进行全量数据恢复

[root@localhost db_backup]# mysql -uroot -p mc_orderdb mc_orderdb.sql

然后查看mc_orderdb.sql文件中change master命令中

在进行这个全备时Mysql二进制日志的文件名(MASTER_LOG_FILE),以及时间点(MASTER_LOG_POS)

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

此处文件名为mysql-bin.000001,日志时间点为154;

下面我们要恢复这个时间点(154)之后到第一次删除数据之前的数据

要找到这个时间点(154)之后到第一次删除数据之前的数据

查看二进制日志,进行分析

[root@localhost db_backup]# cd /home/mysql
[root@localhost mysql]# mysqlbinlog --base64-output=decode-rows -vv --start-position=154 --database=mc_orderdb mysql-bin.000001| grep -B3 DELETE | more
#190110 13:44:54 server id 1 end_log_pos 83285 CRC32 0xf679d195 Table_map: `mc_orderdb`.`t` mapped to number 119
# at 83285
#190110 13:44:54 server id 1 end_log_pos 84620 CRC32 0xa3408e6c Delete_rows: table id 119 flags: STMT_END_F
### DELETE FROM `mc_orderdb`.`t`
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=1 /* INT meta=0 nullable=1 is_null=0 */
### @3=1042.34 /* DECIMAL(8,2) meta=2050 nullable=1 is_null=0 */
### DELETE FROM `mc_orderdb`.`t`
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2=3 /* INT meta=0 nullable=1 is_null=0 */
### @3=803.37 /* DECIMAL(8,2) meta=2050 nullable=1 is_null=0 */
...省略

从中可以看到刚刚的二进制日志中的第一个DELETE,在它之前的日志结束点为84620

所以我们需要恢复的是154 到84620 之间,且数据库为mc_orderdb ,日志所在文件名 为mysql-bin.000001的数据

我们通过mysqlbinlog 将这些数据导出来

[root@localhost mysql]# mysqlbinlog --start-position=154 --stop-position=84620 --database=mc_orderdb mysql-bin.000001 mc_order_diff.sql

将数据导入恢复

[root@localhost mysql]# mysql -uroot -p mc_orderdb mc_order_diff.sql
实时二进制日志备份

Mysql5.6版本之后,可以实时备份Binlog(二进制日志)

要使用这个功能,我们需要进行以下配置
首先新建一个用户,这个用户要有replication slave 权限

mysql grant replication slave on *.* to 'repl'@'localhost' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)

建立一个存储备份的二进制日志文件的目录

mkdir -p binlog_backup

最后在这个目录下,执行以下命令,就可以实时的进行二进制日志的备份了

[root@localhost binlog_bak]# mysqlbinlog --raw --read-from-remote-server --stop-never --host localhost --port 3306 -u repl -p123456 mysql-bin.000001
mysqlbinlog: [Warning] Using a password on the command line interface can be insecure.

raw:代表这个命令是输出的是raw格式的二进制日志
read-from-remote-server: 从mysql服务器上读取这个日志
stop-never:备份的这个进程会持续在后台运行
最后的是指定要备份的二进制文件的名称

此命令执行后这个终端会一直执行这个命令
现在打开另外一个终端,进入备份的目录进行查看

[root@localhost mysql]# cd /home/binlog_bak/
[root@localhost binlog_bak]# ls
mysql-bin.000001

可以看到日志已经备份成功
进入mysql命令行,刷新日志

mysql flush logs;
Query OK, 0 rows affected (0.01 sec)
mysql show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 3560467 |
| mysql-bin.000002 | 154 |
+------------------+-----------+
2 rows in set (0.00 sec)

现在有两个日志,我们再回到备份目录进行查看

[root@localhost binlog_bak]# ls
mysql-bin.000001 mysql-bin.000002

可以看到最新的日志也已实时备份

三. xtrabackup 1. xtrabackup介绍

xtrabackup 物理备份工具,用于在线备份innodb存储引擎的表

在所有表全是innodb存储引擎表的情况下:
xtrabackup 可以保证在备份过程中,不影响表的读写操作
在最初的时候,xtrabackup 本身只支持对innodb存储引擎表的备份,且只会备份数据文件,不会备份表的结构
innobackupex 是对xtrabackup 的插件,提供了备份表结构及其他配置信息的功能,并支持MyISAM表的备份,但也会锁表

因为在当前的mysql版本下,还有一些系统表使用的是MyISAM存储引擎,所以一般情况下使用的是innobackupex 脚本进行备份的

2. 安装xtrabackup 3. 利用innobackupex 进行全备
innobackupex --user=backup --password=123456 --parallel=2 /home/db_backup/
[root@localhost home]# innobackupex --user=backup --password=123456 --parallel=2 /home/db_backup/
xtrabackup: recognized server arguments: --datadir=/home/mysql --log_bin=mysql-bin --server-id=1 --parallel=2 
xtrabackup: recognized client arguments: --datadir=home/mysql --log_bin=mysql-bin --server-id=1 --parallel=2 
190110 15:15:30 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
 At the end of a successful backup run innobackupex
 prints "completed OK!".
... 省略
190110 15:15:37 [00] Writing /home/db_backup/2019-01-10_15-15-30/xtrabackup_info
190110 15:15:37 [00] ...done
xtrabackup: Transaction log of lsn (79088947) to (79088956) was copied.
190110 15:15:37 completed OK!

当看到completed OK!代表备份已完成

和mysqldump单线程备份不同,我们可以通过parallel参数指定备份的线程数
/home/db_backup/ 是我们指定的备份文件的存储目录

xtrabackup 会已当前时间在目标目录中生成一个子目录用来存放当前的备份文件

我们进入目录中查看一下

[root@localhost db_backup]# ls
20190110 2019-01-10_15-15-30 mc_orderdb.sql mc.sql order_master_1000_1050.sql order_master.sql
[root@localhost db_backup]# cd 2019-01-10_15-15-30/
[root@localhost 2019-01-10_15-15-30]# ls
backup-my.cnf ib_buffer_pool mc_orderdb mc_userdb performance_schema xtrabackup_binlog_info xtrabackup_info
bak_orderdb ibdata1 mc_productdb mysql sys xtrabackup_checkpoints xtrabackup_logfile

与原数据文件目录相比,少了ib_logfile0等日志文件

xtrabackup_binlog_info 比较重要,其中记录了备份的日志名和日志点,相当于mysqldump中设置master-data参数的作用

如果我们不想以时间戳的形式自动生成子目录,我们可以通过指定--no-timestamp参数来实现

innobackupex --user=backup --password=123456 --parallel=2 /home/db_backup/2019-01-10 --no-timestamp
[root@localhost db_backup]# innobackupex --user=backup --password=123456 --parallel=2 /home/db_backup/2019-01-10 --no-timestamp
[root@localhost db_backup]# ls
20190110 2019-01-10 2019-01-10_15-15-30 mc_orderdb.sql mc.sql order_master_1000_1050.sql order_master.sql
[root@localhost db_backup]# cd 2019-01-10
[root@localhost 2019-01-10]# ls
backup-my.cnf ib_buffer_pool mc_orderdb mc_userdb performance_schema xtrabackup_binlog_info xtrabackup_info
bak_orderdb ibdata1 mc_productdb mysql sys xtrabackup_checkpoints xtrabackup_logfile
[root@localhost 2019-01-10]# 
4. 利用innobackupex 进行全备的恢复
innobackupex --apply-log /path/to/BACKUP-DIR
mv /path/to/BACKUP-DIR /home/mysql/data

利用xtrabackup备份产生的备份集并不能直接用于数据库的恢复
进行数据库恢复之前,我们必须把备份中产生的备份集 进行应用,此处我们使用的是备份文件的目录伪2019-01-10

[root@localhost db_backup]# innobackupex --apply-log /home/db_backup/2019-01-10
[root@localhost db_backup]# cd 2019-01-10
[root@localhost 2019-01-10]# ls
backup-my.cnf ib_logfile0 mc_productdb sys xtrabackup_info
bak_orderdb ib_logfile1 mc_userdb xtrabackup_binlog_info xtrabackup_logfile
ib_buffer_pool ibtmp1 mysql xtrabackup_binlog_pos_innodb xtrabackup_master_key_id
ibdata1 mc_orderdb performance_schema xtrabackup_checkpoints

可以发现,使用了上面的命令后,备份集中多出了之前缺少的ib_logfile0等文件

使用xtrabackup进行数据库恢复时,我们必须对数据库实例进行重启
先停用mysql服务

然后将原数据库文件所在的文件夹重命名为data_bak,然后将此时的 2019-01-10文件夹移动到data_bak所在的文件夹,并重命名为data,即覆盖了原来的文件

然后 chown -R mysql:mysql data
对文件夹修改所属用户

最后重启mysql服务即可

5. 利用innobackupex 进行增量备份
innobackupex --user=backup --password=123456 /home/db_backup # 先进行全备
innobackupex --user=backup --password=123456 --incremental /home/db_backup/ --incremental-basedir=/home/db_backup/2019-01-10/

incremental :表示我们要进行的是一个全备, 指定全备的目录
incremental-basedir :指定增量备份所依赖的数据基础的备份目录,这个增量备份所依赖的上一个全备

先进行全备

innobackupex --user=backup --password=123456 /home/db_backup 

在 /home/db_backup 目录下生产了一个新的全备子目录 2019-01-10_16-19-37

再依赖上个全量备份进行增量备份

innobackupex --user=backup --password=123456 --incremental /home/db_backup/ --incremental-basedir=/home/db_backup/2019-01-10_16-19-37/

此时在 /home/db_backup 目录下生产了一个增量备分的子目录2019-01-10_16-22-09
增量备份会把自上一个全备后的数据变更记录下来

然后再进行一次增量备份,此时的命令和前面基本相同,只是所基于的增量备份的数据目录要变成上次增量备份生成的目录

innobackupex --user=backup --password=123456 --incremental /home/db_backup/ --incremental-basedir=/home/db_backup/2019-01-10_16-22-09/

此时,第二次增量备份的生成的目录名为2019-01-10_16-24-09

6. 利用innobackupex 进行增量恢复
innobackupex --apply-log --redo-only 全备目录

我们要循环的在多次增量备份中应用上面步骤

 innobackupex --apply-log --redo-only 全备目录 --incremental-dir=第一次增量目录

所有增量备份的都应有了上面的命令后,就可以像全备一样,在全备目录上再进行崩溃恢复的过程

 innobackupex --apply-log /path/to/BACKUP-DIR
 mv /path/to/BACKUP-DIR /home/mysql/data

最后和全备一样,要用全备目录替换mysql数据库目录

下面演示只恢复到第一次备份

[root@localhost db_backup]# innobackupex --apply-log --redo-only /home/db_backup/2019-01-10_16-19-37
[root@localhost db_backup]# innobackupex --apply-log --redo-only /home/db_backup/2019-01-10_16-19-37 --incremental-basedir=/home/db_backup/2019-01-10_16-22-09
[root@localhost db_backup]# innobackupex --apply-log /home/db_backup/2019-01-10_16-19-37 
[root@localhost db_backup]# mv 2019-01-10_16-19-37 /home/mysql
[root@localhost db_backup]# cd /home/mysql
[root@localhost mysql]# systemctl stop mysqld
[root@localhost mysql]# mv 2019-01-10_16-19-37 data
[root@localhost mysql]# chown -R mysql:mysql data
[root@localhost mysql]# systemctl start mysqld
四. 要制定备份计划

每天凌晨对数据库进行一次全备
实时对二进制日志进行远程备份

Linux公社的RSS地址:https://www.linuxidc.com/rssFeed.aspx

友情链接
  • Mozilla发布Firefox 67.0.4,修复沙箱逃逸漏洞
  • 蚂蚁金服正式成为CNCF云原生计算基金会黄金会员
  • Firefox 68将采用Microsoft BITS安装更新
  • OpenSSH增加对存储在RAM中的私钥的保护
  • 谷歌想实现自己的curl,为什么?
  • Raspberry Pi 4发布:更快的CPU、更大的内存
  • Firefox的UA将移除CPU架构信息
  • Ubuntu放弃支持32位应用程序实属乌龙,Steam会否重回Ubuntu怀抱
  • Qt 5.13稳定版发布:引入glTF 2.0、改进Wayland以及支持Lottie动
  • 红帽企业Linux 7现已内置Redis 5最新版
  • Slack进入微软内部禁用服务清单,GitHub也在其列?
  • 安全的全新编程语言V发布首个可用版本
  • Windows Terminal已上架,快尝鲜
  • 阿里巴巴微服务开源生态报告No.1
  • 面世两年,Google地球将支持所有基于Chromium的浏览器
  • 推进企业容器化持续创新,Rancher ECIC千人盛典完美收官
  • CentOS 8.0最新构建状态公布,或于数周后发布
  • Debian移植RISC
  • 微软拆分操作系统的计划初现雏形
  • Oracle发布基于VS Code的开发者工具,轻松使用Oracle数据库
  • Ubuntu 19.10停止支持32位的x86架构
  • 微软为Windows Terminal推出全新logo
  • 联想ThinkPad P系列笔记本预装Ubuntu系统
  • 微软发布适用于Win7/8的Microsoft Edge预览版
  • 启智平台发布联邦学习开源数据协作项目OpenI纵横
  • 经过六个多月的延迟,微软终于推出Hyper
  • ZFS On Linux 0.8.1 发布,Python可移植性工作
  • DragonFly BSD 5.6.0 发布,HAMMER2状态良好
  • Linux Kernel 5.2
  • CentOS 8.0 看起来还需要几周的时间
  • 百度网盘Linux版正式发布
  • PCIe 6.0宣布:带宽翻倍 狂飙至256GB/s
  • PHP 7.4 Alpha 发布,FFI扩展,预加载Opcache以获得更好的性能
  • Canonical将在未来的Ubuntu版本中放弃对32位架构的支持
  • Scala 2.13 发布,改进的编译器性能
  • 微软的GitHub收购了Pull Panda,并且使所有订阅完全免费
  • Windows Subsystem for Linux 2 (WSL 2)现在适用于Windows 10用
  • Debian 10 “Buster”的RISC
  • MariaDB宣布发布MariaDB Enterprise Server 10.4
  • DXVK 1.2.2 发布,带来微小的CPU开销优化
  • DragonFlyBSD 5.6 RC1 发布,VM优化,默认为HAMMER2
  • PrimeNG 8.0.0 发布,支持Angular 8,FocusTrap等
  • GIMP 2.10.12 发布,一些有用的改进
  • 清华大学Anaconda 镜像服务即将恢复
  • Debian GNU/Linux 10 “Buster” 操作系统将于2019年7月6日发布
  • 时时彩论坛
  • 五星体育斯诺克
  • 北单比分直播
  • 河北11选5走势图
  • 福建体彩36选7开奖结果
  • 九龙图库下载