mysql---binlog格式

binlog的概念和格式、以及row格式的数据

Binlog写入机制

binlog 的写入机制比较简单：事务执行的过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到binlog 文件中。
事务提交的时候，执行器把 binlog cache 里完整事务写入到 binlog 中，并清空 binlog cache。
与binlog持久化有关的配置参数sync_binlog
sync_binlog=0 的时候，表示每次提交事务都只写page cache ,不会持久化到硬盘
sync_binlog=1 的时候，表示每次提交事务之后都会写page cache，并且持久化到硬盘
sync_binlog=N 的时候，表示当积累N次事务之后就会一次性写入硬盘

binlog日志的内容

二进制日志（binlog）中记录了对MySQL数据库执行更改的所有操作，并且记录了语句发生时间、执行时长、操作数据等其它额外信息，但是它不记录select、show等那些不修改数据的SQL语句。

statement 基于SQL语句的复制(statement-based replication, SBR)
每一条会修改数据的sql语句都会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。
然后我们在打开最新的binlog日志，可以在里面找到上面的语句。

但就如同 insert 语句，我使用了 now()，这个函数，如果用这个binlog语句去进行备份、同步那么时间字段就对不上了。
优点：

statement模式下，不需要记录每一行的变化，所以bin-log日志量相对较小，节约IO，提高性能。因为它只需要记录所执行的语句的细节，以及执行语句时的上下文信息。

缺点：

由于它是记录执行语句，为了让这些语句在slave端也能正确执行，它还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，来保证所有语句在slave端能够得到和在master端相同的执行结果。statement模式下，在执行一些不确定的函数（如uuid(),now()）时会出现主从数据不一致问题。

row 基于行的复制(row-based replication, RBR)
不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发或 now() 无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。
优点：

在row模式下，bin_log中不需要记录执行的sql语句的上下文信息，仅仅只需要记录哪一条记录被修改，修改成什么样，所以日志内容会非常清楚的记录每一行数据修改的细节。

缺点：

row模式下，所有的执行语句都会记录到日志中，同时都会以每行记录修改的来记录，这样生成的日志内容将会非常大，占用空间。
mixed 混合模式复制(mixed-based replication, MBR)
以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。


binlog数据样子：
unpdate，语句在binlog的row格式中是记下了update时候每一个字段的前后值；
即：语句：update table set a=x where id=1;
binlog:update table set a=x,b=x,c=x ,id=x where a=y,b=y,c=y ,id=y,;
delete，语句在binlog的row格式中是记下了delete时候每一个字段的前后值；和update同理

binlog恢复数据

恢复案例
恢复案例2
恢复数据案例3
是在正式环境，很可能binlog的记录并不是从头到尾的所有sql，所以就需要和全量备份配合使用，数据恢复期间，最好停止外界对数据库的访问，避免数据错误的出现。

恢复数据的方式：
本质是挑选binlog中需要重新执行的sql，执行一遍；因此数据库中如果没有数据，执行binlog中的update自然不会恢复；
但是对delete，是怎么追踪回来的呢？

1. 用最近的全量备份，然后在加上全量备份时间点后的binlog日志，然后先还原全量备份，在通过命令把binlog执行掉，这样数据就能还原了，这种方法，不限binlog的日志格式，ROW或者MIXED都行。但是随着业务量增大，可能单次还原数据库和执行binlog需要很长时间。
2. 只用binlog日志，将binlog日志解析出来,生成反向原始sql，然后执行还原数据，这种方式binlog日志格式需要是ROW

因此没有binlog中没有涉及到的记录数据不会变化；
binlog中被删除的数据，找到其删除前到inert时之间的binlog恢复即可；
binlog中被修改的数据，找到其修改前的binlog恢复