1 简介

答案很简单，使用数据库日志，那么使用哪一种？

mysql自带的mysqlbinlog工具的作用是解析mysql的二进制binlog日志内容，把二进制日志解析成可以在MySQL数据库里执行的SQL语句。

binlog日志原始数据是以二进制形式存在的，需要使用mysqlbinlog工具转换成SQL语句形式。

mysql的binlog日志作用是用来记录mysql内部增删改等对mysql数据库有更新内容的记录（对数据库进行改动的操作）。

对数据库查询的语句如show，select开头的语句，不会被binlog日志记录，主要用于数据库的主从复制与及增量恢复。

2 三个模式

3种binlog日志模式：

• 基于 SQL 语句的复制:

  每一条更新的语句 (insert、update、delete)都会记录在 binlog 中，进而同步到从库的 relaylog 中，被从库的 SQL 线程取出来，回放执行。

优点是 binlog 的志量可能会比较少，
比如一个涉及行数为 1000 行的 update 语句，同步这一个语句，就同步了 1000行的数据。

缺点是同步的 SQL 语句里如果含有绑定本地变量的函数、关键字时，可能造成主从不一致的情况。
比如 SQL 语句中有 time 函数，如果主从数据库的服务器时间不是精确相等，就会造成结果不一致。

• 基于行的复制:

不记录 SQL 语句，只记录了哪个记录更新前和更新后的数据，可以保证主从之间数据绝对相同。

缺点是:1条 SQL 更新 1000行的数据无法再偷懒，必须原原本本同步 1000 行的数据量

• 混合复制:

以上两种模式的混合，选取两者的优点。对于有绑定本地特性、评估可能造成主从不一致的 SQL 语句，

自动选用基于行的复制其他的选择基于 SQL 语句的复制读写分离:

设置不同的主/从数据库分别负责不同的操作，让主数据库负责数据的写操作，从数据库负责数据的读操作，通过角色分担的策略，分别提升读写性能，有效减少数据并发操作的延迟，

• 分表:

分表，也叫分片，可以提升数据库并发以及 I/O 的性能。分表重在单个实例内部，将一张大表分成若干小表，业务同时访问多个表。

• 分库:

分库是将原本存放在一个实例上众多分类的数据(表) ，分开存放到不同的实例上。有利于差异化管理

3 常用binlog查看方式

• 查询是否开启binlog

  SHOW VARIABLES like ‘log_%’;

返回：

# Variable_name, Value
'log_bin', 'ON'

• 查看mysql的 binlog 模式

  show global variables like “binlog%”;

返回：

# Variable_name, Value
'binlog_annotate_row_events', 'ON'
'binlog_cache_size', '32768'
'binlog_checksum', 'CRC32'
'binlog_commit_wait_count', '0'
'binlog_commit_wait_usec', '100000'
'binlog_direct_non_transactional_updates', 'OFF'
'binlog_file_cache_size', '16384'
'binlog_format', 'MIXED'
'binlog_optimize_thread_scheduling', 'ON'
'binlog_row_image', 'FULL'
'binlog_stmt_cache_size', '32768'

其中，‘binlog_format’, ‘MIXED’ MIXED 即是 混合复制 模式。

查看日志开启状态 完整的信息

	SHOW VARIABLES like 'log_%';

查binlog日志列表

	show master logs

查看最新一个binlog日志的编号名称，及其最后一个操作事件结束点

	# File, Position, Binlog_Do_DB, Binlog_Ignore_DB
	'mysql-bin.000006', '844074', '', ''

刷新log日志，立刻产生一个新编号的binlog日志文件，跟重启一个效果

	flush logs

清空所有binlog日志

	reset master

使用mysql自带工具打开binlog文件，将二进制文件转换为可读sql语句

	mysqlbinlog mysql-bin.000006

或者 不使用默认字符

   mysqlbinlog --no-defaults mysql-bin.000001

binlog查询指令

	show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

IN ： ‘log_name’ 指定要查询的binlog文件名(不指定就是第一个binlog文件)

FROM pos ： 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)

LIMIT [offset,] ： 偏移量(不指定就是0)

row_count ： 查询总条数(不指定就是所有行)

4 启用和恢复的方式

开启binlog

修改文件： /etc/my.cnf

1 第一种方式:

• 开启binlog日志

    log_bin = ON
  

• binlog日志的基本文件名

    log_bin_basename = /var/lib/mysql/mysqlbinlog
  

• binlog文件的索引文件，管理所有binlog文件

    log_bin_index = /var/lib/mysql/mysql-bin.index
  

• 配置serverid

    server-id = 1
  

• 设置字符格式

    default-character-set=utf8
    改为：
    character-set-server = utf8
  

2 方式二：

• 设置log_bin

此一行等同于上面log_bin三行,这里可以写绝对路径,也可以直接写mysql-bin(后者默认就是在/var/lib/mysql目录下)

       log_bin = /var/lib/mysql/mysqlbinlog

• 配置serverid

    server-id = 1
  

3 简单设置：

    log-bin = /data/3336/mysql-bin  
	binlog_format="STATEMENT"  
	#binlog_format="ROW"  
	#binlog_format="MIXED" 

不重启，使配置在msyql中生效

	SET global binlog_format='STATEMENT';

5 小结

在对数据库进行定时备份时，只能备份到某个时间点，假如在凌晨0点进行全备了，但是在中午12点出现故障需要恢复数据，定时备份0点以后的数据就只能丢失吗？

这时就是体现binlog日志重要性的时候了，当我们对binlog日志进行定时推送（一分钟一次或五分钟一次，时间频率视业务场景而定）就完成增量备份。

当出现故障时，可以使用定时备份和增量备份恢复到故障点时刻的数据。
具体的恢复方案，后续章节再进行介绍。