mysql-凯发k8官方网

备份类型

1 热备

在业务正常时,对数据库进行备份数据,并且能够一致性恢复（只能是innodb）

对业务影响非常小
2 温备

锁表备份,只能查询不能修改（myisam）

影响到写入操作
3 冷备

关闭数据库业务,数据库没有任何变更的情况下,进行备份数据.

业务停止

常用备份工具

1 逻辑备份工具

基于sql语句进行备份

mysqldump       *****

mysqlbinlog     *****
2 物理备份工具

基于磁盘数据文件备份

xtrabackup(xbk)：percona 第三方   *****

mysql enterprise backup（meb）

逻辑备份和物理备份的比较

1 mysqldump (mdp)

优点：

1.不需要下载安装

2.备份出来的是sql，文本格式，可读性高，便于备份处理

3.压缩比较高，节省备份的磁盘空间

缺点：

依赖于数据库引擎，需要从磁盘把数据读出，然后转换成sql进行转储，比较耗费资源，数据量大的话效率较低

建议：

100g以内的数据量级，可以使用mysqldump

超过1tb以上，我们也可选择的是mysqldump，配合分布式的系统

1eb = 1024pb = 1000000tb
2 xtrabackup(xbk)

优点：

1.类似于直接cp数据文件，不需要管逻辑结构，相对来说性能较高

缺点：

可读性差

压缩比低，需要更多磁盘空间

建议：

数据库容量 大于100g，小于1tb时，使用xbk备份方式

备份策略

备份方式：

全备:全库备份，备份所有数据

增量:备份变化的数据
逻辑备份=mysqldump mysqlbinlog

物理备份=xtrabackup_full xtrabackup_incr binlog或者xtrabackup_full binlog
备份周期:

根据数据量设计备份周期

比如：周日全备，周1-周6增量

mysqldump备份工具

mysqldump (逻辑备份的客户端工具)

客户端通用参数

-u  -p   -s   -h  -p

本地备份:

mysqldump -uroot -p  -s /tmp/mysql.sock
远程备份:

mysqldump -uroot -p  -h 10.0.0.51 -p3306

备份专用基本参数

-a 全备参数

[root@db01 ~]# mkdir -p /data/backup

[root@db01 ~]# mysqldump -uroot -p -a >/data/backup/full.sql

# 补充:建议不用加--set-gtid-purged=off

# 1.常规备份是要加 --set-gtid-purged=off,解决备份时的警告

# [root@db01 ~]# mysqldump -uroot -p123 -a  --set-gtid-purged=off  >/backup/full.sql

# 2.构建主从时,做的备份,不需要加这个参数

# [root@db01 ~]# mysqldump -uroot -p123 -a >/backup/full.sql
-b db1 db2 db3 备份多个单库

说明：生产中需要备份，生产相关的库和mysql库

[root@db01 ~]# mysqldump -uroot -p  -b mysql gtid >/data/backup/full.sql
备份单个或多个表

world数据库下的city,country表

[root@db01 ~]# mysqldump -uroot -p world city country >/backup/bak1.sql
以上备份恢复时:必须库事先存在,并且ues才能source恢复

高级参数应用*****

##特殊参数使用1（必须要加）

-r            备份存储过程及函数

--triggers  	备份触发器

-e            备份事件

[root@db01 backup]# mysqldump -uroot -p -a -r -e --triggers >/data/backup/full.sql
##特殊参数使用2

-f 在备份开始时,刷新一个新binlog日志

[root@db01 backup]# mysqldump -uroot -p  -a  -r --triggers -f >/bak/full.sql
##特殊参数使用3

--master-data=2 ***** 这个参数很重要，必须要加

以注释的形式,保存备份开始时间点的binlog的状态信息

[root@db01 ~]# mysqldump -uroot -p  -a  -r --triggers --master-data=2 >/back/world.sql

[root@db01 ~]# grep 'change' /backup/world.sql

-- change master to master_log_file='mysql-bin.000035', master_log_pos=194;

功能：

（1）在备份时，会自动记录，二进制日志文件名和位置号

     0  默认值

     1  以change master to命令形式，可以用作主从复制

     2  以注释的形式记录，备份时刻的文件名 postion号

（2）自动锁表

（3）如果配合 --single-transaction，只对非innodb表进行锁表备份，innodb表进行热备，实际上是实现快照备份
--single-transaction  这个参数配合上个参数一起使用

innodb存储引擎开启热备(快照备份)功能

master-data可以自动加锁

（1）在不加--single-transaction，启动所有表的温备份，所有表都锁定

（1）加上--single-transaction，对innodb进行快照备份，对非innodb表可以实现自动锁表功能
备份必加参数

mysqldump -uroot -p -a -r -e --triggers --master-data=2  --single-transaction --set-gtid-purged=off >/data/backup/full.sql
##特殊参数使用4

--set-gtid-purged=auto   默认就行，一般不用加这个参数，了解一下

参数: auto, on, off

使用场景:

1. --set-gtid-purged=off,可以使用在日常备份参数中.

mysqldump -uroot -p -a -r -e --triggers --master-data=2  --single-transaction --set-gtid-purged=off >/data/backup/full.sql
2. auto, on:在构建主从复制环境时需要的参数配置

mysqldump -uroot -p -a -r -e --triggers --master-data=2  --single-transaction --set-gtid-purged=on >/data/backup/full.sql

备份小练习

实现所有表的单独备份

提示：

information_schema.tables

mysqldump -uroot -p123 world city >/backup/world_city.sql
####

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 --single-transaction --set-gtid-purged=0  -r -e --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

压缩备份并添加时间戳

[root@db01 backup]# mysqldump -uroot -p123 -a  -r  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date  %f).sql.gz

[root@db01 backup]# mysqldump -uroot -p123 -a  -r  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date  %f-%t).sql.gz
mysqldump备份的恢复方式（在生产中恢复要谨慎，恢复会删除重复的表）

set sql_log_bin=0;

source /backup/full_2018-06-28.sql

set sql_log_bin=1;

注意：

1、mysqldump在备份和恢复时都需要mysql实例启动为前提。

2、一般数据量级100g以内，大约15-45分钟可以恢复，数据量级很大很大的时候（pb、eb）

3、mysqldump是覆盖形式恢复的方法。
一般我们认为，在同数据量级，物理备份要比逻辑备份速度快.

逻辑备份的优势:

1、可读性强

2、压缩比很高

备份时优化参数

(1) max_allowed_packet   最大的数据包大小

mysqldump -uroot -p123 -a  -r  --triggers --set-gtid-purged=off --master-data=2 max_allowed_packet=128m  --single-transaction|gzip > /backup/full_$(date  %f).sql.gz

(2) 增加key_buffer_size  (临时表有关)

(3) 分库分表并发备份

(4) 架构分离,分别备份      (架构拆分,分布式备份)

从mysqldump 全备中获取库和表的备份

1、获得表结构

# sed -e'/./{h;$!d;}' -e 'x;/create table `city`/!d;q'  full.sql>createtable.sql
2、获得insert into语句，用于数据的恢复

# grep -i 'insert into `city`'  full.sqll >data.sql &
3.获取单库的备份

# sed -n '/^-- current database: `world`/,/^-- current database: `/p' all.sql >world.sql

企业故障恢复案例1（可以多参考案例2）

1 背景环境

正在运行的网站系统，mysql-5.7.20数据库，数据量50g，日业务增量1-5m
2 备份策略

每天23:00点，计划任务调用mysqldump执行全备脚本
3 故障时间点

年底故障演练:模拟周三上午10点误删除数据库，并进行恢复
4 思路

  4.1、停业务，挂维护页，避免数据的二次伤害

  4.2、找一个临时库，恢复周二23：00全备

  4.3、截取周二23：00 --- 周三10点误删除之间的binlog，恢复到临时库

  4.4、测试可用性和完整性

  4.5、

    4.5.1 方法一：直接使用临时库顶替原生产库，前端应用割接到新库

    4.5.2 方法二：将误删除的表导出，导入到原生产库

  4.6、开启业务

  处理结果：经过20分钟的处理，最终业务恢复正常
