当前位置:   article > 正文

Mysql数据库备份与恢复_mysql备份时 影响使用吗

mysql备份时 影响使用吗

  在mysql备份当中,我们一般有两种备份方法,一种叫逻辑备份,另一种是物理备份。
  mysql提供了四种备份工具。逻辑备份工具有mysqldump、mysqlpump、mydumper,其中mysqldump是单线程备份工具,备份速度慢。Mysqlpump、Mydumper是多线程备份工具。物理备份工具为xtrabackup。

(1)逻辑备份

  从库是通过读取日志记录来追赶主库的形式来形成备份的,在我们搭建好主从数据库后,对于逻辑备份而言,第一次一般都要先执行一遍mysqldump,其中注意的参数有①master-data,一般设置为2用来开启dump过程中记录主库的binlog和pos点(下面的点位),并在dump文件中注释掉,一般在用到主从时用到这个参数。②–single-transaction用来保证备份的一致性,设置本次会话的隔离级别为REPEATABLE READ可重复读,以确保本次会话(dump)时不会看到其他会话已经提交的数据。
  之所以在第一次在逻辑备份的时候要执行一次mysqldump,是因为我们日志的大小或者存储的时间是有限定的,假设主库已经存了500G的实例,而从库为0,主库的日志只存了近两天的记录,而我们从库就不能通过读主库的日志来进行备份了,就必须手动dump一下先把这500G的数据让从库去追,追上后然后才开始慢慢读主库的日志来进行备份。

  脏页:因为硬盘的读写速度远赶不上内存的速度,系统就把读写比较频繁的数据事先放到内存中,以提高读写速度,这就叫高速缓存。
linux是以页作为高速缓存的单位,当进程修改了高速缓存里的数据时,该页就被内核标记为脏页,内核将会在合适的时间把脏页的数据写到磁盘中去,以保持高速缓存中的数据和磁盘中的数据是一致的。

下面介绍逻辑备份工具的使用:

Mysqldump:

  Mysqldump是逻辑备份,可以将数据库备份成一个文本文件,该文件里面包含了sql语句。Mysqldump是单线程备份工具。
  我们使用mysqldump进行备份,用mysql进行恢复。
  可以使用show variables like ‘%log_bin%’来查看log_bin打开状况。
在这里插入图片描述
  可以使用show variables like ‘%server%’来查看server_id是多少。Server_id是一种标识,用来判断binlog中每条记录是在哪个服务器上产生的,在主主复制架构中可以防止无限复制循环,其实就是mysql进程的标识(因为一台机器可以开多个Mysql进程)
在这里插入图片描述
  可以使用show master logs查看所有日志情况,每一次的dump都会生成一个binlog:
在这里插入图片描述
  在binlog中记录了点位情况,从库就是通过点位去找要执行主库的哪一个日志中的哪一条事务。
首先,我们在主库中创建了一个数据库fxdb1,然后我们去备份这个数据库。在一个文件夹里面执行以下命令:
  mysqldump -h10.236.158.96 -uroot -P9006 -p#77GFMhyp8 --databases fxdb1> fxdb1.sql
如果我们不加—databases,则我们生成的fxdb1.sql文本里面是没有create database的语句的。

  一致性备份:mysqldump是单线程,先备份A表,再备份B表,再备份C表…,假如A表数据量很大,当A表还没备份完的时候,B表已经更改了数据,此时A表备份完开始备份B表时,B表就不再是之前的数据了,此时就要加上一致性备份。也就是在mysqldump的时候加上–single-transaction参数,设置本次会话的隔离级别为REPEATABLE READ可重复读,以确保本次会话(dump)时不会看到其他会话已经提交的数据。除此之外,还有一个主从的master-data参数,一般设置为2用来开启dump过程中记录主库的binlog和pos点(下面的点位),并在dump文件中注释掉。点位的情况如下:
在这里插入图片描述
  Ex:每一次的mysqldump都会生成一个日志文件。000003这种是自增的。
  为什么–single-transaction可以达到一致性备份呢:
  在mysql钟可以通过show variables like ‘%isolation%’来查看隔离级别。
在这里插入图片描述
  我们在调试的时候,可以打开另一个日志文件general_log,他不同于binlog和redolog,他记录的是我们执行的sql语句,一般general_log为关闭状态,因为打开很消耗性能,所以一般是调试的时候才打开,例如这里我们像查看–single-transaction的情况就可以打开查看。general_log一共有三个属性:general_log(on、off)决定打开关闭状态、general_log_file存储的位置、log_output决定general的文件类型(FILE、TABLE)。
在这里插入图片描述
  现在我们打开general_log后,再执行一次备份,然后查看db01.log可以看到:
