Thresh

Binlog 记录模式

Redo Log 是属于 InnoDB 引擎所特有的日志，而 MySQL Server 也有本人的日志，即 Binary log（二进制日志），简称 Binlog。

Binlog 是记录所有数据库表构造变更以及表数据批改的二进制日志，不会记录 SELECT 和 SHOW 这类操作。

Binlog 日志是以事件模式记录，还蕴含语句所执行的耗费工夫。

开启 Binlog 日志有以下两个最重要的应用场景。

主从复制：在主库中开启 Binlog 性能，这样主库就能够把 Binlog 传递给从库，从库拿到 Binlog 后实现数据恢复达到主从数据一致性。数据恢复：通过 mysqlbinlog 工具来复原数据。

Binlog 文件名默认为“主机名_binlog- 序列号”格局，例如 oak_binlog-000001，也能够在配置文件中指定名称。

文件记录模式有 STATEMENT、ROW 和 MIXED 三种，具体含意如下。

• ROW（row-based replication, RBR）

日志中会记录每一行数据被批改的状况，而后在 slave 端对雷同的数据进行批改。

长处：能分明记录每一个行数据的批改细节，能齐全实现主从数据同步和数据的复原。毛病：批量操作，会产生大量的日志，尤其是 alter table 会让日志暴涨。

• STATMENT（statement-based replication, SBR）

每一条被批改数据的 SQL 都会记录到 master 的 Binlog 中，slave 在复制的时候 SQL 过程会解析成和原来 master 端执行过的雷同的 SQL 再次执行。简称 SQL 语句复制。

长处：日志量小，缩小磁盘 IO，晋升存储和复原速度
毛病：在某些状况下会导致主从数据不统一，比方 last_insert_id()、now()等函数。

• MIXED（mixed-based replication, MBR）

以上两种模式的混合应用，个别会应用 STATEMENT 模式保留 binlog，对于 STATEMENT 模式无奈复制的操作应用 ROW 模式保留 binlog，MySQL 会依据执行的 SQL 语句抉择写入模式。

Binlog 写入机制

罕用的 log event 有：Query event、Row event、Xid event 等。binlog 文件的内容就是各种 Log event 的汇合。

• 依据记录模式和操作触发 event 事件生成 log event（事件触发执行机制）
• 将事务执行过程中产生 log event 写入缓冲区，每个事务线程都有一个缓冲区

Log Event 保留在一个 binlog_cache_mngr 数据结构中，在该构造中有两个缓冲区，一个是 stmt_cache，用于寄存不反对事务的信息；另一个是 trx_cache，用于寄存反对事务的信息。

• 事务在提交阶段会将产生的 log event 写入到内部 binlog 文件中。

不同事务以串行形式将 log event 写入 binlog 文件中，所以一个事务蕴含的 log event 信息在 binlog 文件中是间断的，两头不会插入其余事务的 log event。

Binlog 文件操作

Binlog 状态查看

show variables like 'log_bin';

开启 Binlog 性能
须要批改 my.cnf 或 my.ini 配置文件，在 [mysqld] 上面减少 log_bin=mysql_bin_log，重启 MySQL 服务。

#log-bin=ON 
#log-bin-basename=mysqlbinlog 
binlog-format=ROW 
log-bin=mysqlbinlog

执行开启语句

set global log_bin=mysqllogbin;

应用 show binlog events 命令

show binary logs; // 等价于 show master logs; 
show master status; 
show binlog events; 
show binlog events in 'mysqlbinlog.000001'\G;
后果:
     Log_name: mysql_bin.000001   // 此条 log 存在那个文件中
        Pos: 174                 //log 在 bin-log 中的开始地位 
     Event_type: Intvar          //log 的类型信息 
        Server_id: 1  // 能够查看配置中的 server_id, 示意 log 是那个服务器产生 
     End_log_pos: 202          //log 在 bin-log 中的完结地位 
        Info: INSERT_ID=2    //log 的一些备注信息，能够直观的看出进行了什么操作 

能够用 mysql 自带的工具 mysqlbinlog

mysqlbinlog "文件名" mysqlbinlog "文件名" > "文件名比方:test.sql"

应用 binlog 复原数据

// 按指定工夫复原 
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop-datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234 
// 按事件地位号复原 
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234

mysqldump：定期全副备份数据库数据。mysqlbinlog: 能够做增量备份和复原操作。

删除 Binlog 文件

purge binary logs to 'mysqlbinlog.000001'; // 删除指定文件 
purge binary logs before '2020-04-28 00:00:00'; // 删除指定工夫之前的文件 
reset master; // 革除所有文件

能够通过设置 expire_logs_days 参数来启动主动清理性能。默认值为 0 示意没启用。设置为 1 示意超出 1 天 binlog 文件会主动删除掉

Redo Log 和 Binlog 区别

• Redo Log 是属于 InnoDB 引擎性能，Binlog 是属于 MySQL Server 自带性能，并且是以二进制文件记录。
• Redo Log 属于物理日志，记录该数据页更新状态内容，Binlog 是逻辑日志，记录更新过程。
• Redo Log 日志是循环写，日志空间大小是固定，Binlog 是追加写入，写完一个写下一个，不会笼罩应用。
• Redo Log 作为服务器异样宕机后事务数据主动复原应用，Binlog 能够作为主从复制和数据恢复应用。Binlog 没有主动 crash-safe 能力。

(crash-safe 即在 InnoDB 存储引擎中，事务提交过程中任何阶段，MySQL 忽然奔溃，重启后都能保障事务的完整性，已提交的数据不会失落，未提交残缺的数据会主动进行回滚。这个能力依赖的就是 redo log 和 unod log 两个日志。)