Mysql备份
备份类型:
热备份,温备份,冷备份
热备份:读写不受影响
温备份:仅仅可以执行读操作
冷备份:离线备份,服务停止,读写操作均终止
物理备份和逻辑备份
物理备份:复制数据文件
逻辑备份:将数据导出至文本文件
完全备份。增量备份和差异备份
完全备份:备份全部数据
增量备份:仅备份上次完全备份或增量备份以后变化的数据
差异备份:仅备份上次完全备份以来变化的数据
在线:物理完全备份
还原
备份什么
数据,配置文件,二进制文件,事物文件
热备份
MyIsam:温备份
InnoDb:xtrabackup mysqldump
Mysql ->从
物理备份:速度快
逻辑备份:速度慢,丢失浮点数精度,方便使用文本处理工具直接对其处理可移植性强
备份策略:完全+增量 ;完全+差异
Mysql备份工具
Mysqldump,逻辑备份工具 myisam(温备)Inoodb(热备份)
Mysqlhostcopy 物理备份工具,温备份
文件系统工具
Cp
Lv:逻辑卷的快照功能,几乎实现热备;---à不适合innodb引擎 flush tables需要监控
Mysql>flush tables;
Mysql>lock tables
创建快照,释放锁而后复制数据
第三组工具
Ibbackup
Xtrabackup:开源工具
Mysqldump 逻辑备份
Mysqldump (安全备份) + 二进制文件
完全+增量
完全+差异
备份单个数据库 或库中特定表
Mysqldump DB_NAME [tb1] [tb2] > xx.sql
在执行备份前需要锁表
Mysql>flush tables with read lock;
或者
Mysql>lockt ables
Mysql>flush logs 将日志刷新
Mysql>flush tables
备份完然后释放锁
Mysql>unlock tables
--master-data={0|1|2}
0:不记录二进制文件及位置
# mysqldump -uroot -p test01 > /tmp/upload/test01-`date '+%F-%H:%M:%S'`.sql
--lock-all-tables:锁定所有表
--flush-logs 执行日志flush
如果制定库中所有表的类型均为Innodb,可以使用—single-transaction启动热备
备份多个库
--all-databases 备份所有库
--databases DB_NAME,DB_NAME2,...备份指定库
--events
--routines
--triggers
备份策略 每周完全 + 每日增量
完全备份Mysqldump
增量备份 备份二进制文件 (flush logs)
查看文件中记录的位置,然后可以删除一些日志
Flush logs
数据库出现故障 文件全部损坏
导入数据库
处理二进制文件并且导入
产看日志中的操作
> show binlog events in 'mysql-bin.000224' limit 3,5 ; 从第三行开始列出5行
备份:
SELECT * INTO OUTFILE '/path/to/somefile.txt' FROM tb_name [WHERE clause];
还原:
LOAD DATA INFILE '/path/to/somefile.txt' INTO TABLE tb_name;
几乎热备:LVM
snapshot:
前提:
1、数据文件要在逻辑卷上;
2、此逻辑卷所在卷组必须有足够空间使用快照卷;
3、数据文件和事务日志要在同一个逻辑卷上;
步骤:
1、打开会话,施加读锁,锁定所有表;
mysql> FLUSH TABLES WITH READ LOCK;
mysql> FLUSH LOGS;
2、通过另一个终端,保存二进制日志文件及相关位置信息;
$ mysql -uroot -p -e 'SHOW MASTER STATUS\G' > /path/to/master.info
3、创建快照卷
# lvcreate -L # -s -p r -n LV_NAME /path/to/source_lv
4、释放锁
mysql> UNLOCK TABLES;
5、挂载快照卷,备份
mount
cp
6、删除快照卷;
7、增量备份二进制日志;
二进制日志相关的几个选项:
innodb_support_xa={TRUE|FLASE}
存储引擎事务在存储引擎内部被赋予了ACID属性,分布式(XA)事务是一种高层次的事务,它利用“准备”然后“提交”(prepare-then-commit)两段式的方式将ACID属性扩展到存储引擎外部,甚至是数据库外部。然而,“准备”阶段会导致额外的磁盘刷写操作。XA需要事务协调员,它会通知所有的参与者准备提交事务(阶段1)。当协调员从所有参与者那里收到“就绪”信息时,它会指示所有参与者进行真正的“提交”操作。
此变量正是用于定义InnoDB是否支持两段式提交的分布式事务,默认为启用。事实上,所有启用了二进制日志的并支持多个线程同时向二进制日志写入数据的MySQL服务器都需要启用分布式事务,否则,多个线程对二进制日志的写入操作可能会以与原始次序不同的方式完成,这将会在基于二进制日志的恢复操作中或者是从服务器上创建出不同原始数据的结果。因此,除了仅有一个线程可以改变数据以外的其它应用场景都不应该禁用此功能。而在仅有一个线程可以修改数据的应用中,禁用此功能是安全的并可以提升InnoDB表的性能。作用范围为全局和会话级别,可用于选项文件,属动态变量。
sync_binlog = 1
mysql> LOCK TABLES mydb.tb1 READ, mydb.tb2 READ, ...
mysql> FLUSH TABLES mydb.tb1, mydb.tb2, ...
mysq> SET SQL_LOG_BIN=0;
mysql> SOURCE somefile.sql;
mysql> SET SQL_LOG_BIN=1;
percona:
ibbackup: InnoDB online physical backup
full
incremental
MyISAM: warm backup, full
$5000
mysqldump
LVM --> mylvmbackup(perl scripts)
percona:
xtrabackup
xtradb: innodb的增强版
innodb
xtrabackup+二进制日志;
mysql: