MySql中binlog与redolog的介绍

MySql中binlog与redolog的介绍

在MySQL中有两种重要的日志文件，分别是binlog和redolog。binlog记录的是MySQL所执行的所有的DDL(数据定义)和DML(数据操作)语句，并以二进制的格式进行存储的一种日志文件，是MySQL的server层运行产生的，不具备crash-safe能力；redolog记录的是数据库运行过程中在某个数据页上做了那些修改的，是内存层面的修改，是InnoDB引擎所独有的的日志记录文件。下面分别详细介绍下这两种日志

binlog

binlog在MySQL中主要有两个作用：第一个是数据恢复，当数据库宕机的时候可以根据binlog回放来恢复历史数据；第二个是数据复制，针对多机、多系统的业务，在不同的系统和机器间完成MySQL数据的高可用复制。

binlog中数据记录也有多种不同的模式，每一种模式记录的数据有不同的格式。第一种是Statement模式：这种模式记录的是每一条修改数据的SQL，该模式只保存执行的SQL语句，不涉及到执行的上下文信息，优点是占用的空间比较小，比较适合查询和分析；缺点是可能因为一些特殊函数或者执行顺序的问题造成主备库的数据不一致，比如更新使用now()函数，由于主备库的执行时间不一致，导致主备库的数据不一致（这种情况MySQL已经修复了，使用statement不会出现问题）；另外需要强调的是相同的SQL在主备库上执行可能会使用不同的索引，这在某些特殊情况下也会造成数据不一致。第二种是Row模式，从V5.1.5版本开始支持，记录的是针对每一条SQL语句的执行，内存中每一行记录的变革各自生成记录，这样能有效避免主从下针对同一条sql而产生不同的结果，但是在空间和效率上消耗比较大。第三种是Mixed模式，记录的数据格式混合使用了Statement模式和Row模式，一般的更新语句使用Statement模式来保存 Binlog，但是遇到一些函数操作，可能会影响数据准确性的操作则使用Row模式来保存，综合了前面两种模式的优点。

redo log

redolog是物理日志，记录的是“在某个数据页上做了什么修改”，先写redo log，处于prepare的状态，再写binlog之后一起提交，InnoDB的redolog 是固定大小的,一般是4个大小为1GB的文件，可以自己配置。redo log一般是从头开始写，写到末尾就又回到开头循环写； redolog使InnoDB拥有了crash-safe的能力，能够保证即使数据库发生异常重启，之前提交的记录都不会丢失的能力

其他

为什么需要使用两阶段提交，使用反证法:
1.先提交redolog：对InnoDB引擎来说，如果redolog提交完成了，事务就不能回滚（如果这还允许回滚，就可能覆盖掉别的事务的更新）。而如果redolog直接提交，然后binlog写入的时候失败，InnoDB又回滚不了，数据和binlog日志就不一致了，使用binlog进行数据备份的时候就会造成数据不一致。
2.先提交binlog：当binlog提交之后redolog提交失败了，此时事务回滚了，但是binlog不能回滚，造成了数据库的数据和binlog日志记录的数据不一致，当使用binlog进行数据备份的时候就会造成数据不一致

为什么binlog不支持崩溃恢复
只有binlog不支持崩溃恢复的原因：InnoDB引擎使用的是WAL技术，执行事务的时候，写完内存和日志，事务就算完成了。binlog只是记录的更新的数据，数据是否已经落盘是不知道的。当时日志写完事务已经提交，最终的数据可能还没有落盘，当发生崩溃需要进行恢复的时候，提交事务的binlog会被跳过，导致事务已提交但是数据未落盘的数据会丢失。redolog记录的就是未落盘的数据，所以只有redolog可以保证cras-safe的能力