5 故障模拟演练

5.1 准备数据

create database backup;

use backup

create table t1 (id int);

insert into t1 values(1),(2),(3);

commit;
5.2 周二 23：00全备

mysqldump -uroot -p123 -a  -r  --triggers --set-gtid-purged=off --master-data=2  --single-transaction|gzip > /backup/full_$(date  %f).sql.gz
5.3 模拟周二 23：00到周三 10点之间数据变化

use backup

insert into t1 values(11),(22),(33);

commit;

create table t2 (id int);

insert into t2 values(11),(22),(33);
5.4 模拟故障,删除表(只是模拟，不代表生产操作)

drop database backup;
6 恢复过程

6.1 准备临时数据库（多实例3307）

systemctl start mysqld3307
6.2 准备备份

（1）准备全备

    cd /backup

    gunzip full_2018-10-17.sql.gz

（2）截取二进制日志

     -- change master to master_log_file='mysql-bin.000036', master_log_pos=793;

     #mysqlbinlog --skip-gtids --include-gtids='3ca79ab5-3e4d-11e9-a709-000c293b577e:6-7' /data/binlog/mysql-bin.000036 >/backup/bin.sql
6.3 恢复备份到临时库

mysql -s /data/3307/mysql.sock

set sql_log_bin=0;

source /backup/full_2018-10-17.sql

source /backup/bin.sql
6.4 将故障表导出并恢复到生产

mysqldump   -s /data/3307/mysql.sock backup t1 >/backup/t1.sql

#mysql -uroot -p123

>set sql_log_bin=0

>use backup

>source /backup/t1.sql;

企业故障恢复案例2

数据准备

利用mysqldump进行全备 binlog

创建数据库

mysql> create database backup charset utf8mb4;

创建一张表

mysql> use backup;

mysql> create table t1 (id char(255));

写一个shell脚本模拟业务一直在往表中插入数据

#!/bin/baship="10.0.0.51"user="root"pwd="root123"dbname="backup"while true; do    sleep 1    insert_sql="insert into t1 values(`date  %s`)"    mysql -h${ip} -u${user} -p${pwd} ${dbname} -e "${insert_sql};commit"    echo ${insert_sql}done

执行shell脚本，开始往数据库插入数据

模拟在某个时间点对数据库进行了全备

[root@db01 backup]# mysqldump -uroot -proot123 -a -r -e -f --triggers --master-data=2 --single-transaction >./full.sql参数解释：-a						    对整个数据库实例全备，里面有多少库备份多少库-r						    备份存储过程和函数-e						    备份事件--triggers			  备份触发器--master-data=2		记录备份时刻的binlog信息，自动锁表。不加--single-transaction ,温备份。加了--single-transaction对于innodb表不锁表备份(快照备份)--single-transaction  对于innodb的表,进行一致性快照备份,不锁表.-f						    在备份开始时,刷新一个新binlog日志

模拟故障

全备完成以后，等几分钟，这时候又插入了新的数据。模拟数据库出现故障，这里直接drop t1表mysql> drop table t1;

恢复

此时看到一直插入数据的脚本报错了，代表业务出错了

这里的数值是1576220628。待会恢复数据后最后一条数据要是这个1576220628，另外由于是快照备份，不锁表。所以应该是每秒插入1条数据

找到最近的全备，这里是在 /backup/full.sql

[root@db01 backup]# ll

total 51088

-rw-r--r-- 1 root root 52313239 dec 13 15:02 full.sql

[root@db01 backup]# pwd

/backup

把全备恢复到 测试库中 。注意不要直接恢复到生产库

mysql> show databases;

 -------------------- 

| database           |

 -------------------- 

| information_schema |

| mysql              |

| performance_schema |

| sys                |

 -------------------- 

4 rows in set (0.04 sec)

# 恢复全备

mysql> set sql_log_bin=0;			# 临时关闭二进制日志记录，避免恢复的时候，记录了大量的二进制日志

mysql> source /backup/full.sql;

