mysql的日志及利用mysqldump备份及还原
日志文件：6类
一般查询日志：log，general_log,log_output
慢查询日志：
错误日志
二进制日志
中继日志
事务日志
二进制日志：
记录了当前服务器的数据修改和有潜在可能性影响数据修改的语句
默认在数据目录下，通常情况下为mysql-bin
可以通过mysqlbinlog来查看
时间记录 time
偏移位置 position
show master status 查看当前使用的二进制日志和下一个事件开始时的基于的位置
日志滚动：当超过1G，日志会滚动
可以按照大小定义
时间定义
执行flush logs
查看当前正在使用的log日志
show binary logs
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 996 |
| mysql-bin.000002 | 126 |
| mysql-bin.000003 | 39892 |
| mysql-bin.000004 | 201 |
| mysql-bin.000005 | 194 |
+------------------+-----------+
二进制日志的功用
即时点恢复：
复制：
清除日志
PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr（某个时间之前） }
查看mysql的日志
SHOW BINLOG EVENTS
mysql> show binlog events\G
*************************** 1. row ***************************
Log_name: mysql-bin.000001
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 107
Info: Server ver: 5.5.33-log, Binlog ver: 4
service-id：服务器身份标识
INSERT INTO t1 value(current_date())
Mysql 记录二进制日志的格式
基于语句：statement
基于行：row
混合模式：mixed
指定从那个位置开始读取
mysql> show binlog events in 'mysql-bin.000001' from 371\G
或者
# mysqlbinlog --start-position=371 mysql-bin.000005
mysqlbinlog
--start-time
--stop-time
--start-position
--stop-position
二进制日志文件内容格式
事件发生的日期和时间
服务器ID
事件结束位置
事件的类型
原服务器生成此事件时的线程ID号
语句时间戳和写入二进制文件的时间差，单位为秒
错误代码，0表示正常执行
事件内容
事件位置（相当于下一事件的开始位置）
服务器参数：
log_bin = {ON|OFF}，还可以是一个文件路径
log_bin_trust_function_creators 不阻止任何存储函数
sql_log_bin = {ON|OFF} 当前会话是否将二进制文件进入进二进制文件
sql_log_off 是否将一般查询日志记入查询日志
sync_binlog 同步缓冲中的二进制到硬盘的时间，0不基于时间同步，只在事件提交时同步
binlog_format = {|statement|row|mixed}
max_binlog_cache_size = mysql二进制日志的缓冲区大小，仅用于缓存事务类的语句
max_binlog_stmt_cache_size 语句缓冲区大小，即事务类和非事务类公用的大小
max_binlog_size 二进制日志文件的上限，单位为字节
建议：切勿将二进制日志与数据文件放在同一设备
设置二进制日志文件目录：
# mkdir /data/binlog
# chown mysql.mysql /data/binlog
vim /etc/my.cnf
加入 log-bin=/data/binlog/mysql-bin
重启mysql服务生效
# service mysqld restart
可以临时通过sql_log_bin来控制二进制的写入
中继日志：
对于非从服务器 中继日志没有启用
relay_log_purge = {ON|OFF} 是否自动清理不在需要的中继日志
relay_log_space_limit 中继大小是否限制
备份和恢复：
1.做灾难恢复
2.做审计
3.测试
备份：目的用于恢复；对备份数据做恢复测试
备份类型：
根据备份时，数据库服务器是否在线
冷备：cold backup
温备：warm backup 全局施加共享锁，只能读，不能写
热备：hot backup
根据备份的数据集：
完全备份 full backup
部分备份 partial backup
根据备份时的接口（直接备份数据文件还是通过mysql服务器导出数据）
物理备份：直接复制（归档）数据文件的备份方式
逻辑备份：把数据从库中提取出来保存为文本文件
根据备份时是备份整个数据还是仅备份变化的数据
完全备份：full backup
增量备份：incremental backup
差异备份：differential backup 从上一个完全备份开始备份
备份策略：
选择备份方式
选择备份时间
考虑到恢复成本
恢复时长
考虑备份成本
锁时间
备份时长
备份负载
备份对象：
数据
配置文件：
代码：存储过程、存储函数、触发器
OS相关的配置文件，如crontab配置计划及相关脚本
跟复制相关的配置信息：
二进制日志文件
常用的备份工具
mysqldump（单线程）：逻辑备份工具
InnoDB热备、MyISAM温备、Aria温备
备份和恢复过程较慢
mysqldumper：多线程的mysqldump
很难实现差异或增量备份
基于lvm-snapshot
接近于热备的工具，因为要先请求全局锁，而后创建快照，并在创建完成后释放全局锁
使用cp、tar等工具进行物理备份
备份和恢复速度较快
很难实现增量备份，并且请求全局锁需要等待一段时间，在繁忙的服务器上尤其如此
SELECT clause INTO OUTFILE ‘/path/to/somefile’
LOAD DATA INFILE ‘/path/from/somefile’
部分备份工具，不会备份关系定义，仅备份表中的数据
是个逻辑备份工具，快于mysqldump
Innobase：商业备份工具，innobackup
Xtarbackup：有Percona提供的开源备份工具
InnoDB热备，增量备份
MyISAM热备，不支持增量
物理备份，速度快
mysqlhotcopy：几乎冷备
mysqldump：仅适用于数据集较小
使用格式：mysqldump [options] [db_name [tbl_name ...]]
还原时库应该存在
-u uername
-h 主机名
-p 密码
恢复时应该使用mysql < /path/to/file.mysql
备份单个库 mysqldump [options] db_name > /path/to/file.mysql
恢复时如果目标不存在，应先创建数据库，如果不想创建，这使用--databases
# mysqldump -uroot -hlocalhost -p hellodb > /tmp/hello.sql
备份所有的库
mysqldump --all-databases > /path/to/file.mysql
# mysqldump --all-databases > /tmp/alldb.sql
备份指定的多个库
--databases tb1 tb2 .....
# mysqldump --databases hellodb mydb > /tmp/hellandmydb.sql
恢复：
# mysql < /tmp/hellandmydb.sql
注意：备份前要加锁
--lock-all-tables ：请求锁定所有表之后在备份，对MyISAM，InnoDB，Aria做温备
--single-transaction：能够对InnoDB存储引擎实现热备
备份代码
--events：备份事件调度器代码
--routines：备份存储过程和存储函数
--triggers：备份触发器
备份时滚动日志：
--flush-logs：备份前、请求到锁之后滚动日志
复制时的同步位置标记
--master-data={0|1|2}
0表示不记录，
1表示记录为change master语句
2表示记录为注释的change master语句
使用mysqldump备份
请求锁：--lock-all-tables 或使用--single-transaction进行innodb热备
滚动日志：--flush-logs
选定要备份的库 --databases
记录二进制文件及位置 --master-date
手动请求全局锁
FLUSH [NO_WRITE_TO_BINLOG | LOCAL] flush_option [, flush_option] ...
flush tables with read lock
flush logs
unlock tables
恢复：
建议：关闭二进制日志，关闭其他用户的写操作
应该用souce 恢复
备份策略：基于mysqldump
备份：mysqldump+二进制日志文件
周日做一次完全备份，备份的同时滚动日志
周一至周六：备份二进制日志
myadmin flush-logs
恢复：完全备份+各二进制文件至此刻的事件
对于MYsql配置文件，以及与mysql相关的OS配置文件在每次修改后都应该直接进行备份
案例： 对hellodb数据库进行还原操作
1.查看hellodb数据库表使用的引擎情况，有myisam数据库
mysql> show table status from hellodb\G
备份hellodb数据库，--master-data-2标记日志文件的位置
# mysqldump --databases hellodb --lock-all-tables --flush-logs --master-data=2 > /tmp/hello.a.sql
通过命令可以看到此时的位置107，
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 107 | | |
+------------------+----------+--------------+------------------+
或者vim /tmp/hellodb.20160114.sql，也可以看到二进制文件标记
2.模拟失误操作
创建newtb表，并插入数据
mysql> create table newtb(name char(30));
mysql> insert into newtb(name) values('tom'),('lily'),('lucy');
清空表数据
mysql> truncate table newtb;
查看二进制从107位置开始的日志记录
# mysqlbinlog --start-position=107 /data/binlog/mysql-bin.000004
将日志中记录这一部分记录截取出来生成增量的sql
# mysqlbinlog --start-position=107 --stop-position=712 mysql-bin.000005 > /tmp/hello.a.inc.sql
3.还原
关闭还原操作的日志记录
mysql> set session sql_log_bin=0;
还原完整备份
mysql> source /tmp/hellodb.a.sql
验证数据库是否存在
还原增量备份
mysql> source /tmp/hello.a.inc.sql
