mysql杂谈

Posted nmap

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql杂谈相关的知识,希望对你有一定的参考价值。

本文主要记录一些零碎知识点

1、mysql默认存储引擎变更
InnoDB as Default Storage Engine
mysql-5.5.5开始,InnoDB作为默认存储引擎,InnoDB作为支持事务的存储引擎,拥有相关的RDBMS特性:包括ACID事务支持,参考完整性(外健),灾难恢复能力等特性。
同时作为维护mysql内部结构的mysql和information_schema两个databases中的表,依然使用MyISAM存储引擎,而且不能被更改为InnoDB.
MySQL5.5开始新增一个数据库:PERFORMANCE_SCHEMA,主要用于收集数据库服务器性能参数。并且库里表的存储引擎均为PERFORMANCE_SCHEMA,而用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表。MySQL5.5默认是关闭的,需要手动开启,在配置文件里添加:
[mysqld]
performance_schema=ON

查看是否开启:

mysql>show variables like \'performance_schema\';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

从MySQL5.6开始,默认是打开状态

 

2、备份相关知识总结


 

2.1备份需要考虑的问题

可以容忍丢失多长时间的数据;
恢复数据要在多长时间内完;
恢复的时候是否需要持续提供服务;
恢复的对象,是整个库,多个表,还是单个库,单个表。

 

2.2 备份类型划分

(1)根据是否需要数据库离线
冷备(cold backup):需要关mysql服务,读写请求均不允许状态下进行;
温备(warm backup): 服务在线,但仅支持读请求,不允许写请求;
热备(hot backup):备份的同时,业务不受影响。
注:
1、这种类型的备份,取决于业务的需求,而不是备份工具
2、MyISAM不支持热备,InnoDB支持热备,但是需要专门的工具

 

(2)根据要备份的数据集合的范围

完全备份:full backup,备份全部字符集。
增量备份: incremental backup 上次完全备份或增量备份以来改变了的数据,不能单独使用,要借助完全备份,备份的频率取决于数据的更新频率。
差异备份:differential backup 上次完全备份以来改变了的数据。
建议的恢复策略:
完全+增量+二进制日志
完全+差异+二进制日志

(3) 根据备份数据或文件

物理备份:直接备份数据文件
优点:
备份和恢复操作都比较简单,能够跨mysql的版本,
恢复速度快,属于文件系统级别的
建议:
不要假设备份一定可用,要测试
mysql>check tables;检测表是否可用


逻辑备份: 备份表中的数据和代码
优点:
恢复简单、
备份的结果为ASCII文件,可以编辑
与存储引擎无关
可以通过网络备份和恢复
缺点:
备份或恢复都需要mysql服务器进程参与
备份结果占据更多的空间,
浮点数可能会丢失精度
还原之后,缩影需要重建

 

2.3 备份的对象
(1)数据
(2)配置文件
(3)代码:存储过程、存储函数、触发器
(4)os相关的配置文件
(5)复制相关的配置
(6)二进制日志

 

3.  Xtrabackup有两个主要的工具介绍:xtrabackup、innobackupex


 

Xtrabackup中包含两个工具:
xtrabackup -用于热备份innodb,xtradb引擎表的工具,不能备份其他表。
innobackupex-对xtrabackup封装的perl脚本,提供了用于myisam(会锁表)和innodb引擎,及混合使用引擎备份的能力。

 

innobackupex在备份过程中,会给非innodb表上读锁,会给innodb表上元数据信息锁
Xtrabackup有两个主要的工具:xtrabackup、innobackupex[个人推荐使用此方式]
注解:
(1).xtrabackup只能备份InnoDB和XtraDB 两种数据表
(2).innobackupex则封装了xtrabackup,同时可以备份MyISAM数据表

 

在Xtrabackup的wiki上简单的介绍了一下实现的原理:
首先,在logfile中找到并记录最后一个checkpoint(“last checkpoint LSN”),然后开始从LSN的位置开始拷贝InnoDB的logfile到xtrabackup_logfile;
接着,开始拷贝全部的数据文件.ibd;在拷贝全部数据文件结束之后,才停止拷贝logfile。
因为logfile里面记录全部的数据修改情况,所以,即时在备份过程中数据文件被修改过了,恢复时仍然能够通过解析xtrabackup_logfile保持数据的一致。

