• 欢迎访问 winrains 的个人网站!
  • 本网站主要从互联网整理和收集了与Java、网络安全、Linux等技术相关的文章,供学习和研究使用。如有侵权,请留言告知,谢谢!

MySQL 备份系列(1):备份方案总结性梳理

MySQL winrains 来源:散尽浮华 4个月前 (05-15) 29次浏览

mysql数据库备份有多么重要已不需过多赘述了,废话不多说!以下总结了mysql数据库的几种备份方案:

一、binlog二进制日志

通常作为备份的重要资源,所以再说备份方案之前先总结一下binlog日志~~

1.binlog日志内容

1)引起mysql服务器改变的任何操作。
2)复制功能依赖于此日志。
3)slave服务器通过复制master服务器的二进制日志完成主从复制,在执行之前保存于中继日志(relay log)中。
4)slave服务器通常可以关闭二进制日志以提升性能。

2.binlog日志文件的文件表现形式

1)默认在安装目录下,存在mysql-bin.00001, mysql-bin.00002的二进制文件(binlog日志文件名依据my.cnf配置中的log-bin参数后面的设置为准)
2)还有mysql-bin.index用来记录被mysql管理的二进制文件列表
3)如果需要删除二进制日志时,切勿直接删除二进制文件,这样会使得mysql管理混乱。

3.binlog日志文件查看相关mysql命令

1)SHOW MASTER STATUS ; 查看正在使用的二进制文件

MariaDB [(none)]> SHOW MASTER STATUS ;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 245 | | |
+------------------+----------+--------------+------------------+

2)FLUSH LOGS; 手动滚动二进制日志

MariaDB [(none)]> FLUSH LOGS;
MariaDB [(none)]> SHOW MASTER STATUS ;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 245 | | |
+------------------+----------+--------------+------------------+

滚动以后,mysql重新创建一个新的日志mysql-bin.000004
3)SHOW BINARY LOGS 显示使用过的二进制日志文件

MariaDB [(none)]> SHOW BINARY LOGS ;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 30373 |
| mysql-bin.000002 | 1038814 |
| mysql-bin.000003 | 288 |
| mysql-bin.000004 | 245 |

4)SHOW BINLOG EVENTS 以表的形式查看二进制文件
命令格式:SHOW BINLOG EVENTS [IN ‘log_name’] [FROM pos] [LIMIT [offset,] row_count]

MariaDB [(none)]> SHOW BINLOG EVENTS IN 'mysql-bin.000001' \G;
*************************** 99. row ***************************
Log_name: mysql-bin.000001
Pos: 30225
Event_type: Query
Server_id: 1
End_log_pos: 30354
Info: use `mysql`; DROP TEMPORARY TABLE `tmp_proxies_priv` /* generated by server */

4.MySQL二进制文件读取工具mysqlbinlog

命令格式:mysqlbinlog [参数] log-files
有以下四种参数选择:
–start-datetime
–stop-datetime
–start-position
–stop-position

[root@test-huanqiu ~]# mysqlbinlog --start-position 30225 --stop-position 30254 mysql-bin.000001

截取一下结果:

# at 30225
#151130 12:43:35 server id 1 end_log_pos 30354 Querythread_id=1exec_time=0error_code=0
use `mysql`/*!*/;
SET TIMESTAMP=1448858615/*!*/;
SET @@session.pseudo_thread_id=1/*!*/

根据以上截取结果第二行,进行解释二进制日志内容
1)时间点: 151130 12:43:35
2)服务器ID: server id 1
服务器ID主要用于标记日志产生的服务器,主要用于双主模型中,互为主从,确保二进制文件不会被相互循环复制
3)记录类型: Query
4) 线程号: thread_id = 1
5) 语句的时间戳和写入二进制日志文件的时间差; exec_time=0
6) 事件内容
7)事件位置 #at 30225
8) 错误代码 error_code=0
9) 事件结束位置 end_log_pos也就是下一事件开始的位置

5.二进制日志格式