mysql> set sql_log_bin=1;

查看全备full.sql中正在使用的binlog文件是哪个，以及pos开始号（这里直接用pos号恢复了，没用gtid）

-- change master to master_log_file
# pos开始号

[root@db01 backup]# head -30 full.sql |grep "change master to master_log_file"

-- change master to master_log_file='mysql-bin.000014', master_log_pos=194;
# pos结束号 直接查看drop前10行

[root@db01 backup]# mysqlbinlog /data/mysql/binlog/mysql-bin.000014 |grep -b10 "drop"

# at 29266

#191213 15:03:48 server id 6  end_log_pos 29297 crc32 0x4d4926e4 	xid = 6272

commit/*!*/;

# at 29297

#191213 15:03:48 server id 6  end_log_pos 29362 crc32 0x25b456a0 	gtid	last_committed=109	sequence_number=110	rbr_only=no

set @@session.gtid_next= 'a4b648cb-11b8-11ea-8636-000c2990cef0:1196'/*!*/;

# at 29362

#191213 15:03:48 server id 6  end_log_pos 29481 crc32 0x910720d6 	query	thread_id=20	exec_time=1	error_code=0

use `backup`/*!*/;

set timestamp=1576220628/*!*/;

drop table `t1` /* generated by server */

截取二进制日志。如果二进制文件过大也可以直接用grep过滤

[root@db01 backup]# mysqlbinlog --skip-gtids --start-position=194 --stop-position=29297 /data/mysql/binlog/mysql-bin.000014 >./binlog.sql

恢复二进制日志的数据

mysql> use backup;

mysql> set sql_log_bin=0;

mysql> source /backup/binlog.sql;

mysql> set sql_log_bin=1;

验证数据 这里最后一条数据是1576220628。刚好和业务中断之前的对上，数据完美恢复

mysql> select * from t1 order by id desc limit 2;

 ------------ 

| id         |

 ------------ 

| 1576220628 |

| 1576220627 |

 ------------ 

10 rows in set (0.00 sec)

导出该表

[root@db01 backup]# mysqldump -s /data/3308/mysql.sock  -r -e -f --triggers --master-data=2 --single-transaction backup t1 >./t1.sql

在生产中恢复该表

mysql> use backup;

mysql> source /backup/t1.sql;

mysql> select * from t1 order by id desc limit 5;

xtrabackup备份工具(xbk、xbackup)

安装

1 安装依赖包：

wget -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

yum -y install perl perl-devel libaio libaio-devel perl-time-hires perl-dbd-mysql libev
2 下载软件并安装

wget https://www.percona.com/downloads/xtrabackup/percona-xtrabackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm

https://www.percona.com/downloads/xtrabackup/percona-xtrabackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

常用备份命令

xtrabackup

innobackupex    ******

备份方式（物理备份）

（1）对于非innodb表（比如 myisam）是，锁表cp数据文件，属于一种温备份。

（2）对于innodb的表（支持事务的），不锁表，拷贝数据页，最终以数据文件的方式保存下来，把一部分redo和undo一并备走，属于热备方式。
题：xbk 在innodb表备份恢复的流程

  0、xbk备份执行的瞬间,立即触发checkpoint,已提交的数据脏页,从内存刷写到磁盘,并记录此时的lsn号

  1、备份时，拷贝磁盘数据页，并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint lsn之后的日志

  2、在恢复之前，模拟innodb“自动故障恢复”的过程，将redo（前滚）与undo（回滚）进行应用

  3、恢复过程是cp 备份到原来数据目录下

innobackupex使用

全备

[root@db01 backup]# innobackupex --user=root --password=123  /data/backup
自主定制备份路径名