InnoDB维护了一个redo log,又称为 transaction log,事务日志,它包含了innodb数据的所有改动情况。
当InnoDB启动的时候,它会先去检查data file和transaction log,并且会做二步操作:
1.It applies committed transaction log entries to the data files
2.it performs an undo operation on any transactions that modified data but did not commit.
XtraBackup在备份的时候, 一页一页地复制innodb的数据,而且不锁定表,与此同时,XtraBackup还有另外一个线程监视着transactions log,
一旦log发生变化,就把变化过的log pages复制走。为什么要急着复制走呢? 前几章的时候就提过这个问题,
因为transactions log文件大小有限,写满之后,就会从头再开始写,所以新数据可能会覆盖到旧的数据。

每个InnoDB的页面都会包含一个LSN信息, 每当相关的数据发生改变, 相关的页面的LSN就会自 动增长。 这正是InnoDB表可以进行增量备份的基础, 即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

 

 

实现细节--文件权限
xtrabackup以read-write模式打开innodb的数据文件,然后对其进行复制。其实它不会修改此文件。
也就是说,运行xtrabackup的用户,必须对innodb的数据文件具有读写权限。
为什么要用rw模式呢?直接read模式不好么?
因为xtrabackup采用了其内置的innodb库来打开文件,而innodb库打开文件的时候就是rw的。

 

Innobackupex完整备份后生成了几个重要的文件:
xtrabackup_binlog_info:记录当前最新的LOG Position
xtrabackup_binlog_pos_innodb:innodb log postion
xtrabackup_checkpoints: 存放备份的起始位置beginlsn和结束位置endlsn,增量备份需要这个lsn [增量备份可以在这里面看from和to两个值的变化]

 

Xtrabackup特点:
(1)备份过程快速、可靠
(2)备份过程不会打断正在执行的事务
(3)能够基于压缩等功能节约磁盘空间和流量
(4)自动实现备份检验
(5)还原速度快

 

Xtrabackup工具仅支持对InnoDB存储引擎的增量备份
(1)首先完成一个完全备份,并记录下此时检查点的LSN(Log Sequence Number)。
(2)在进程增量备份时,比较表空间中每个页的LSN是否大于上次备份时的LSN,如果是,则备份该页,同时记录当前检查点的LSN。

 

innobackupex相关参数说明:

  --defaults-file:指定my.cnf参数文件的位置[此配置文件里必须指定datadir]
  --apply-log:同xtrabackup的--prepare参数,一般情况下,在备份完成后,数据尚且不能用于恢复操作,
因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。
因此,此时数据 文件仍处理不一致状态。--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。
  --copy-back:做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir 
  --remote-host=HOSTNAME: 通过ssh将备份数据存储到进程服务器上
  --stream=[tar]:备份文件输出格式, 该文件可在XtarBackup binary文件中获得. 在使用参数stream=tar备份的时候,你的xtrabackup_logfile可能会临时放在/tmp目录下,
  如果你备份的时候并发写入较大的话,xtrabackup_logfile可能会很大(5G+),很可能会撑满你的/tmp目录,可以通过参数--tmpdir指定目录来解决这个问题.
  --tmpdir=DIRECTORY:当有指定--remote-host or --stream时, 事务日志临时存储的目录, 默认采用MySQL配置文件中所指定的临时目录tmpdir 
  --redo-only --apply-log:强制备份日志时只redo,跳过rollback,这在做增量备份时非常必要
  --use-memory=*:该参数在prepare的时候使用,控制prepare时innodb实例使用的内存
  --databases=LIST:列出需要备份的databases,如果没有指定该参数,所有包含MyISAM和InnoDB表的database都会被备份
  --slave-info:备份从库, 加上--slave-info备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主日志文件以及偏移, 文件内容类似于:CHANGE MASTER TO MASTER_LOG_FILE=\'\', MASTER_LOG_POS=0 
  --socket=SOCKET:指定mysql.sock所在位置,以便备份进程登录mysql.

  

关于增量备份恢复时用到的--redo-only参数--个人理解

 

 

 本文参考链接

http://blog.csdn.net/luyaran/article/details/54023113
http://www.cnblogs.com/zhoujinyi/p/5236705.html
http://www.jb51.net/article/41570.htm
http://blog.sina.com.cn/s/blog_616b428f0101836h.html
http://mysql.taobao.org/monthly/2015/05/01/
https://wenku.baidu.com/view/590a96605bcfa1c7aa00b52acfc789eb172d9e35.html

 

以上是关于mysql杂谈的主要内容,如果未能解决你的问题,请参考以下文章

一条SQL查询语句是如何执行的? MySql杂谈

部分代码片段

鸟哥杂谈腾讯云 CentOS8 Linux环境下通过docker安装mysql

鸟哥杂谈腾讯云 CentOS8 Linux环境下通过docker安装mysql

杂谈——数据库事务及其隔离级别

linux中怎么查看mysql数据库版本