由bin_log_format={statement|row|mixed}定义
1)statement: 基于语句,记录生成数据的语句
缺点在于如果当时插入信息为函数生成,有可能不同时间点执行结果不一样,
例如: INSERT INTO t1 VALUE (CURRENT_DATE());
2)row: 基于行数据
缺点在于,有时候数据量会过大
3)mixed: 混合模式,又mysql自行决定何时使用statement, 何时使用row 模式

6.二进制相关参数总结

1)log_bin = {ON|OFF}
还可以是个文件路径,自定义binlog日志文件名,使用“log_bin=“或“log-bin=“都可以,主要用于控制全局binlog的存放位置和是否开启binlog日志功能。
比如:log_bin=mysql-bin 或者 log-bin=mysql-bin,这样binlog日志默认会和mysql数据放在同一目录下。
2) log_bin_trust_function_creators
是否记录在
3) sql_log_bin = {ON|OFF}
会话级别是否关闭binlog, 如果关闭当前会话内的操作将不会记录
4) sync_binlog 是否马上同步事务类操作到二进制日志中
5) binlog_format = {statement|row|mixed} 二进制日志的格式,上面单独提到了
6) max_binlog_cache_size =
二进制日志缓冲空间大小,仅用于缓冲事务类的语句;
7) max_binlog_stmt_cache_size =
语句缓冲,非事务类和事务类共用的空间大小
8) max_binlog_size =
二进制日志文件上限,超过上限后则滚动
9) 删除二进制日志
命令格式:PURGE { BINARY | MASTER } LOGS { TO ‘log_name’ | BEFORE datetime_expr }

MariaDB> PURGE BINARY LOGS TO 'mysql-bin.010';
MariaDB> PURGE BINARY LOGS BEFORE '2016-11-02 22:46:26';

建议:切勿将二进制日志与数据文件放在一同设备;可以将binlog日志实时备份到远程设备上,以防出现机器故障进行数据恢复;

二、接下来说下binlog二进制日志备份和恢复

1.为什么做备份:

(1)灾难恢复
(2)审计,数据库在过去某一个时间点是什么样的
(3)测试

2.备份的目的:

(1)用于恢复数据
(2)备份结束后,需要周期性的做恢复测试

3.备份类型:

(1)根据备份时,服务器是否在线
1)冷备(cold backup): 服务器离线,读写操作都不能进行
2)温备份: 全局施加共享锁,只能读不能写
3)热备(hot backup):数据库在线,读写照样进行
(2)根据备份时的数据集分类
1)完全备份(full backup)
2)部分备份(partial backup)
(3)根据备份时的接口
1)物理备份(physical backup):直接复制数据文件 ,打包归档
特点:
不需要额外工具,直接归档命令即可,但是跨平台能力比较差;如果数据量超过几十个G,则适用于物理备份
2)逻辑备份(logical backup): 把数据抽取出来保存在sql脚本中
特点:
可以使用文本编辑器编辑;导入方便,直接读取sql语句即可;逻辑备份恢复时间慢,占据空间大;无法保证浮点数的精度;恢复完数据库后需要重建索引。
(4)根据备份整个数据还是变化数据
1) 全量备份 full backup
2) 增量备份 incremental backup
在不同时间点起始备份一段数据,比较节约空间;针对的是上一次备份后有变化的数据,备份数据少,备份快,恢复慢
3) 差异备份 differential backup
备份从每个时间点到上一次全部备份之间的数据,随着时间增多二增多;比较容易恢复;对于很大的数据库,可以考虑主从模型,备份从服务器的内容。针对的是上一次全量备份后有变化的数据,备份数据多,备份慢,恢复快。
(5)备份策略,需要考虑因素如下
备份方式
备份实践
备份成本
锁时间
时长
性能开销
恢复成本
恢复时长
所能够容忍丢失的数据量
(6)备份内容
1)数据库中的数据
2)配置文件
3)mysql中的代码: 存储过程,存储函数,触发器
4)OS 相关的配置文件,chrontab 中的备份策略脚本
5)如果是主从复制的场景中: 跟复制相关的信息
6)二进制日志文件需要定期备份,一旦发现二进制文件出现问题,需马上对数据进行完全备份

