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中添加的选项,并重启;


***************当你发现自己的才华撑不起野心时,就请安静下来学习吧***************