binlog——逻辑复制的基础
Ⅰ、binlog定义和作用
1.1 定义
记录每次数据库的逻辑操作(包括表结构变更和表数据修改)
包含：binlog文件和index文件
1.2 作用
- 复制：从库读取主库binlog,本地回放实现复制
- 备份恢复：最近逻辑备份数据+binlog实现最大可能恢复
- innodb恢复：开启binlog的情况下,innodb事务提交是二阶段提交,发生crash的时候,innodb中事务有两种状态,一种是commit,一种是prepared,对于prepared状态的事务需要根据binlog来判断是提交还是回滚,以此来保证主从数据一致性
Ⅱ、不同类型binlog对比
| - | statement | row | mixed |
|---|---|---|---|
| 说明 | 记录操作的SQL语句 | 记录每一行数据的变更 | 混合模式 |
| 优点 | 易于理解 | 数据一致性高、可flashback | 综合上述两种模式 |
| 缺点 | 不支持不确定SQL语句 | 每张表一定要有主键 | 之前版本bug比较多 |
| 线上使用 | 不推荐 | 推荐 | 不推荐 |
再说一遍row
- 优点：记录每一行记录变化,确保证主从数据严格一致性
- 缺点：全表update,delete全表时binlog文件大,所以不建议用MySQL做类似操作
调成statement看,会发现记录的是sql语句,不说太多,线上基本上不会用
写入数据量很大时,ROW格式下,commit会比较耗时间,因为他还要写binlog（ binlog在提交时才写入 ）
假设更新一张几百万的表,产生的binlog可能会有几百兆,当commit时,写入的数据量就是几百兆,所以会有“阻塞”等待的效果。但其实是在写binlog到磁盘
Ⅲ、相关参数及使用命令
log_bin=bin 默认不打开,和oracle一样,不管事务大小,提交速度都一样)
log_bin_basename 设置binlog名,不设置默认为机器名,直接用上面的log_bin=bin也表示二进制文件以bin开头
binlog_format 之前为statement,5.6有几个小版本用的mixed,5.7开始默认row了
max_binlog_size 限定单个binlog文件大小,默认1G
binlog_do_db
binlog_ignore_db binlog过滤
sync_binlog 默认是0,binlog文件每次写入内容不会立刻持久化到磁盘,具体持久化是交给操作系统做,固系统崩溃会导致binlog的丢失和不一致,建议设置为1,事务写入到binlog后立即fsync到磁盘
flush binary logs; 新生成一个binlog
show master status; 查看当前的binlog
tips:
①bin.999999满了之后怎么办？ 前面加1位
②binlog文件可能大于max_binlog_size,原因是一个事务产生的所有事件必须记录在同一个binlog中
Ⅳ、binlog内容
4.1 index文件
有序地记录了当前MySQL服务所使用的所用binlog文件
MySQL运行过程中千万不要骚操作修改index文件,避免出问题
4.2 binlog文件
执行show binlog events in 'xxx'；
查看binlog文件内容,不指定文件默认看第一个binlog文件
(root@localhost) [test]> show binlog events;
+------------+------+----------------+-----------+-------------+--------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------+------+----------------+-----------+-------------+--------------------------------------------------+
| bin.000001 | 4 | Format_desc | 3 | 123 | Server ver: 5.7.18-log, Binlog ver: 4 |
| bin.000001 | 123 | Previous_gtids | 3 | 154 | |
| bin.000001 | 154 | Anonymous_Gtid | 3 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 219 | Query | 3 | 313 | create database test |
| bin.000001 | 313 | Anonymous_Gtid | 3 | 378 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 378 | Query | 3 | 474 | use `test`; create table a (a int) |
| bin.000001 | 474 | Anonymous_Gtid | 3 | 539 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 539 | Query | 3 | 649 | use `test`; create table b (b int) engine=myisam |
| bin.000001 | 649 | Anonymous_Gtid | 3 | 714 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 714 | Query | 3 | 786 | BEGIN |
| bin.000001 | 786 | Table_map | 3 | 830 | table_id: 219 (test.a) |
| bin.000001 | 830 | Write_rows | 3 | 870 | table_id: 219 flags: STMT_END_F |
| bin.000001 | 870 | Xid | 3 | 901 | COMMIT /* xid=18 */ |
| bin.000001 | 901 | Anonymous_Gtid | 3 | 966 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 966 | Query | 3 | 1038 | BEGIN |
| bin.000001 | 1038 | Table_map | 3 | 1082 | table_id: 219 (test.a) |
| bin.000001 | 1082 | Update_rows | 3 | 1128 | table_id: 219 flags: STMT_END_F |
| bin.000001 | 1128 | Xid | 3 | 1159 | COMMIT /* xid=21 */ |
| bin.000001 | 1159 | Anonymous_Gtid | 3 | 1224 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| bin.000001 | 1224 | Query | 3 | 1296 | BEGIN |
| bin.000001 | 1296 | Table_map | 3 | 1340 | table_id: 219 (test.a) |
| bin.000001 | 1340 | Delete_rows | 3 | 1380 | table_id: 219 flags: STMT_END_F |
| bin.000001 | 1380 | Xid | 3 | 1411 | COMMIT /* xid=22 */ |
| bin.000001 | 1411 | Rotate | 3 | 1452 | bin.000002;pos=4 |
+------------+------+----------------+-----------+-------------+--------------------------------------------------+
24 rows in set (0.00 sec)
由此可见,binlog是由各类event组成,下面分析下event相关内容
| field | 含义 |
|---|---|
| (Log_name,Pos) | 一个event开始的位置信息 |
| End_log_pos | 一个event结束的位置信息 |
| Event_type | event类型 |
①End_log_pos - Pos = 每个event占用的字节数
②show master status; Position就代表binlog写到这个偏移量的地方,也就是写了这么多字节,即当前binlog文件的大小
③每个binlog前四个字节保留,不写数据
4.3 Event类型分析
| Event_type | 含义 |
|---|---|
| Format_desc | 一个binlog文件开始,记录server的版本号和二进制日志的版本号,5.7版本固定占119个字节 |
| Previous_gtids/Anonymous_Gtid | 5.7版本加进来的gtid |
| Query | 开始一个sql语句 |
| Table_map | 操作的哪个库表 |
| Write_rows | 插入某条记录,具体看不到 |
| Delete_rows | 删除某条记录 |
| Update_rows | 更新某条记录 |
| Xid | 事务提交,可以看到事务号 |
| Rotate | 一个binlog文件结束,指向下一个event的起始位置（bin.xxx;pos=4） |
再强调,row记录的是每条记录的情况(每次操作的每个记录记下来),而不是sql语句
Ⅴ、mysqlbinlog工具的使用
5.1 解析binlog
1、[root@VM_0_5_centos src]# mysqlbinlog bin.000001
截取一段：
# at 1224
#171107 10:17:31 server id 3 end_log_pos 1296 CRC32 0xd4d80fa6 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1510021051/*!*/;
BEGIN
/*!*/;
# at 1296
#171107 10:17:31 server id 3 end_log_pos 1340 CRC32 0x73b187fa Table_map: `test`.`a` mapped to number 219
# at 1340
#171107 10:17:31 server id 3 end_log_pos 1380 CRC32 0x2e637fcd Delete_rows: table id 219 flags: STMT_END_F
BINLOG '
uxcBWhMDAAAALAAAADwFAAAAANsAAAAAAAEABHRlc3QAAWEAAQMAAfqHsXM=
uxcBWiADAAAAKAAAAGQFAAAAANsAAAAAAAEAAgAB//4CAAAAzX9jLg==
'/*!*/;
# at 1380
#171107 10:17:31 server id 3 end_log_pos 1411 CRC32 0x2a6353fd Xid = 22
COMMIT/*!*/;
这个解析出来at xxx什么的可以跟前面直接show binlog events对应起来,但是dml的内容有点小难懂,原因是为了方便传输解析出来的每行记录的内容被base64转换了
tips:
mysqlbinlog --base64-output=never xxx 非row格式下只看ddl,加密的dml不显示
2、[root@VM_0_5_centos src]# mysqlbinlog --base64-output=decode-rows -v bin.000001
row格式下可以将密文转为伪sql
同样截取一段
# at 966
#171107 10:17:23 server id 3 end_log_pos 1038 CRC32 0x00be64e0 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1510021043/*!*/;
BEGIN
/*!*/;
# at 1038
#171107 10:17:23 server id 3 end_log_pos 1082 CRC32 0x5286fd55 Table_map: `test`.`a` mapped to number 219
# at 1082
#171107 10:17:23 server id 3 end_log_pos 1128 CRC32 0x1ed2714c Update_rows: table id 219 flags: STMT_END_F
### UPDATE `test`.`a`
### WHERE
### @1=1
### SET
### @1=2
# at 1128
#171107 10:17:23 server id 3 end_log_pos 1159 CRC32 0xa254d40a Xid = 21
COMMIT/*!*/;
# at 1159
#171107 10:17:31 server id 3 end_log_pos 1224 CRC32 0x76a7413c Anonymous_GTID last_committed=5 sequence_number=6
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
看到的是每行记录的内容,@n表示第几列
切记这搞出来的绝对不是sql语句哈,他只管你一行记录的内容,不管你的sql
tips:
-vv 可以看到更详细内容,比如每个列的类型和属性,通常一个v够看
insert和delete记录一整行记录
update记录前项和后项。全表更新会导致二进制日志特别大
问题:
binlog_format设为row,只知道变化,不知道sql语句,这咋办？
解决:
设置参数binlog_rows_query_log_events=1 建议打开
再去看binlog的events,会多一个叫Rows_query的event,它会记录下改变行内容的sql
5.2 常用参数
- 根据时间点解析
--start-datetime='xxx-xx-xx xx:xx:xx'
--stop-datetime='xxx-xx-xx xx:xx:xx'
- 根据二进制偏移量解析
--start-position=xxx
tips:
这是从xxx来解析,那从xxx+1开始呢？会报error,从这边开始读出来不是一个完整的event,xxx-1开始也是报错,读的时候,每个evnet都有个header,如果不是标准位置就会报错
ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 16640, event_type: 90
ERROR: Could not read entry at offset 1158: Error in log format or read error.
--stop-position=xxx
到xxx结束,并不包含xxx这个点
特殊情况：如果指向了一个Table_map的events,会抛出了一个warning
WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.
通常通过datetime找position,再来进行恢复
Ⅵ、通过mysqlbinlog恢复数据
mysqlbinlog binlog.00003 |mysql -S /tmp/mysql.sock -f
-f强制跳过错误
只恢复某一段,就加上--start-position或者--start-datetime等
官方文档：
如果存在多个二进制日志,并不建议一个一个恢复,而是用下面这个方法
mysqlbinlog binlog.[0-9]* |mysql -u root -p
一个一个恢复会报danger
说明：
如果分两次操作,会被认为在两个session中操作,如果刚好用到一个临时表,一个session退出了,另一个session上去就出错了
另一种方法：
mysqlbinlog binlog.000001 > /tmp/statements.sql
mysqlbinlog binlog.000002 >> /tmp/statements.sql
mysql -u root -p -e "source /tmp/statements.sql"
Ⅶ、清理binlog
这里介绍三种清理binlog的方法：
法1：purge
purge binary logs to 'xxx';
清理xxxbinlog文件之前的内容
purge binary logs before 'xxx'
清理xxx日期之前的内容
法2：rm
step1：MySQL停止服务
step2：按顺序rm掉binlog文件
step3：编辑index文件,将rm掉的binlog文件从index中去掉
法3：配自动清理参数
[mysqld]
expire_logs_days=N
表示只保存N天的binlog,默认值是0,表示不删除
实现原理：
当binlog文件切换或者mysql服务启动时,遍历index文件,找到第一个"最后修改时间在N天之内的文件",然后将该文件之前的所有binlog全部删除
Ⅷ、其他相关问题
8.1 增量备份怎么做
通常MySQL不做增量备份,除非单点,因为MySQL复制本身就是实时在做增量,从库开binlog,在从库上备份binlog即可(flush binary logs;产生新日志,把之前的存下来)
Oracle增量备份还是有用的,万一page发生crash,需要把所有日志重做一遍
8.2 row格式的binlog回放
一个sql插了3条记录,其实插了3次,对应3个write_rows,解析这个东西,变相执行3个sql
一个sql删了3条记录,对应的单个delete_rows,回放的时候先根据主键回放,没有主键就找一个索引来回放,如果一个索引没有,会scan全表
如果表中有10w条记录,一个索引没有,你去删全表的话,每条记录删的时候都会扫10w次,复杂度是O(10w^2)次,但因为记录越来越少,最后会扫描10w + （10w * 10w-1）/2 次,所以为什么每张表必须要有主键,这里又是一种体现,有主键回放速度会快很多,特别是delete和update
注意：没主键是不要扯什么row_id,binlog是server层的东西,和row_id没关系
tips:
①MySQL5.6推出下面这个参数来指定scan算法可以部分解决无主键表导致的复制延迟问题,其基本思路是对于在一个ROWS EVENT中的所有前镜像收集起来,然后在一次扫描全表时,判断HASH中的每一条记录进行更新
slave_rows_search_algorithms,默认值是table_scan,index_scan,另一个hash_scan可配,默认没开,也不建议用,因为创建hash表消耗比较大
②当使用innodb表时,使用rc时即使my.cnf中用的其他格式binlog也会被强制转为row
8.3 flash back
二进制日志能实现一个非常好的功能,用来挽救数据,实现flash back,oracle中还要用到undo
对于insert的event,如果要flash back,就搞成delete,delete搞成insert,update交换前后项即可
听说8.0会支持这个工具,但是现在每家互联网公司都开源自己的工具,实现flashback,但是一定要用row格式的binlog_format
8.4 binlog_cache
binlog默认写入binlog_cache中
binlog生成的过程
| 步骤 | 操作 |
|---|---|
| 1 | binlog被write到各session对应的文件句柄缓存中,也就是标准io缓存 |
| 2 | binlog从每个session私有的缓存中flush到公共缓存中,即操作系统缓存中 |
| 3 | binlog从内存中sync到文件系统,持久化 |
第一步session之间互相看不到
第二步每个session之间互相可以看到
在这之前只要机器发生crash,则日志就相对应的丢失了
特殊情况：遇到大事务时,binlog很大,cache放不下就会落盘
(root@172.16.0.10) [(none)]> show global status like 'binlog_cache%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 0 | -- 记录使用临时文件记录binlog日志的次数(监控项)
| Binlog_cache_use | 1 | -- 记录使用缓冲写binlog日志的次数
+-----------------------+-------+
2 rows in set (0.01 sec)
(root@172.16.0.10) [(none)]> show variables like 'binlog_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| binlog_cache_size | 32768 |
+-------------------+-------+
1 row in set (0.00 sec)
默认为32K,sessioin级的内存变量,勿设置太大
- cache写不下落盘,然后再写binlog,就是两次写磁盘,这样会变慢。若如果参数Binlog_cache_disk_use次数很多,须考虑调大binlog_cache_size,或者检查业务中是否存在大事务(oltp场景尽量大事务拆小事务)
