mysql到底如何备份
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql到底如何备份相关的知识,希望对你有一定的参考价值。
数据备份是数据容灾的最后一道防线,即便有着两地三中心的架构,备份也依然重要。如果备份出问题,备份时影响了交易业务,备份数据无法恢复,这些也是企业难以承受的。所以选择合适的备份工具尤为重要。
每个企业级数据库都会有配套的备份工具,MEB(mysql Enterprise Backup)就是MySQL企业版中非常重要的工具之一,是为企业级客户提供的数据备份方案。
Xtrabackup一直作为MEB 开源版备胎而存在,从MySQL 8.0开始情况可能会变得有所不同。
在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下,MEB备份/恢复体验会更好,目前xtrabackup还不支持这些特性。
MySQL 企业版还有哪些功能?
特性1:Backup Lock
8.0之前使用xtrabackup或MEB做物理备份,为了保证备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁,再拷贝非InnoDB文件,这期间MySQL会变成只读,数据无法写入。表数量越多,可能加上时间越长,如果使用的xtrabackup 不小心没加rsync参数,逐个拷贝frm文件,锁定时间会更长,对业务影响较大。
我曾遇到过部署在虚拟机的实例有12000多张表,当时使用的xtrabackup,备份脚本中没加rsync参数,结果锁了十几分钟,而MEB就没有这样的问题。
MySQL 8.0支持轻量级备份锁 LOCK INSTANCE FOR BACKUP,数据字典也重构了由InnoDB存储。若不创建非InnoDB表,MEB默认使用备份锁获取binlog日志一致性位置,并阻止DDL操作,但不影响DML操作。
只有InnoDB表,仅上备份锁
若有非InnoDB表,上全局锁
特性2:Redo Log Archiving
MEB能做到在线热备,备份时不影响数据库读写,这是利用了InnoDB事务日志,在备份期间持续监视redo log的变化,读取增量变化,写入到ibbackup_logfile,也就不需要上锁来保障备份一致性。(对非InnoDB的文件需要上读锁拷贝)
如果备份期间数据库写入负载特别大,而写入ibbackup_logfile速度较慢,redo log size也不大,很可能会出现ibbackup_logfile的写入速度跟不上redo log记录生成速度,redo log 空间不够时需要覆写日志文件,那么来不及写入ibbackup_logfile的记录会丢失,导致备份失败。
MEB 4.1对此做了优化,将redo log处理线程拆分成多线程分工合作,提高处理redo log的效率,降低了redo log覆写造成备份失败的概率,但redo log新增速度和ibbackup_logfile写入速度悬殊太大,问题依然会发生。
MySQL 8.0.17支持了redo log archiving 彻底解决了此问题,备份前设置innodb_redo_log_archive_dirs,指定redo log归档目录。MEB备份时自动开启日志归档,当checkpoint时会将旧记录归档到此目录,后续从归档文件中读取redo日志记录,避免了覆写可能导致的redo记录丢失。
注意:innodb_redo_log_archive_dirs 不能在数据目录下,目录权限要求是700
特性3:Page Tracking
Page Tracking 是为优化增量备份效率,减少不必要的数据页扫描。
增量备份当前有3种扫描模式:
page-track:利用LSN精确跟踪上次备份之后被修改页面,仅复制这些页面,效率最快。
optimistic:扫描上次备份之后被修改的InnoDB 数据文件中,找出并拷贝修改的页面。依赖系统时间,使用存在限制。
full-scan:扫描所有InnoDB数据文件,找出并拷贝自上次备份之后修改的页面,效率最慢
1、利用page-track增量备份,需先安装备份组件
mysql> INSTALL COMPONENT "file://component_mysqlbackup";2、在全备前开启page-track
SELECT mysqlbackup_page_track_set(true);3、全备之后,做增量备份时指定若满足page tracking条件,默认会使用page-track模式,否则会使用full-scan模式,也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backupincremental-base有3种选择
last_backup:基于前一次备份做增备,前一次备份可能是增备,也可能是全备。这种方式全备之间可能会有多个增备,每次增量可能比较小,但恢复时需要逐个合并。
last_full_backup:基于前一次全备做增备。这种方式增备会越往后体积可能越大,但恢复时只需要合并最后一次增量备份。
dir:基于前一次的备份目录,前一次备份可能是增备,也可能是全备。
测试对比full-scan 和page-track ,在变更页小于总体50%的情况下 ,备份效率至少能有1倍的速度提升。
page-track 模式 磁盘读写均衡,说明读写的都是修改页面。
full-scan模式 磁盘读写差别很大,说明读了很多未修改的页面。
Mysql数据库备份的方法:
方法一:如果你使用的是虚拟主机,可以用使用phpmyadmin来备份数据库。
1、登陆phpmyadmin。登陆后左边会出现数据库列表,单击要备份的数据库。
2、在弹出的页面中,右侧上部单击“导出”按钮,一般保持默认选项,最下面“另存为文件”,选择“ZIP压缩”,最后单击执行按钮。
3、弹出保存文件后,保存文件即可。
方法二:如果你的数据库可以使用外部链接。可以使用SQLyogEnt来备份。
1、打开SQLyogEnt,并登陆mysql服务器,前面的文章已经讲过,如果还不明白的可以看这里《MySql管理利器SQLyogEnt初识(php建立数据库)》。
2、在左边数据库菜单选择要备份的书库,然后右击它。在弹出的菜单中,选择Backup Database as sql dump。
3、在弹出的对话框中,“export to file”即时备份数据库文件要保存的位置,其他保持默认选项,单击“Export”按钮,开始备份。
4、如果数据库是存放在和程序一台服务器的时候,及数据库地址为localhost的时候,备份mysql数据库一般采用第一种方法,如果你的mysql数据库可以外部登录,就可以使用第二种方式。如果你是独立服务器,可以直接复制数据库源文件即可,这里就不详细讲解了。
注意:
备份时要注意MYSQL数据库的版本和使用的字集,在还原的时候也要对应好,否则会出现乱码或者意想不到的后果。
参考技术B 常用备份工具是mysql自带的mysqldump,mysqldump -u root -p密码 dbname >d:\test.sql ------------备份某个库
mysqldump -u root -p密码 dbname tablename>d:\test.sql ------------备份某个库下的某个表
mysqldump -u root -p密码 --all-databases >d:\test.sql ------------备份全库
更多参数可通过 在 mysqldump --help查看本回答被提问者和网友采纳 参考技术C 备份的应该是数据库。。
MySQL备份详解
目录:
一、MySQL备份概述:
1.备份和冗余的区别:
- 备份:能够防止由于机械故障以及人为误操作带来的数据丢失,例如将数据库文件保存在了其他地方
- 冗余:数据有多份冗余,但不等于备份,只能防止机械故障带来的数据丢失,例如主备模式,数据库集群
2.备份什么:
- 数据库:一堆物理文件的集合;日志文件(二进制日志)+数据文件+配置文件
- ①.数据文件
- ②.配置文件=>my.cnf
③.日志文件(主要是二进制日志文件)
扩展:MySQL体系结构(MySQL=>DBMS软件到底是由哪些层构成的)
1).存储引擎层(myisam与innodb引擎):
- 存储引擎层:简单来说,就是数据的存储方式。在MySQL中,我们可以使用show engines 查看当前数据库版本支持哪些引擎,常见的数据存储引擎:innodb,myisam,ndb等等
- 常见面试题:请简述mysql的myisam引擎与innodb引擎的区别:
答:①.myisam引擎擅长数据的查询,支持全文索引
②.innodb引擎支持事务处理,行级锁,支持外键
2).存储层(数据文件与日志文件):
①.myisam引擎:
- 问题:存储引擎到底是如何保存数据文件的?(myisam引擎)
- 先创建一个全新的数据库
- 在创建一个数据表
- 查看mysql目录下的data目录
- *.frm:框架文件,定义数据表结构
- *.MYI:index索引,主要用于存放索引文件
- *.MYD:数据文件
②.innodb引擎:
- 这次我们用innodb引擎创建另一个数据表
- *.frm:框架文件,定义数据表结构
- *.ibd:索引文件+数据文件
- 其实innodb引擎不仅仅产生以上两个文件,其在外部data目录中也会产生一个文件(确切来说不能叫做产生文件,而应该叫做共享文件)
- 所以由此可见,innodb引擎的数据备份不能简简单单的通过拷贝方式实现,必须使用专业的备份工具
3).日志文件(MySQL中我们需要了解哪些日志)
日志类型 | 写入日志的信息 |
---|---|
error错误日志 | 存放数据库的启动,停止,或运行时的错误信息(找ERROR) |
binlog二进制日志 | 数据库的所有更改操作,不包含select或者show这类语句 |
①.error错误日志:
- error错误日志的命令规则与存放的目录:/data目录下+主机名称.err
- 更改错误日志的存放位置:
在这文件的最后一行加入log_error=目录/日志名称
②.binlog二进制日志:
- binlog二进制日志应用场景:
- 用于主从复制中,master主服务器将二进制日志中的更改操作发送给slave服务器,从服务器执行这些更改操作是和主服务器的更改相同
- 用于数据的恢复操作
- binlog二进制日志如何开启?
默认binlog日志是关闭的,可以通过修改配置文件完成开启:
然后将数据库重启一下(service mysql restart)
3.备份过程须考虑的因素:
- 必须制定详细的备份计划(策略)(备份频率,时间点,周期)
- 备份数据应该放在非数据库本地并建议有多份副本
- 必须做好数据恢复的演练(每隔一段时间,对备份的数据在测试环境中进行模拟恢复,保证当出现数据灾难的时候能够及时恢复数据)
- 根据数据应用的场合,特点选择正确的备份工具
- 数据的一致性
- 服务的可用性
4.备份类型:
1).逻辑备份:
- 备份的是建表,建库,插入等操作所执行的SQL语句(DDL,DML,DCL)
- 适用于中小型数据库,效率相对较低。一般在数据库正常提供服务的前提下进行,如mysqldump,mydumper,into outfile(表的导出导入)等
- 备份实质:就是把要备份的数据导出成 .sql或 .txt文件
2).物理备份:
- 直接复制数据库文件
- 适用于大型数据库环境,不受存储引擎的限制,但不能恢复到不同的MySQL版本
- 一般是在数据库彻底关闭或者不能完成正常提供服务的前提下进行的备份,如:tar,cp,xtrabackup(数据库可以正常提供服务),lvm snapshot,rsync等等
- 备份的实质:对数据文件+配置文件+日志文件进行拷贝操作
3).在线热备(数据冗余,AB复制,主从复制)
- MySQL的replication架构,如M-S | M-S-S | M-M-S等等
- 实时在线备份
5.备份工具:
1).社区版安装包中的备份工具:
2).企业版安装包中的备份工具:
3).第三方备份工具:
6.备份方法:
- 完全备份(全备)
- 增量备份(增量备份基于全量备份)
二、MySQL逻辑备份:
1.mysqldump基本备份:
- mysqldump基本备份:
- 本质:导出的是sql语句;
- 优点:无论是什么存储引擎,都可以用mysqldump备成sql语句;
- 缺点:速度较慢,导入时可能会出现格式不兼容的突发状况,无法直接做增量备份;
- 提供三种级别的备份,表级,库级和全库级
- mysqldump基本语法:
1).mysqldump表级备份与还原:
- 案例:把db_lin数据库中的tb_student数据表进行备份!(备份到/tmp/sql.bak)
- 案例:还原数据表,先在数据库中删除原先表!
然后数据表就回来了
第二种还原方式:
在进入mysql中,用source+.sql文件位置来进行还原
就可以了
2).mysqldump库级备份与还原:
- 案例:把db_lin数据库进行备份!
- 案例:还原db_lin数据库!
第二种还原方式:
3).mysqldump全库级备份:
- 在MySQL中,如果想使用mysqldump进行全库级备份,必须开启二进制日志!!
- mysqldump高级选项说明:
- –master-data参数其他说明:
1.恢复时会执行,默认是1
2.需要RELOAD privilege必须打开二进制文件
3.这个选项会自动打开–lock-all-tables,关闭–lock-tables
4).mysqldump总结:
2.逻辑导入导出(了解):
- 无论是什么存储引擎,以下方式本身是一种数据导出的方法,同时可以用来辅助备份,它可以对一个表的其中一列或者某几列做备份。备份的是数据记录
1).导出(数据备份):
- 案例:把tb_student数据表中的数据记录进行逻辑导出
- 出现以上问题的主要原因在于我们没有指定MySQL逻辑导出时指定的路径
- 解决方法:
这样子就成功导出数据了
2).导入(数据还原):
- 使用方法2的时候,要求导出的文件必须和数据表名称完全一致!!!
3).数据导入案例(导入规则的文本文件):
- 案例:把/etc/passwd文件中的数据导入到passwd数据表中
- 第一步:创建一个passwd数据表
- 第二步:把/etc/passwd拷贝到/tmp取名为passwd.txt
- 第三步:导入数据
- 选项说明:
- fields-terminated-by:指定导出文件的分隔符为冒号
- liness-terminated-by:指定每一行的结尾使用的符号,\\n代表换行符
三、mysqldump+binlog实现增量备份:
1.什么是增量备份:
- 要有全量备份
- 继续增删改数据
- 再次需要备份的时候,不需要进行全量备份,只需要备份binlog日志文件即可(因为binlog日志记录了增删改操作的所有SQL语句)
2.增量备份实验步骤:
- 第一步:准备数据(前提)
- 第二步:开启二进制,然后做全量备份(全库备份)
- 第三步:继续对数据库进行增删改操作
- 第四步:假设发生了硬件故障导致数据丢失
- 第五步:恢复全量备份导出的数据(不完整,90%左右)
- 第六步:备份二进制日志,根据其信息(导入剩余的部分数据)
3.增量备份实践:
- 进行全库备份后,咱们再继续进行增删改操作!
我在这里插入了一条信息和删除了一条信息- 模拟突然间发生故障,数据库丢失了!
- 开始进行数据恢复,马上把最新的二进制文件进行备份
- 得确保这个二进制文件有内容
- 先进行全库的备份!
- 这个时候数据库是恢复了,但是我还增加了一条记录,和删除了一条记录,但是这两条记录就没有显示出来了
- 通过binlog增量备份还原数据到100%(在此之间,必须学会怎么读二进制文件)
- mysqlbinlog --start-position=4 --stop-position=636 /tmp/sql.bak/binlog.000002 | mysql -uroot -p
1).读二进制日志文件:
- 必须通过专业工具
- mysqlbinlog /tmp/sql.bak/binlog.000002 ==> 重点找事故的临界点!!,确认at的位置
四、MySQL的物理备份:
1.xtrabackup备份介绍:
1).xtrabackup优缺点:
- 优点:
1.备份过程快速,可靠(因为是物理备份)
2.支持增量备份,更为灵活
3.备份过程不会打断正在执行的事务
4.能够基于压缩等功能节约磁盘空间和流量
5.自动实现备份检验
6.还原速度快
- 缺点:
1.只能对innodb表进行增量备份,myisam表增量备份时是全备
2.innobackupex备份myisam表之前要对全库进行加READ LOCK,阻塞写操作,若备份是在库上进行的话会影响主从同步,造成延迟。对innodb表备份不会阻塞读写
2).xtrabackup备份原理:
- innobackupex首先会启动一个xtrabackup_log后台检测的进程,实时检测mysql的redo log的变化,一旦发现redo有新的日志写入,立刻将日志写入到日志文件xtrabackip_log中
- 物理拷贝innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方
- 复制结束后,执行flush table with read lock操作进行全库锁表准备备份非innodb文件
- 物理复制 .frm, .myd, .myi 等等非innodb引擎文件到备份目录
- 查看二进制日志的位置
- 解锁表unlock tables
- 停止xtrabackup_log进程
3).xtrabackup软件的安装:
- 第一步:上传软件包及依赖库到linux服务器端
- 第二步:安装依赖库
rpm -ivh libev-4.15-3.el7.x86_64.rpm- 第三步:安装xtrabackup软件
yum install percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm -y
4).xtrabackup全库备份与恢复:
- 备份核心思路:
- 使用innobackupex对数据库中的所有库进行全量备份,备份完成后,其不能立刻进行数据恢复(因为数据不完整)
- 预备阶段,备份过程中产生xtrabackup_log应用到全量备份集
- 模拟故障(删除数据)
- 进行全库恢复
- 测试验证
第一步:准备数据(准备一个innodb引擎的和一个myisam引擎的)
第二步:专门准备一个数据库备份的账号,开通相应的权限
第三步:使用innobackupex工具进行全库备份:
- 第一次运行报错:出现以上问题的主要原因在于我们的mysql.sock并不在/var/lib/mysql/mysql.sock这儿。为什么其会自动连接/var/lib/mysql目录下的mysql.sock呢?
答:原因1:可能在/etc目录下还有my.cnf文件,影响了innobackupex的执行。
答:原因2:innobackupex拥有自己的默认配置,默认读取了/var/lib/mysql/mysql.sock文件- 解决方案:
方案1:把你的套接字文件创建一个软链接,放置于/var/lib/mysql/mysql.sock这个文件中
方案2:在innobackupex中添加一个-S的选项指定套接字
不管之前那条命令执行成功与否,都会生成文件,咱们先删除
命令执行成功后,在这个目录下就会有这么些文件了第四步:预备阶段,把备份这段时间内产生的日志整合到全量备份中
第五步:模拟数据库故障
rm -rf /mysql_3306/data/*
pkill mysqld
再删除一次
这下子就啥也没了
第六步:快速的恢复数据库中的数据
rm -rf /mysql_3306/data/* 先清空,以确保没有其他因素的影响
- 第一次恢复报错:出现以上问题的主要原因在于,innobackupex工具无法找到MySQL中的数据目录
- 解决方案:把my.cnf配置文件传递给innobackupex,让其自动识别这个文件中的datadir
数据就回来了!!!!但是权限不对
第七步:恢复数据时,一定要记得更改文件拥有者以及所属组权限,否则mysql无法启动
第八步:启动MySQL,测试其是否正常
经过测试,一切正常!
5).xtrabackup增量备份与恢复:
- 第一步:准备数据
- 第二步:创建一个账号,专门用于备份
- 第三步:全量备份
innobackupex --user=admin --password=123456 /full_xtrabackup/- 第四步:把全备过程中产生的日志进行整合
- 选项说明:
–apply-log:表示整合日志
–redo-only:表示只应用已经提交的事务,不回滚未提交的事务
注意:如果已经回滚了未提交的事务,那么就无法再应用增量备份(在某一时间段,产生了很多事务操作,事务处理==>开启事务,成功提交了事务,写入硬盘;失败了回滚事务,不写入硬盘)- 第五步:修改数据,使其产生增量数据
- 第六步:做增量备份
- 选项说明:
–incremental:增量备份目录
–incremental-basedir:这个增量是相对于哪个全量的- 第七步:把增量备份产生的数据以及日志文件整合到全量备份中
顺序不能颠倒!!- 第八步:模拟数据库故障
- 第九步:数据恢复
- 第十步:更改权限
- 第十一步:测试验证
这是刚刚添加的两条记录,都备份进来了
以上是关于mysql到底如何备份的主要内容,如果未能解决你的问题,请参考以下文章