(7)Mysql最常用的三种备份工具:
1)mysqldump:
通常为小数据情况下的备份
innodb: 热备,温备
MyISAM, Aria: 温备
单线程备份恢复比较慢
2)Xtrabackup(通常用innobackupex工具):
备份mysql大数据
InnoDB热备,增量备份;
MyISAM温备,不支持增量,只有完全备份
属于物理备份,速度快;
3)lvm-snapshot:
接近于热备的工具:因为要先请求全局锁,而后创建快照,并在创建快照完成后释放全局锁;
使用cp、tar等工具进行物理备份;
备份和恢复速度较快;
很难实现增量备份,并且请求全局需要等待一段时间,在繁忙的服务器上尤其如此;

除此之外,还有其他的几个备份工具:
–>mysqldumper: 多线程的mysqldump
–>SELECT clause INTO OUTFILE ‘/path/to/somefile’ LOAD DATA INFILE ‘/path/from/somefile’
部分备份工具, 不会备份关系定义,仅备份表中的数据;
逻辑备份工具,快于mysqldump,因为不备份表格式信息
–>mysqlhotcopy: 接近冷备,基本没用

mysqldump工具基本使用

1. mysqldump [OPTIONS] database [tables…]
还原时库必须存在,不存在需要手动创建
–all-databases: 备份所有库
–databases db1 db2 …: 备份指定的多个库,如果使用此命令,恢复时将不用手动创建库。或者是-B db1 db2 db3 ….
–lock-all-tables:请求锁定所有表之后再备份,对MyISAM、InnoDB、Aria做温备
–lock-table: 对正在备份的表加锁,但是不建议使用,如果其它表被修改,则备份后表与表之间将不同步
–single-transaction: 能够对InnoDB存储引擎实现热备;
启动一个很大的大事物,基于MOCC可以保证在事物内的表版本一致
自动加锁不需要,再加–lock-table, 可以实现热备
备份代码:
–events: 备份事件调度器代码
–routines: 备份存储过程和存储函数
–triggers:备份触发器
备份时滚动日志:
–flush-logs: 备份前、请求到锁之后滚动日志;
方恢复备份时间点以后的内容
复制时的同步位置标记:主从架构中的,主服务器数据。效果相当于标记一个时间点。
–master-data=[0|1|2]
0: 不记录
1:记录为CHANGE MASTER语句
2:记录为注释的CHANGE MASTER语句

2. 使用mysqldump备份大体过程:
1) 请求锁:–lock-all-tables或使用–singe-transaction进行innodb热备;
2) 滚动日志:–flush-logs
3) 选定要备份的库:–databases
4) 记录二进制日志文件及位置:–master-data=
FLUSH TABLES5 WITH READ LOCK;

3. 恢复:
恢复过程无需写到二进制日志中
建议:关闭二进制日志,关闭其它用户连接;

4. 备份策略:基于mysqldump
备份:mysqldump+二进制日志文件;(“mysqldump >”)
周日做一次完全备份:备份的同时滚动日志
周一至周六:备份二进制日志;
恢复:(“mysql < ”)或在mysql数据库中直接执行“source sql备份文件;”进行恢复。如果sql执行语句比较多,可以将sql语句放在一个文件内,将文件名命名为.sql结尾,然后在mysql数据库中使用”source 文件.sql;”命令进行执行即可!
完全备份+各二进制日志文件中至此刻的事件

5. 实例说明:
参考:Mysql备份系列(2)–mysqldump备份(全量+增量)方案操作记录

lvm-snapshot:基于LVM快照的备份

1.关于快照:

