mysql binlog pid_MySQL日志binlog的三种模式

1三种模式的介绍

二进制日志binlog作用：

1、以二进制形式记录更改数据库的SQL语句(insert,update,delete,create,drop,alter等)

2、用于Mysql主从复制

3、增量数据库备份及恢复

1.1Row模式

日志会记录成每一行数据被修改成的形式，然后再slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。

优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关信息，仅仅需要记录哪一条记录被修改了，修改成什么信样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现在某些特定情况下的存储过程和function，以及trigger的调用和处罚无法被正确复制问题。

缺点：在row模式下，所有执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。比如有这样一条update语句：updateproduct set name='gongli'这条语句不是记录的一条，而是修改每一条的都会记录下来

1.2Statement模式

每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端相同的sql再执行。

优点：在Statement模式下首先就是解决了row模式下的缺点，不需要记录记录每一行日志的变化，减少了bin-log日志量，节省了I/O以及存储资源，提高性能。因为它们只需要激励在master上所执行的语句的细节以及执行语句时候的上下文信息。

缺点：在Statement模式下，由于它记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么它还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候的结果。另外，由于MySQL现在发展较快，很多的新功能不断的加入，使MySQL的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在Statement中，目前已经发现不少情况会造成MySQL的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现。比如：sleep()函数在有些版本中就不能直接复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于rowlevel是基于每一行来记录的变化，所以不会出现类似的问题

1.3Mixed模式

从官方文档中看到，之前的MySQL一直都只有基于Statement的复制模式，知道5.1.5版本的MySQL才开始支持row模式。从5.0开始，MySQL的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给MySQL replication又带来了更大的挑战。另外，看到官方文档说，从5.1.8版本开始，MySQL提供了除Statement和row之外的第三种模式：mixed，实际上就是前两种模式的结合。在mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式&