在这里插入图片描述
  结论:–single-transaction会将隔离级别设置为REPEATABLE_READ可重复读,并随后再执行一条START TRANSACTION语句,让整个数据再dump过程钟保证数据的一致性,这个选项对InnoDB的数据表很有用,且不会锁表,就是对其他用户的操作不会有影响。而对于myisam而言,就会锁表,毕竟他没有事务。

增量恢复: 我们在备份的时候,数据库也在不断运行,假如我们在数据库的最新点进行一致性备份,备份了一分钟,但是在这一分钟里数据库在不断运行,一分钟后原来的最新点就不再是最新点了,那么如果此时数据库挂掉了,那么增加的那一部分的恢复就需要用到增量恢复。
  增量恢复:备份+binlog。
  也就用全备份的数据+binlog读取新增的数据来实现增量恢复。
在这里插入图片描述
  而这个binlog日志文件可以在mysql的目录下看(一般在/var/lib/mysql),里面存放的有很多binlog日志文件。当我们主库宕机了,那么我们就需要用备份文件恢复,然后再用日志文件进行增量恢复,毕竟日志先行,日志都落地到磁盘里了的。

mysqlpump

  也是逻辑备份工作,是多线程备份工具,他主要特点是:
  ① 多线程只能到表级别,单表备份还是单线程。一个库里面可以同时备份多张表,而mysqldump一次只能备份一张表。
  ② 并行备份数据库和数据库中的对象,加快备份过程。
  ③ 备份出来直接生成压缩后的备份文件。
  ④ 重新加载(还原)备份文件时,是先建表后插入数据最后建立索引,减少了索引维护开销,加快了还原速度。因为如果是先建表再建立索引再插入数据的话,那么一边插入数据一边会维护索引。

  这里我们写一次mysqlpump备份的语句,之后的备份语句就不再写了,都差不多:
  Mysqlpump -uroot -p123456 –default-character-set=utf8mb4 –databases fxdb1 > fxdb1.sql
  我们查看他的备份sql文件fxdb1.sql可以看到:
在这里插入图片描述
  他是创建一张表后,再创建一张表,然后再给第一张表插入数据,最后再给第二张表插入数据。这里就和mysqldump不一样,在mysqldump中就是创建一张表,然后插入数据,然后再创建第二张表,再插入数据。
  无论是mysqldump还是mysqlpump还是其他,我们想要看他有哪些参数,可以通过mysqlpump –help > help.txt 然后查看help.txt可以得到参数。
  通过翻阅参数可以看到,想要压缩我们mysqldump出来的sql文件,他不是自动压缩,是需要我们带参数他才会帮我们压缩,参数为–compress-output=name,还有其他参数如下:
  ① --compress-output=name压缩参数,name可以为LZ4
  ② --default-parallelism=# 开启几个线程去执行,默认是2个线程,这里#可以设置成3,4更多。
  其他参数和mysqldump差不多。
  例如上面mysqlpump的逻辑备份语句可以写成:
Mysqlpump -uroot -p123456 –default-character-set=utf8mb4 --compress-output=LZ4 --default-parallelism=4 --databases fxdb1 > fxdb1.sql
  此时我们再看fxdb1.sql会发现里面引入了压缩:
在这里插入图片描述
  那么我们需要对fxdb1.sql进行解压。
  Mysqlpump解决一致性问题也是–single-transactio

mydumper

  mydumper是多线程的备份工具,单表也可以多线程备份。要使用mydumper的话需要下载。
  备份命令是mydumper,恢复命令是myloader。
  Mydumper是通过–outputdir参数把备份文件放到一个目录里,而不是像之前的mysqldump这些是存放到一个sql文件中:
  mydumper -uroot -p123456 –database fxdb1 –outputdir fxdb1
  这里变成了database而不是之前的databases,说明只可以一个数据库进行备份。就是把fxdb1数据库备份到fxdb1这个目录中。在这个目录中包含多个sql文件(metadata文件、每一张表都会对应两个sql文件表结构文件和表数据文件、数据库结构文件)。这里特别注意的是还有一个metadata文件,这里面记录的是点位信息:
在这里插入图片描述
  当然,使用mudumper也可以备份所有的数据库,也就是我加 --database这个参数,默认的是备份所有数据库。他跟前面的mysqldump就不一样,mysqldump可以指定备份哪些数据库,这个要么备份一个,要么备份全部。如果非要用mydumper备份指定的哪些数据库,则可以用–regex来写正则表达式实现。
  如果要备份数据库中的一些表,则使用–tables-list 表名1,表名2
  对于mydumper,要解决一致性问题,使用–less-locking参数来解决。
  如果用mydumper来恢复表,则进入到目录然后再mysql中通过source命令来执行表结构的sql来创建表。
