MYSQL备份恢复知识：第三章：数据日志

数据库的日志有两种，一是系统日志，例如alert.log等，记录了数据库的运行情况，不包括任何用户数据，用于排错等运维工作；另外一种是数据日志，记录的是数据内容，比如什么时间往哪个表里写了什么数据。数据日志，是备份需要关注的内容。
• MySQL由两套日志并行使用：

• BINARY LOG
  基于数据库服务层的日志，采用WAL机制，用于数据库复制和增量备份
• REDO LOG（transaction log)
  基于INNODB数据引擎的日志，设计目的为Crash Recovery
  • 在INNODB架构，是目前的主流也是推荐架构，使用BINLOG和REDO LOG共同完成备份；在非INNODB架构，如MyISAM架构，仅有BINLOG。
  • Binary log与Redo log组合，功能与Oracle Redo Log相同，由于产品发展历史原因，无法进行整合。

1. REDO

Redo Log的设计目的主要是crash recovery，在数据库意外停机恢复后，需要通过日志来恢复一致性。在非一致性备份中，redo log可用来保证一致性恢复。Redo Log中记录了LSN（Log Sequence Number）和XID（Transaction ID），LSN用于验证一致性，而XID可以与BINLOG对应。日志记录InnoDB引擎的变化，是数据块级的，采用循环使用方法。在旧版本中，默认为两个文件，在DATADIR下，分别为ib_logfile0和ib_logfile1，文件默认大小50M。可通过my.cnf配置中的参数添加文件数量和修改文件大小。在新版本中，定义innodb_redo_log_capacity参数，值为REDO日志的总量大小。REDO日志的默认保存在DATA/#innodb_redo中，创建32个文件，平均分配了日志的总量。例如，innodb_redo_log_capacity参数设置为8G，#innodb_redo目录中的32个文件大小均为256M。32个文件循环使用，当文件全部使用完毕后，最旧的文件被清空并重复使用。
由于采用了循环使用方法，因此日志中的数据保存周期较短。如果备份持续时间较长，日志内容被覆盖，恢复时无法保证一致性。有两种解决方法，一是通过配置增加日志问题大小来避免覆盖；二是利用归档功能，在备份期间将所有REDO在指定的路径中进行单独的保存。需要注意的是，归档不是持续的，在备份开始时启用归档功能，备份结束时关闭。MEB和xtrabackup软件可自动调用归档功能。
配置归档，设置归档文件路径：

mysql> set global innodb_redo_log_archive_dirs='arch1:/mysql/mysql-server/arch'; 

–arch1为标识，/mysql/mysql-server/arch目录为归档文件保存的路径
也可以设置多个归档路径，使用分号分割：

mysql> set global innodb_redo_log_archive_dirs='arch1:/mysql/mysql-server/arch;arch2:/mysql/mysql-server/arch2';

查看归档设置：

归档配置后并没有启用，需要在备份前手工开启：

mysql> select innodb_redo_log_archive_start('arch1','20250410001');

arch1为配置归档的标识，第二个字段为arch1对应的归档路径下的子目录.如果子目录为空，在arch1路径下生成。生成的文件名格式如，
archive.1026d0c1-0c88-11f0-a5b9-0800276f73f9.000001.log
备份数据文件结束后，停止归档：

mysql> select innodb_redo_log_archive_stop();

2. BINARY

日志包含表创建操作或表中数据的变化，也记录了语句修改数据消耗的时间。在复制和XA Transaction场景下，BINARY日志是必须的。日志有两个重要的用途：
• 在复制场景中，源端数据库记录了数据变化并发送到目标端；
• 两段式提交协议中，与redo日志协同校验；
• 数据恢复操作。备份数据被恢复后，备份生成时间后的记录保存在BIN日志中，会被重新执行，使数据恢复到最新的时间点。
BIN日志会在很小的程度上降低数据库的性能 ，但是它带来的好处远大于对性能的负面影响。BIN日志能够应对非计划中断，完成的事件或交易被记录在日志中。
BIN是一系列连续的文件，当下列事件发生时系统自动创建新的文件：
• 数据库启动
• 对日志进行FLUSH操作
• 日志文件达到最大限制。但是日志文件也可能超出最大限制。当一个大的交易执行时，要保存在一个日志文件中包括所有的记录，不能跨越两个文件。

日志默认保存在DATADIR中，文件名格式为binlog.xxxxxx，可以在my.cnf配置文件中通过log_bin指定不同的位置和文件名格式。在相同的目录下，日志文件写满后，自动生产一个新的文件，旧文件保存至binlog_expire_logs_seconds参数指定的时间到达，或者通过purge命令手动删除。在日志相同的路径下，还有一个索引文件binlog.index，记录了当前哪些日志文件被使用。
Binary日志，顾名思义，因此无法直接阅读。通过MySQL内置工具mysqlbinlog，可将binary日志转换成ASCII文本，便于阅读。

$ mysqlbinlog -v binlog.000028 > 28.sql

文件内容如，

这里有一个非常关键的概念，log position。例如上面的例子中，“at 371”，这个事件开始于log position 371，结束于log position 448，事件为写入数据。下一个事件，开始于448，结束于479，是之前写数据事件的提交事件。利用log position，可以更精确的定位binary日志中的事件。例如，

$ mysqlbinlog -v binlog.000028 --start-position=1529 --stop-position=2602

3. RELAY

仅在数据库复制的目标端存在，接收从源端传输过来的数据，格式与BIN日志相同。数据库master节点，通过I/O Thread将binlog日志发送到replica节点，生成Relay Log。在同步模式下，Replica节点的Relay Log与Master节点的BINLOG保持一致。异步模式下，两者会有一定差距。SQL Thread进程对Relay Log进行Apply，生成Replica节点的BINLOG，并写入数据文件。
RELAY日志的默认保存位置为DATADIR，文件名格式为$hostname-relay-bin.xxxxxx，索引文件名格式为$hostname-relay-bin.index，可通过relay-log和relay-log-index参数来修改。

4. UNDO

UNDO日志中记录了如何撤销最后的交易的信息，用于回滚。UNDO日志默认有两个，名为UNDO_001和UNDO_002，保存在DATADIR中。可以使用innodb_undo_directory参数修改保存位置，使用innodb_undo_tablespaces设置UNDO文件的数量。

CSDN视频课程：

https://edu.csdn.net/lecturer/8135?spm=1002.2001.3001.4144