1)事务日志跟数据文件必须在同一个卷上;
2)刚刚创立的快照卷,里面没有任何数据,所有数据均来源于原卷
3)一旦原卷数据发生修改,修改的数据将复制到快照卷中,此时访问数据一部分来自于快照卷,一部分来自于原卷
4)当快照使用过程中,如果修改的数据量大于快照卷容量,则会导致快照卷崩溃。
5)快照卷本身不是备份,只是提供一个时间一致性的访问目录。

2.基于快照备份几乎为热备:

1)创建快照卷之前,要请求MySQL的全局锁;在快照创建完成之后释放锁;
2)如果是Inoodb引擎, 当flush tables 后会有一部分保存在事务日志中,却不在文件中。 因此恢复时候,需要事务日志和数据文件
但释放锁以后,事务日志的内容会同步数据文件中,因此备份内容并不绝对是锁释放时刻的内容,由于有些为完成的事务已经完成,但在备份数据中因为没完成而回滚。 因此需要借助二进制日志往后走一段

3.基于快照备份注意事项:

1)事务日志跟数据文件必须在同一个卷上;
2)创建快照卷之前,要请求MySQL的全局锁;在快照创建完成之后释放锁;
3)请求全局锁完成之后,做一次日志滚动;做二进制日志文件及位置标记(手动进行);

4.为什么基于MySQL快照的备份很好?

原因如下几点:
1)几乎是热备 在大多数情况下,可以在应用程序仍在运行的时候执行备份。无需关机,只需设置为只读或者类似只读的限制。
2)支持所有基于本地磁盘的存储引擎 它支持MyISAM, Innodb, BDB,还支持 Solid, PrimeXT 和 Falcon。
3)快速备份 只需拷贝二进制格式的文件,在速度方面无以匹敌。
4)低开销 只是文件拷贝,因此对服务器的开销很细微。
5)容易保持完整性 想要压缩备份文件吗?把它们备份到磁带上,FTP或者网络备份软件 — 十分简单,因为只需要拷贝文件即可。
6)快速恢复 恢复的时间和标准的MySQL崩溃恢复或数据拷贝回去那么快,甚至可能更快,将来会更快。
7)免费 无需额外的商业软件,只需Innodb热备工具来执行备份。

快照备份mysql的缺点:

1)需要兼容快照 — 这是明显的。
2)需要超级用户(root) 在某些组织,DBA和系统管理员来自不同部门不同的人,因此权限各不一样。
3)停工时间无法预计,这个方法通常指热备,但是谁也无法预料到底是不是热备 — FLUSH TABLES WITH READ LOCK 可能会需要执行很长时间才能完成。
4)多卷上的数据问题 如果你把日志放在独立的设备上或者你的数据库分布在多个卷上,这就比较麻烦了,因为无法得到全部数据库的一致性快照。不过有些系统可能能自动做到多卷快照。

5.备份与恢复的大体步骤

备份:

1)请求全局锁,并滚动日志

mysql> FLUSH TABLES WITH READ LOCK;
mysql> FLUSH LOGS;

2)做二进制日志文件及位置标记(手动进行);

[root@test-huanqiu ~]# mysql -e 'show master status' > /path/to/orignal_volume

3)创建快照卷

[root@test-huanqiu ~]# lvcreate -L -s -n -p r /path/to/some_lv

4)释放全局锁
5)挂载快照卷并备份
6)备份完成之后,删除快照卷

恢复:

1)二进制日志保存好;
提取备份之后的所有事件至某sql脚本中;
2)还原数据,修改权限及属主属组等,并启动mysql
3)做即时点还原
4)生产环境下, 一次大型恢复后,需要马上进行一次完全备份。

备份与恢复实例说明:

环境, 实现创建了一个test_vg卷组,里面有个mylv1用来装mysql数据,挂载到/data/mysqldata

备份实例:

1. 创建备份专用的用户,授予权限FLUSH LOGS 和 LOCK TABLES

MariaDB > GRANT RELOAD,LOCK TABLES,SUPER ON *.* TO 'lvm'@'192.168.1.%' IDENTIFIED BY 'lvm';
MariaDB > FLUSH PRIVILEGES;

2. 记录备份点