在这里插入图片描述
  Verbose是输出信息模式。

  以上三种都可以进行增量恢复

(2)物理备份

  要使用物理备份,首先要让主库的数据高可用,也就是持久化。redolog他是以页为单位记录一页行的变化,他不会记录每一条sql语句是Insert还是update,所以redolog的大小很小。任何的数据库操作都要遵循“日志先行”,这里的日志就是指的redolog:也就是说当我们主库insert后,要保证数据库的高可用,肯定要持久化,但是面对大量的数据,你去insert或者update开销很大,所以此时不能用数据做到同步,我们去同步的是redolog,让redolog先落地(可能存内存,也可能持久化到硬盘上),因为redolog很小,当内存足够时他就放到内存中,已经记录了的redolog在内存足够时不会被删除,这种redolog叫做脏页,就是已经同步过的有效数据,当内存满了再把这些redolog持久化到硬盘上。而对于数据而言,就是通过异步方式落地数据的。所以在我们执行数据库操作时,他一般有两个线程,一个线程记录变化的redolog,另一个线程记录.idb文件。当这些数据记录好后,就可以开始我们的物理备份。
  物理备份的原理和redolog息息相关,当开始物理备份的时候,XtraBackup会开两个线程,一个线程用来一页一页的复制innodb的数据,并且不锁定表。同时,另一个线程用来监控redolog,一旦redolog发生变化就立即把变化过的那一页复制走,因为redolog有大小限制,一旦写满后就会从头再开始写,所以新数据可能会覆盖旧的数据。
  物理备份速度快,但占用空间大,因为是整个库的文件的备份,mysql读数据读的都是文件因此在还原的时候就是把文件还原,让mysql去读文件就好,就不像逻辑备份那样一条条执行sql语句存到文件里。

Xtrabackup

  物理备份工具是Xtrabackup,它能对InnoDB数据库和XtraDB存储引擎的数据库地备份(不用像MyISAM那样锁表),mysqldump等逻辑备份最大的缺陷是备份和恢复速度较慢。
  物理备份Xtrabackup支持对innodb进行热备、增量备份,mysqldump这些逻辑备份不能做到增量备份,只能做到增量恢复。但是Xtrabackup只能对myisam进行温备,因为在b欸分myisam表时会给myisam表添加读锁,而且不能对myisam表进行增量备份,每次备份myisam数据都是全量(毕竟锁表后就没有增量了)。
  物理备份备份的是整个数据库,不能单独对某一个库某一张表进行备份了。
  Xtrabackup –user=root --password=123456 --backup full(目录)
  此时会产生一个full的文件夹,进入文件夹就会有很多我们数据库备份文件。

  总而言之,逻辑备份备份的是sql文件,在恢复的时候执行备份的sql语句实现数据库数据的重现。而物理备份则是备份数据文件了。

全库恢复

  命令有两个要执行才能实现全库恢复:
  ① Xtrabackup --apply-log --user-memory=32m full(之前备份的目录)
  ② Xtrabackup --copy-backup full
  一般情况下,再备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已提交但尚未同步到数据文件中的事务。因此此时数据文件仍处于不一致状态。因此此时我们需要用到命令①来避免上面的问题。
  --apply-log的作用是通过回滚未提交的事务以及同步已经提交的事务至数据文件使数据文件处于一致性状态。
  命令②就是进行复制恢复。
  此时我们主库就被恢复了,但还没完,我们需要进行增量恢复,毕竟我们只是备份了执行备份命令时的那些数据,此时主库可能又执行了很多。因此需要通过查看full文件夹里面的log日志和宕机时主库的log日志进行对比来实现增量恢复(日志先行,主库宕机了但是主库的binlog落地到磁盘里了的,可以从磁盘里找)。
  我们可以使用以下命令把binlog日志转成sql文件然后进行恢复:
  mysqlbinlog --start-position=154 mysql-bin.00011 > inc.sql
  Start-position=154是说从154这个位置开始同步,可以查看full文件夹里面的binlog_pos_innodb这个文件来得到:
在这里插入图片描述

增量备份

  增量备份的命令:
  Xtrabackup –user=root --password=123456 --incremental-basedir=full --incremental inc
  上面的命令的意思是在我们之前做的全备份的这个目录full下做增量备份,备份的文件放到inc这个文件夹里。
  所以增量备份其实就是把多出来的部分进行备份而已,没啥高大上的。
  我们可以在备份的文件夹里查看xtrabackup_checkpoints文件可以得到备份详情:
在这里插入图片描述
  Backup_type为备份类型:incremental为增量备份。From_lsn

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/很楠不爱3/article/detail/88427
推荐阅读
相关标签
  

闽ICP备14008679号