[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/backup/full
备份集中多出来的文件：

-rw-r----- 1 root root       24 jun 29 09:59 xtrabackup_binlog_info

-rw-r----- 1 root root      119 jun 29 09:59 xtrabackup_checkpoints

-rw-r----- 1 root root      489 jun 29 09:59 xtrabackup_info

-rw-r----- 1 root root     2560 jun 29 09:59 xtrabackup_logfile
xtrabackup_binlog_info ：（备份时刻的binlog位置）

[root@db01 full]# cat xtrabackup_binlog_info

mysql-bin.000003    536749

79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7

记录的是备份时刻，binlog的文件名字和当时的结束的position，可以用来作为截取binlog时的起点。
xtrabackup_checkpoints ：

backup_type = full-backuped

from_lsn = 0            上次所到达的lsn号(对于全备就是从0开始,对于增量有别的显示方法)

to_lsn = 160683027      备份开始时间(ckpt)点数据页的lsn

last_lsn = 160683036    备份结束后，redo日志最终的lsn。注意最终的last_lsn号要比to_lsn大9

compact = 0

recover_binlog_info = 0

（1）备份时刻，立即将已经commit过的，内存中的数据页刷新到磁盘(ckpt).开始备份数据，数据文件的lsn会停留在to_lsn位置。

（2）备份时刻有可能会有其他的数据写入，已备走的数据文件就不会再发生变化了。

（3）在备份过程中，备份软件会一直监控着redo的undo，如果一旦有变化会将日志也一并备走，并记录lsn到last_lsn。

从to_lsn  ----》last_lsn 就是，备份过程中产生的数据变化

全备的恢复

准备备份（prepared）

将redo进行重做，已提交的写到数据文件，未提交的使用undo回滚掉。模拟了csr的过程

[root@db01 ~]# innobackupex --apply-log  /backup/full
恢复备份

前提：

1、被恢复的目录是空

2、被恢复的数据库的实例是关闭

systemctl stop mysqld
创建新目录

[root@db01 backup]# mkdir /data/mysql1
数据授权

chown -r mysql.mysql /data/mysql1
恢复备份

[root@db01 full]# cp -a /backup/full/* /data/mysql1/
启动数据库

vim /etc/my.cnf

datadir=/data/mysql1

[root@db01 mysql1]# chown -r mysql.mysql /data/mysql1

systemctl start mysqld

innobackupex 增量备份(incremental)

（1）增量备份的方式，是基于上一次备份进行增量。

（2）增量备份无法单独恢复。必须基于全备进行恢复。

（3）所有增量必须要按顺序合并到全备中。
增量备份命令

（1）删掉原来备份

略.

（2）全备（周日）

[root@db01 backup]# innobackupex --user=root --password --no-timestamp /backup/full >&/tmp/xbk_full.log

（3）模拟周一数据变化

db01 [(none)]>create database cs charset utf8;

db01 [(none)]>use cs

db01 [cs]>create table t1 (id int);

db01 [cs]>insert into t1 values(1),(2),(3);

db01 [cs]>commit;

（4）第一次增量备份（周一）

[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/full  /backup/inc1 &>/tmp/inc1.log

（5）模拟周二数据

db01 [cs]>create table t2 (id int);

db01 [cs]>insert into t2 values(1),(2),(3);

db01 [cs]>commit;

（6）周二增量

 [root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/inc1  /backup/inc2  &>/tmp/inc2.log

（7）模拟周三数据变化

db01 [cs]>create table t3 (id int);

db01 [cs]>insert into t3 values(1),(2),(3);

db01 [cs]>commit;

db01 [cs]>drop database cs;
恢复到周三误drop之前的数据状态

恢复思路：

1.  挂出维护页，停止当天的自动备份脚本

2.  检查备份：周日full 周一inc1 周二inc2，周三的完整二进制日志

3. 进行备份整理（细节），截取关键的二进制日志（从备份——误删除之前）

4. 测试库进行备份恢复及日志恢复

5. 应用进行测试无误，开启业务

6. 此次工作的总结
恢复过程

1. 检查备份

1afe8136-601d-11e9-9022-000c2928f5dd:7-9

2. 备份整理（apply-log） 合并备份（full inc1 inc2）

(1) 全备的整理

注意这里是要 --redo-only 参数的。需要模拟innodb引擎数据自动恢复

[root@db01 one]# innobackupex --apply-log --redo-only /data/backup/full

(2) 合并inc1到full中

[root@db01 one]# innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full

(3) 合并inc2到full中

[root@db01 one]# innobackupex --apply-log  --incremental-dir=/data/backup/inc2 /data/backup/full

(4) 最后一次整理全备 这里不需要 --redo-only 参数

[root@db01 backup]#  innobackupex --apply-log  /data/backup/full

3. 截取周二 23:00 到drop 之前的 binlog

[root@db01 inc2]# mysqlbinlog --skip-gtids --include-gtids='1afe8136-601d-11e9-9022-000c2928f5dd:7-9' /data/binlog/mysql-bin.000009 >/data/backup/binlog.sql

4. 进行恢复

[root@db01 backup]# mkdir /data/mysql/data2 -p

[root@db01 full]# cp -a * /data/mysql/data2

[root@db01 backup]# chown -r mysql.  /data/*

[root@db01 backup]# systemctl stop mysqld

vim /etc/my.cnf

datadir=/data/mysql/data2

systemctl start mysqld

master [(none)]>set sql_log_bin=0;

master [(none)]>source /data/backup/binlog.sql

master [(none)]>set sql_log_bin=1;

备份集中单独恢复表

思考:在之前的项目案例中,如果误删除的表只有10m,而备份有500g,该如何快速恢复误删除表?

拷贝表相关的文件，然后cp到生产环境

提示：

drop table city;

create table city like city_bak;

alter table city discard tablespace;

cp /backup/full/world/city.ibd  /application/mysql/data/world/

chown -r mysql.mysql  /application/mysql/data/world/city.ibd

alter table city import  tablespace;

mysql升级迁移

迁移(5.6.44  --->  5.7.26)

1 搭建5.6的测试环境

(1)创建必须的目录

[root@oldboyedu ~]# mkdir /data/mysql/data  -p

[root@oldboyedu ~]# mkdir /application/ -p

[root@oldboyedu ~]# mkdir /data/binlog -p

上传软件至 /application 下并解压

(2) 建用户,改权限

[root@oldboyedu ~]# useradd mysql

[root@oldboyedu ~]# chown -r mysql. /data/application/

(3) 修改环境变量

vim /etc/profile

export path=/application/mysql/bin:$path

source /etc/profile

(4)数据初始化

[root@oldboyedu ~]# yum remove mariadb-libs

[root@oldboyedu ~]# yum install -y libaio-devel

[root@oldboyedu ~]# \rm -rf /data/mysql/data/*

[root@oldboyedu ~]# /application/mysql/scripts/mysql_install_db --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data

(5) 准备配置文件和启动脚本

cat > /etc/my.cnf <
[mysqld]

basedir=/application/mysql

datadir=/data/mysql/data

server_id=99

user=mysql

log_bin=/data/binlog/mysql-bin

binlog_format=row

socket=/tmp/mysql.sock

[mysql]

socket=/tmp/mysql.sock

eof

[root@oldboyedu data]# cp  /application/mysql/support-files/mysql.server /etc/init.d/mysqld

(6) 启动数据库

[root@oldboyedu data]# /etc/init.d/mysqld start

[root@oldboyedu data]# mysqladmin -uroot -p password 123
2 迁移5.6 数据到 5.7  (扩展)

(1) 5.6 数据库备份

[root@oldboyedu ~]# mysqldump -uroot -p123 -a --master-data=2 --single-transaction -r -e --triggers >/tmp/full.sql

[root@oldboyedu ~]# scp /tmp/full.sql 10.0.0.51:/data/3308

(2)准备5.7数据库

[root@db01 /]# systemctl start mysqld3308

[root@db01 /]# mysql -s /data/3308/mysql.sock

mysql> source /data/3308/full.sql

[root@db01 /]# mysql_upgrade  -uroot -p123 -s /data/3308/mysql.sock

(3) binlog的持续追加

(4) 停业务,恢复剩余的binlog

(5) 业务割接

总结

以上是凯发k8官方网为你收集整理的mysql-14-备份恢复的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得凯发k8官方网网站内容还不错，欢迎将凯发k8官方网推荐给好友。