[root@test-huanqiu ~]# mysql -ulvm -h192.168.1.10 -plvm -e 'SHOW MASTER STATUS' > /tmp/backup_point.txt

3. 创建快照卷并挂载快照卷

[root@test-huanqiu ~]# lvcreate -L 1G -s -n lvmbackup -p r /dev/test_vg/mylv1
[root@test-huanqiu ~]# mount -t ext4 /dev/test_vg/lvmbackup /mnt/

4. 释放锁

[root@test-huanqiu ~]# mysql -ulvm -h192.168.98.10 -plvm -e 'UNLOCK TABLES'

做一些模拟写入工作

MariaDB [test]> create database testdb2

5. 复制文件

[root@test-huanqiu ~]# cp /data/mysqldata /tmp/backup_mysqldata -r

6. 备份完成卸载,删除快照卷

[root@test-huanqiu ~]# umount /mnt
[root@test-huanqiu ~]# lvmremove /dev/test_vg/lvmbackup

还原实例:
假如整个mysql服务器崩溃,并且目录全部被删除

1. 数据文件复制回源目录

[root@test-huanqiu ~]# cp -r /tmp/backup_mysqldata/* /data/mysqldata/
MariaDB [test]> show databases ;
+--------------------+
| Database |
+--------------------+
| information_schema |
| hellodb |
| mysql |
| mysqldata |
| openstack |
| performance_schema |
| test |
+--------------------+

此时还没有testdb2, 因为这个是备份之后创建的,因此需要通过之前记录的二进制日志

2. 查看之前记录的记录点。向后还原

[root@test-huanqiu ~]# cat /tmp/backup_point.txt
FilePositionBinlog_Do_DBBinlog_Ignore_DB
mysql-bin.000001245
[root@test-huanqiu ~]# mysqlbinlog /data/binlog/mysql-bin.000001 --start-position 245 > tmp.sql
MariaDB [test]> source /data/mysqldata/tmp.sql
MariaDB [test]> show databases ;
+--------------------+
| Database |
+--------------------+
| information_schema |
| hellodb |
| mysql |
| mysqldata |
| openstack |
| performance_schema |
| test |
| testdb2 |
+--------------------+
8 rows in set (0.00 sec)

testdb2 已经被还原回来。

具体实例说明,参考:Mysql备份系列(4)–lvm-snapshot备份mysql数据(全量+增量)操作记录

使用Xtrabackup进行MySQL备份:

参考:Mysql备份系列(3)–innobackupex备份mysql大数据(全量+增量)操作记录

—————————————————–

关于备份和恢复的几点经验之谈

备份注意:
1. 将数据和备份放在不同的磁盘设备上;异机或异地备份存储较为理想;
2. 备份的数据应该周期性地进行还原测试;
3. 每次灾难恢复后都应该立即做一次完全备份;
4. 针对不同规模或级别的数据量,要定制好备份策略;
5. 二进制日志应该跟数据文件在不同磁盘上,并周期性地备份好二进制日志文件;

从备份中恢复应该遵循步骤:
1. 停止MySQL服务器;
2. 记录服务器的配置和文件权限;
3. 将数据从备份移到MySQL数据目录;其执行方式依赖于工具;
4. 改变配置和文件权限;
5. 以限制访问模式重启服务器;mysqld的–skip-networking选项可跳过网络功能;
方法:编辑my.cnf配置文件,添加如下项:
skip-networking
socket=/tmp/mysql-recovery.sock
6. 载入逻辑备份(如果有);而后检查和重放二进制日志;
7. 检查已经还原的数据;
8. 重新以完全访问模式重启服务器;
注释前面第5步中在my.cnf中添加的选项,并重启;

作者:散尽浮华

来源:https://www.cnblogs.com/kevingrace/p/6112565.html


版权声明:文末如注明作者和来源,则表示本文系转载,版权为原作者所有 | 本文如有侵权,请及时联系,承诺在收到消息后第一时间删除 | 如转载本文,请注明原文链接。
喜欢 (0)