查询日志：general_log
慢查询日志：log_slow_querles
错误日志：log_error，log_warnings
二进制日志：binlog
中继日志：relay_log
事务日志：innodb_log
记录查询语句，日志存储位置：
文件：file
表：table（mysql.general_log）
general_log={ON|OFF}general_log_file=HOSTNAME.loglog_output={FILE|TABLE|NONE}慢查询：运行时间超出指定时长的查询；long_query_time
存储文件位置：
文件：file 表： table，mysql.slow_log
log_slow_queries={ON|OFF}
slow_query_log={ON|OFF} 是否开启慢查询
slow_query_log_file=log_output={FILE|TABLE|NONE}log_slow_filter=admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk 日志过滤器log_slow_rate_limitlog_slow_verbosity记录信息：
mysqld启动和关闭过程输出信息； mysqld运行中产生的错误信息； event scheduler运行时产生的信息； 主从复制构架中，从服务器复制线程启动时产生的日志；
log_error=log_warnings={ON|OFF}用于记录引起数据改变或存在引起数据改变的潜在可能性的语句（STATEMENT）或改变后结果（ROW），也可能是二者混合； 功能：“重放”
二进制日志查看命令：
mysqlbinlog
--start-datetime=
--stop-datetime=
-j,--start-position=#
--stop-position=#
--user,--host,--password
服务器变量：
log_bin=/PATH/TO/BIN_LOG_FILE 开启二进制日志，二进制日志存放位置，此配置卸载server.conf文件中的mysql模块
sql_log_bin={ON|OFF} 二进制日志是否开启
max_binlog_size=1073741824 日志文件大小
sync_binlog={1|0} 由事务提交时进行由内存到磁盘的同步，
binlog_format={STATEMENT|ROW|MIXED} STATEMENT:语句 ROW:行 MIXED:混编查看二进制日志文件列表：
SHOW MASTER|BINARY LOGS;
查看当前正在使用的二进制日志文件：
SHOW MASTER STATUS;
查看二进制日志文件中的事件：
SHOW BINLOG EVENTS [IN ‘log_name‘][FROM pos][LIMIT][offset,][row_count]
二进制日志时间格式： # at 553 #160831 9:56:08 server id 1 end_log_pos 624 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1472608568/*!*/; BEGIN /*!*/; 事件发生的日期时间：#160831 9:56:08 事件发生的服务器id：server id 1 事件的结束位置：end_log_pos 624 事件的类型：Query 事件发生时所在服务器执行此事件的线程的ID： thread_id=2 语句的时间戳与将其写入二进制日志文件中的时间差：exec_time=0 错误代码：error_code=0 事件内容：SET TIMESTAMP=1472608568/*!*/;从服务器上记录下来从中服务器的二进制日志文件同步过来的事件；
事务型存储引擎innodb用于保证事务特性的日志文件；
备份：存储的数据副本；
原始数据：持续改变；
备份一般不止一份，并且在备份后要经常性恢复演练；
恢复：把副本应用到线上系统；
仅能恢复至备份操作时刻的数据状态；
备份数据集的范围
完全备份：整个数据集
部分备份：数据集的一部分，例如备份部分表；
完全备份、增量备份、差异备份
增量备份：仅备份自上一次完全备份 或者备份以来再次改变的那部分数据；
差异备份：仅备份自上一次完全备份以来变量的那部分数据。
物理备份、逻辑备份：
物理备份：复制数据文件进行备份；
逻辑备份：从数据库导出数据另存在一个或多个文件中；
根据数据是否在线：
热备：读写操作均可进行的状态下所做的备份；
温备：可读但不可写状态下进行的备份;
冷备：读写均不可进行状态下所做的备份；
需要备份哪些
数据
二进制日志、InnoDB事务日志；
代码（存储过程、存储函数、触发器、时间调度器）# 服务器的配置文件
mysqldump ：mysql服务自带的备份工具；逻辑备份工具；
cp/tar
lvm2:快照（请求一个全局锁），之后立即释放锁，达到几乎热备的效果；物理备份；
注意：不能仅备份数据文件，要同时备份事务日志；要求数据文件和事务日志位于同一个逻辑卷
xtrabackup: 由percona提供，开源工具，支持对InnoDB做热备，物理备份工具；
完全备份、部分备份；
完全备份、增量备份；
完全备份、差异备份；
备份策略
完全+差异+binlog
完全+增量+binlog
逻辑备份、完全备份、部分备份；
二次封装工具：mydumper、phpMyAdmin
用法：
mysqldump [options] [db_name [tbl_name ...]] 备份表
mysqldump [options] --databases [options] DB1 [DB22 DB3...]备份库及表
mysqldump [options] --all-databases [options]
MyISAM存储引擎：支持温备，备份时需要锁定所有表；
-x,--lock-all-tables:锁定所有库的所有表；
-l,--lock-tables:锁定指定库的所有表； *InnoDB存储引擎：支持温备和热备 --single-transaction:创建一个事务，基于此快照执行备份
其他选项：
-R,--routines:存储过程和存储函数；
--triggers :触发器
-E,--events：事件调度器 --flush-logs:锁定表完成后，即进行日志刷新操作；
--master-date[=#]
1:记录为CHANGE MASTER TO语句，此语句不被注释；2:记录为CHANGE MASTER TO语句，此语句被注释；
备份数据库InnoDB
将备份的数据保存至文件内，备份实际上创建新的数据库，删除所有表，创建表在插入数据；
有databases时对数据库及表进行备份；
无databases时仅对表进行备份
[root@localhost ~]# mysqldump --databases hellodb --single-transaction -R --triggers -E --master-data=2 --flush-logs > /tmp/hellodb-$(date +%F)
删除数据库
MariaDB [(none)]> drop database hellodb;
需要备份二进制日志：
mysqlbinlog --stop-position=xxx /var/lib/mysql/master-log.00000x > /tmp/bin.log
恢复数据库
关闭二进制日志 set @@session.sql_log_bin=OFF
source /tmp/hello-date
source /tmp/bin.log
开启二进制日志 set @@session.sql_log_bin=ON
注意： 1、脚本化、周期性进行 2、备份结果要另存，建议为异地存储；对备份结果做测试； 3、配置mysqldump使用binlog做增量备份
物理备份工具，几乎热备，取决于快照命令执行的时长
前提：数据目录位于逻辑卷，包含了数据文件和事务日志；
(1)请求锁定所有表；
mysql>FLUSH TABLES WITH READ LOCK;
(2)记录二进制文件事件位置；
mysql>FLUSH LOGS;
mysql>SHOW MASTER STATUS;
#msyql -e ‘show master status;‘ >> /path/to/some_posfile
(3)创建快照卷
lvcreate -L # -s -p r - SNAM-NAME /dev/VG-NAME/LV-NAME
(4)释放锁
mysql> UNLOCK TABLES;
(5)挂载快照卷，并执行备份，备份完成后删除快照卷；
(6)周期性备份二进制日志
Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点：
(1)备份过程快速、可靠；
(2)备份过程不会打断正在执行的事务；
(3)能够基于压缩等功能节约磁盘空间和流量；
(4)自动实现备份检验；
(5)还原速度快；
支持InnoDB,XtraDB（mariadb）；
还原之前合并备份文件至一个完全备份文件；
MyISAM:温备，不支持增量备份；
InnoDB:热备，增量备份，物理备份；
物理备份：速率快、可靠；备份完成后自动效验备份结果集是否可用；还原速度快；
完全备份数据库
[root@localhost ~]# innobackupex --user=root --host=localhost /data/backup
主要生成以下文件
使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、
CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命名的目录中。
*在备份的同时，innobackupex还会在备份目录中创建如下文件：
(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息； 每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。 (2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。 (3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。 (4)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件； (5)backup-my.cnf —— 备份命令用到的配置选项信息 在使用innobackupex进行备份时，还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据 [root@localhost ~]# cd /data/backup/2017-02-21_12-26-09/[root@localhost 2017-02-21_12-26-09]# lltotal 18460-rw-r----- 1 root root 385 Feb 21 12:26 backup-my.cnf drwx------ 2 root root 138 Feb 21 12:26 hellodb -rw-r----- 1 root root 18874368 Feb 21 12:26 ibdata1 drwx------ 2 root root 4096 Feb 21 12:26 mysql drwx------ 2 root root 4096 Feb 21 12:26 performance_schema drwx------ 2 root root 19 Feb 21 12:26 test -rw-r----- 1 root root 23 Feb 21 12:26 xtrabackup_binlog_info 二进制备份日志 -rw-r----- 1 root root 113 Feb 21 12:26 xtrabackup_checkpoints 检查点文件 -rw-r----- 1 root root 480 Feb 21 12:26 xtrabackup_info -rw-r----- 1 root root 2560 Feb 21 12:26 xtrabackup_logfile 事务日志信息 [root@localhost 2017-02-21_12-26-09]#
注意innodb_log_file_size = 50331648
准备恢复
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。
因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
[root@localhost mysql]# innobackupex --apply-log /data/backup/2017-01-19_10-40-32/
在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
恢复数据
innobackupex命令的--copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。
innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。
[root@localhost mysql]# innobackupex --copy-back /data/backup/2017-01-19_10-40-32/
将mysql的文件属主和属组均改成mysql
当数据恢复至DATADIR目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。如：
[root@localhost mysql]# chown -R mysql.mysql ./*
启动mariadb服务
[root@localhost mysql]# systemctl start mariadb
注意：恢复数据时需清空/var/lib/mysql/并需要关闭mariadb服务
每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。
其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。
#innobackupex --incremental /backup --incremental-basedir=BASEDIR
其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。
另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。
注意：增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：
(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。 (2)基于所有的备份将未提交的事务进行“回滚”。
于是，操作就变成了：
# innobackupex --apply-log --redo-only BASE-DIR
接着执行：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
而后是第二个增量：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；
本文出自 “guo_ruilin” 博客，请务必保留此出处http://guoruilin198.blog.51cto.com/12567311/1900339
原文地址：http://guoruilin198.blog.51cto.com/12567311/1900339
