逻辑日志与物理日志 - 版本历史

Eijux：/* 数据引擎层的 redo log/undo log */

2021-04-27T14:00:02Z

数据引擎层的 redo log/undo log

←上一版本		2021年4月27日 (二) 22:00的版本
第186行：		第186行：

	==== 数据引擎层的 '''redo log/undo log''' ====		==== 数据引擎层的 '''redo log/undo log''' ====
	MySQL 的 InnoDB 存储引擎使用 '''redo log''' 以及 '''undo log'''，它们属于'''“Physiological Logging”'''~~，虽然很多人认为其属于物理日志。【！！！】~~		MySQL 的 InnoDB 存储引擎使用 '''redo log''' 以及 '''undo log'''，它们属于'''“Physiological Logging”'''，虽然很多人认为其属于物理日志。【？？？undo log 不是逻辑日志吗？？？】

Eijux：/* 数据引擎层的 redo log/undo log */

2021-04-27T13:57:44Z

数据引擎层的 redo log/undo log

←上一版本		2021年4月27日 (二) 21:57的版本
第189行：		第189行：


	MySQL InnoDB 的 redo log ~~可以分为三种类型：~~		MySQL InnoDB 的 redo log 可以分为三种类型：【？？？】
	# 作用于 ~~Page，【？？？】~~		# 作用于 Page，
	# 作用于 ~~Space，【？？？】~~		# 作用于 Space，
	# 以及提供额外信息的 Logic ~~类型。【？？？】~~		# 以及提供额外信息的 Logic 类型。


	以“作用于Page”的 redo log 的格式为例：		以“作用于Page”的 redo log 的格式为例：
	: [[File:“作用于Page”的 redo log 的格式.png\|~~400px~~]]		: [[File:“作用于Page”的 redo log 的格式.png\|700px]]


	可见，MySQL 的 redo log 属于“Physiological ~~Logging”：~~		可见，MySQL 的 redo log 属于“Physiological Logging”：【！！！】
	# ~~物理上，其使用 Page Number~~ + ~~Record Offset 来指定具体作用于哪一个~~ page 上的一条记录。		# 物理：使用“Page Number”+“Record Offset”来指定具体作用于哪一个 page 上的一条记录。
	# ~~逻辑上，使用 Field Number（Field编号）来说明更新操作作用于哪些字段；~~		# 逻辑：使用“Field Number”（Field编号）来说明更新操作作用于哪些字段；

	=== Redis【？？？】 ===		=== Redis【？？？】 ===

Eijux：/* server 层的 bin log */

2021-04-27T13:53:38Z

server 层的 bin log

←上一版本		2021年4月27日 (二) 21:53的版本
第176行：		第176行：


	无论是 SQL 更新语句还是行上具体某个修改，都是逻辑日志，因为都没有涉及在具体哪一个 page 上进行修改。		'''无论是 SQL 更新语句还是行上具体某个修改，都是逻辑日志，因为都没有涉及在具体哪一个 page 上进行修改。'''

Eijux：/* server 层的 bin log */

2021-04-27T13:53:06Z

server 层的 bin log

←上一版本		2021年4月27日 (二) 21:53的版本
第174行：		第174行：
	#** 数据量相比基于语句的 binlog 要大很多，在备份与恢复上性能较差；		#** 数据量相比基于语句的 binlog 要大很多，在备份与恢复上性能较差；
	#** 丢失了原有 SQL 更新语句，不利于复盘；		#** 丢失了原有 SQL 更新语句，不利于复盘；
	#**

Eijux：/* server 层的 bin log */

2021-04-27T13:52:55Z

server 层的 bin log

←上一版本		2021年4月27日 (二) 21:52的版本
第162行：		第162行：
	#** 数据更少，即使一个更新操作会影响非常多的行。		#** 数据更少，即使一个更新操作会影响非常多的行。
	#** 包括任何更新语句，因此可以用于数据库维护人员维护数据库；		#** 包括任何更新语句，因此可以用于数据库维护人员维护数据库；
	#* 缺点：并非所有 SQL ~~语句的执行效果都支持基于语句的复制。例如调动一个函数~~ now() 来获取系统时间，在不同的机器、时间上重放日志将得到不同的结果；		#* 缺点：并非所有 SQL 语句的执行效果都支持基于语句的复制。
			#*: 例如调动一个函数 now() 来获取系统时间，在不同的机器、时间上重放日志将得到不同的结果；
	# '''基于行'''的日志记录（Row-based logging）：主要记录了对单个行的修改，其在 MySQL 5.1.5 后引入；		# '''基于行'''的日志记录（Row-based logging）：主要记录了对单个行的修改，其在 MySQL 5.1.5 后引入；
	#* 优点：		#* 优点：

Eijux：/* “Physiological Logging”日志的存储内容 */

2021-04-27T13:51:36Z

“Physiological Logging”日志的存储内容

←上一版本		2021年4月27日 (二) 21:51的版本
第79行：		第79行：


	“Physiological ~~Logging”的特点是：~~		“Physiological Logging”的特点是：【以物理日志方式定位，以逻辑日志方式更新】
	# 与物理日志相同：'''更新操作相对于 page 进行，每一条日志仅仅涉及一个 page 的修改'''；		# 与物理日志相同：'''更新操作相对于 page 进行，每一条日志仅仅涉及一个 page 的修改'''；
	# 与逻辑日志相同：'''日志内容为更新语句（update query）本身'''，而不是状态机某些字段更新前后的状态。		# 与逻辑日志相同：'''日志内容为更新语句（update query）本身'''，而不是状态机某些字段更新前后的状态。

Eijux：/* 物理日志与逻辑日志的存储内容 */

2021-04-27T13:49:30Z

物理日志与逻辑日志的存储内容

←上一版本		2021年4月27日 (二) 21:49的版本
第10行：		第10行：
	== 物理日志与逻辑日志的存储内容 ==		== 物理日志与逻辑日志的存储内容 ==
	物理日志与逻辑日志在存储内容上有很大的区别，存储内容是区分它们的最重要手段：		物理日志与逻辑日志在存储内容上有很大的区别，存储内容是区分它们的最重要手段：
	# 物理日志：存储数据库中特定记录的变更，通常是 page oriented（面向页面），即描述具体某一个 page ~~的修改内容；~~		# 物理日志：存储数据库中特定记录的变更，通常是 page oriented（面向页面），即描述具体某一个 page 的修改'''内容'''；
	#: 如：一条更新请求对应的初始值（original value）以及更新值（after value）		#: 如：一条更新请求对应的初始值（original value）以及更新值（after value）
	# ~~逻辑日志：存储事务中的一个操作；~~		# 逻辑日志：存储事务中的一个'''操作'''；
	#: 如：事务中的 UPDATE、DELETE 以及 INSERT 操作。		#: 如：事务中的 UPDATE、DELETE 以及 INSERT 操作。

Eijux：建立内容为“category:MySQLcategory:Redis == 关于 == 日志主要分为： # '''逻辑日志''' （Logic log）； # '''物理日志''' （Physical log）； * 转…”的新页面

2021-04-27T13:48:42Z

建立内容为“category:MySQL category:Redis == 关于 == 日志主要分为： # '''逻辑日志''' （Logic log）； # '''物理日志''' （Physical log）； * 转…”的新页面

新页面

[[category:MySQL]][[category:Redis]]

== 关于 ==
日志主要分为：
# '''逻辑日志''' （Logic log）；
# '''物理日志''' （Physical log）；

* 转自：“[https://spongecaptain.cool/post/database/logicalandphicallog/#reference 逻辑日志与物理日志]”

== 物理日志与逻辑日志的存储内容 ==
物理日志与逻辑日志在存储内容上有很大的区别，存储内容是区分它们的最重要手段：
# 物理日志：存储数据库中特定记录的变更，通常是 page oriented（面向页面），即描述具体某一个 page 的修改内容；
#: 如：一条更新请求对应的初始值（original value）以及更新值（after value）
# 逻辑日志：存储事务中的一个操作；
#: 如：事务中的 UPDATE、DELETE 以及 INSERT 操作。

由以下示例可以看出：如果利用'''物理日志进行宕机后的数据恢复，那么需要确保 page 不能够改变'''，但利用'''逻辑日志并不在乎底层 page 是否改变'''。

=== “Physical log”的存储内容 ===
下图是一种典型的“物理日志”：
: [[File:物理日志.png|800px]]
我们可以看到，更新操作作用于 Page42，将字段 “Kemera” 修改为 “camera”。更新操作对应的日志为：
<syntaxhighlight lang="mysql" highlight="">
"Page 42:image at 367,2; before:'ke';after:'ca'"
</syntaxhighlight>
其中：
: Page 42 用于说明更新操作作用的 page；
: 367：用于说明更新操作相对于 page 的 offset；
: 2：用于说明更新操作的作用长度，即 length，2 代表仅仅修改了两个字符；
: before:‘Ke’：这里表示 undo information，也可以称为 undo log；
: after:‘ca’：这里表示 redo log information，也可以称为 redo log；

当然，一条物理日志可以有多个字段的修改，下面是一个抽象版本：
<syntaxhighlight lang="mysql" highlight="">
（Page ID，Record Offset,length，(Filed 1, Value 1) … (Filed i, Value i) … )
</syntaxhighlight>

注意：
* 物理日志实际上以字节编码落盘，而不是字符编码，因此通常肉眼不可见；
* image 的含义通常指代镜像，但这里不是说对 page 做整个镜像，而是对更改或增量（change/delta）操作做镜像，before image 代表写操作作用之前的字段副本，after image 代表写操作作用之后的字段副本；
* 可见，physical log 中的一条记录对应于状态机（state mechine）上某一个 page 上的某些字段做了什么改动的落盘。

=== “Logic log”的存储内容 ===
逻辑日志又被称为“high-level logging”，这是相对于物理日志而言的。

下图是一种典型的“逻辑日志”：
: [[File:逻辑日志.png|800px]]
在上图中，有一张 CameraLingo 表，我们试图纠正 itermID 为 0 的拼写错误，即将 “Kemera” 修改为 “Cemera”。逻辑日志的格式如下：
<syntaxhighlight lang="mysql" highlight="">
CameraLingo:update(0,'Kermera'=>'camera')
</syntaxhighlight>

逻辑日志被称为“high level”的原因是其更抽象，其不需要指明更新操作具体作用于哪一块 page，因此也对底层少了一些限制。逻辑日志与一条 SQL 语句非常类似，事实上确实如此，逻辑日志的本质就是对更新语句（update query）本身的落盘。

注意：
* “high level”的数据结构抽象不仅仅局限于 table，例如 key-value 也是一个典型的“high level”数据结构。
* 得益于“high level”的抽象，一个逻辑日志可以对应多条物理日志，下面举一个例子：
*: <syntaxhighlight lang="mysql" highlight="">
CameraLingo:capitaLetter(term)
</syntaxhighlight>
*: 上述逻辑日志的语义是对 CameraLingo 表中所有 term 字段对应的属性首字母大写，如果表足够大，此次逻辑日志涉及多个 page 上的修改，因而需要多个物理日志。

=== “Physiological Logging”日志的存储内容 ===
除了物理日志以及逻辑日志，还有一种日志被称为“Physiological Logging”，其试图同时获得物理日志与逻辑日志的优势。

下图是一种典型的“物理逻辑日志”：
: [[File:物理逻辑日志.png|800px]]

“Physiological Logging”的格式也可以如下表示：
<syntaxhighlight lang="mysql" highlight="">
（Page ID，Record Offset，(Filed 1, Value 1) … (Filed i, Value i) … )
</syntaxhighlight>
其中，Page ID、Record Offset 的设计源于物理日志。(Field1,Value1) 的设计来源于逻辑日志。

“Physiological Logging”的特点是：
# 与物理日志相同：'''更新操作相对于 page 进行，每一条日志仅仅涉及一个 page 的修改'''；
# 与逻辑日志相同：'''日志内容为更新语句（update query）本身'''，而不是状态机某些字段更新前后的状态。

== 物理日志与逻辑日志的比较 ==
=== 事务并发控制 ===
我们需要使用事务并发控制的原因基于以下事实（以 MySQL 为语境解释）：
# 事务由 SQL 语句构成，每一个 SQL 语句可分解为多个不可分隔的读/写操作；
# 事务的执行实际上是一连串不可分割读写操作的执行；
# 事务调度器负责调度不可分割读写操作的执行顺序，它们可能来自于不同事务；
# 事务并发控制的一个目标就是实现'''并行化事务'''；

# '''物理日志本身就是存储就是基于不可分隔的更新操作，因此其存储先后顺序就代表了执行器的调度顺序'''。而且由于很容易判断两个 page 是否是同一个 page，如果不是，完全可以安全并行地并行执行。
# '''逻辑日志很难实现一致的事务并发控制'''。由于逻辑日志难以携带并发执行顺序的信息，当同时有多个事务产生更新操作时，数据库内部会将这些操作调度为串行化序列执行，需要机制来保障每次回放操作的执行顺序与调度产生的顺序一致。
* 为了实现宕机前后事务并发控制的一致性，数据库选择使用 Physical Logging 作为其 Redo Log。

=== 幂等性 ===
幂等性在日志上的语义是：无论日志回放多少次，最终得到的结果保持一致。

# 物理日志能够保证幂等性：因为其本质是对状态机某一个字段在更新前后状态的记录，无论执行多少次，最终得到的状态总是相同的。下面是一个例子：
#: <syntaxhighlight lang="mysql" highlight="">
"Page 42:image at 367,2; before:'ke';after:'ca'"
</syntaxhighlight>
# 逻辑日志并不能够提供幂等性的语义，因为某一个更新操作本身不具备幂等性。例如：
#: <syntaxhighlight lang="mysql" highlight="">
CameraLingo:update(0,age=>age+1)
</syntaxhighlight>
#* 而且逻辑日志可能包含了某些不确定函数。
#* 当然，如果更新操作本身是幂等的，逻辑日志也可以是幂等的，例如：
<syntaxhighlight lang="mysql" highlight="">
CameraLingo:capitaLetter(term)
</syntaxhighlight>

=== 数据量大小 ===
日志数据量大小是特别重要的特性，其对以下过程都有影响：
* 磁盘 I/O 吞吐量；
* 落盘文件大小；
* 网络带宽；

来自客户端的一条更新语句可能会对应多个 page 上的更新，因此逻辑日志与物理日志在日志数量上有巨大的区别。
<syntaxhighlight lang="mysql" highlight="">
#查询语句
CameraLingo:capitaLetter(term)

#物理日志
"Page 42:image at 3,1; before:'k';after:'K'"
"Page 42:image at 22,1; before:'a';after:'A'"
....
"Page 42:image at 442,1; before:'b';after:'B'"

#逻辑日志
CameraLingo:capitaLetter(term)
</syntaxhighlight>
可以看出：'''逻辑日志在数据量上优势明显'''。

分布式系统中，会通过 primary 副本向 secondary 副本发送日志的方式来进行分布式事务的维护，因此使用物理日志进行传播就不合适。例如，'''MySQL 就选择逻辑日志进行维护分布式事务'''。

=== 日志重放效率 ===
逻辑日志比物理日志在重放时有着更低的效率，这主要有两个方面的原因：
# 额外的解释步骤：逻辑日志需要额外地解释更新语句、额外查找实际 page 位置；
# 物理日志可以并发进行：当系统判断两个物理日志作用于不同的 page 时，就可以进行完全的并行处理，而逻辑日志通常只能串行执行。

=== 磁盘/内存式日志系统的 trade-off【？？？】 ===
基于磁盘的存储系统与基于内存的存储系统对逻辑日志以及物理日志有着不同的 trade-off（权衡），如下面两张图所示：
: [[File:“基于磁盘的存储系统”的日志 IO 效率与 replay 效率.png|none|thumb|600px|“基于磁盘的存储系统”的日志 IO 效率与 replay 效率]]
: [[File:“基于内存的存储系统”的日志 IO 效率与 replay 效率.png|none|thumb|600px|“基于内存的存储系统”的日志 IO 效率与 replay 效率]]

== 工业实践与典型案例 ==
=== MySQL ===
----
MysQL 对存储引擎层以及 sever 提供了不同的日志方案。以 InnoDB 存储引擎为例。

==== server 层的 bin log ====
MySQL 的 server 层使用 binlog，其属于'''逻辑日志'''。bin log 分为两种类型：
# '''基于语句'''的日志记录（Statement-based logging）：主要记录了该 MySQL 执行语句（包括 inserts, updates, deletes）；
#* 优点：
#** 技术成熟；
#** 数据更少，即使一个更新操作会影响非常多的行。
#** 包括任何更新语句，因此可以用于数据库维护人员维护数据库；
#* 缺点：并非所有 SQL 语句的执行效果都支持基于语句的复制。例如调动一个函数 now() 来获取系统时间，在不同的机器、时间上重放日志将得到不同的结果；
# '''基于行'''的日志记录（Row-based logging）：主要记录了对单个行的修改，其在 MySQL 5.1.5 后引入；
#* 优点：
#** 所有更改都可以复制，包括上面提到的 now() 函数；
#** 以下类型的语句所需行锁更少，可以实现更好的并发性：
#*** INSERT ... SELECT
#*** INSERT statements with AUTO_INCREMENT
#*** UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
#* 缺点：
#** 数据量相比基于语句的 binlog 要大很多，在备份与恢复上性能较差；
#** 丢失了原有 SQL 更新语句，不利于复盘；
#**

无论是 SQL 更新语句还是行上具体某个修改，都是逻辑日志，因为都没有涉及在具体哪一个 page 上进行修改。

为此，MySQL 提供了三个模式进行配置：
# '''Statement'''：基于语句的 binlog 日志记录（statement-based replication-SBR）；
# '''Row'''：基于行的 binlog 日志记录（row-based replication-RBR）；
# '''Mixed'''：混合模式，通常基于语句，有必要的情况下基于行实现（mixed-based replication-MBR）；
* MySQL 从 5.1.8 开始提供 Mixed 模式。5.7.7 之前的版本默认是 Statement 模式，之后默认使用 Row 模式。但是在 8.0 以上版本已经默认使用 Mixed 模式了。

==== 数据引擎层的 '''redo log/undo log''' ====
MySQL 的 InnoDB 存储引擎使用 '''redo log''' 以及 '''undo log'''，它们属于'''“Physiological Logging”'''，虽然很多人认为其属于物理日志。【！！！】

MySQL InnoDB 的 redo log 可以分为三种类型：
# 作用于 Page，【？？？】
# 作用于 Space，【？？？】
# 以及提供额外信息的 Logic 类型。【？？？】

以“作用于Page”的 redo log 的格式为例：
: [[File:“作用于Page”的 redo log 的格式.png|400px]]

可见，MySQL 的 redo log 属于“Physiological Logging”：
# 物理上，其使用 Page Number + Record Offset 来指定具体作用于哪一个 page 上的一条记录。
# 逻辑上，使用 Field Number（Field编号）来说明更新操作作用于哪些字段；

=== Redis【？？？】 ===
----
Redis 是一个内存型 key-value NoSQL 数据库的典型代表。

Redis 基于 '''AOF'''（'''Append Only File'''）提供持久化机制。

AOF 中的每一条日志代表 Redis 节点接收到的一条写操作，其格式为 Redis 命令格式，因此 '''AOF 属于逻辑日志'''。

Redis 基于内存快照（RDB）+ check point + AOF 的方式实现持久化。【？】

=== Kafka【？？？】 ===
----
在关系型数据库看来，日志不是数据本身，例如'''对于 MySQL 的 InnoDB 存储引擎来说，数据本身是存储于磁盘上的 B+Tree 树'''，日志是用于确保单机事务以及分布式事务的一种手段。换言之，关系型数据库提供的读/查询 API 不是直接读日志，而是直接读 B+Tree。

但是'''对于 Kakfa 而言，日志本身就是数据本身'''。因此就没有必要将这类数据库分为逻辑日志与物理日志。Kakfa 的日志一方面服务于单机事务与分布式事务，另一方面服务于消息的读/写 API。

Kakfa “消息”包括如下重要字段：
{| class="wikitable"
! 字段 !! 含义
|-
| offset || 偏移量
|-
| magic || 魔数，区分版本
|-
| crc332 || 校验码
|-
| attributes || 表示压缩类型
|-
| key length || key 的长度
|-
| key || key
|-
| value length || value 长度
|-
| value || value
|-
| timestamp || 时间戳
|}
可见，Kafka 在“message-logging”中的一条消息并不是用于描述更新，其就是数据本身。

总之，'''当日志本身就是数据而不是描述更新操作时，不需要将日志区分为逻辑日志与物理日志'''。

逻辑日志与物理日志 - 版本历史

Eijux：​/* 数据引擎层的 redo log/undo log */

Eijux：​/* 数据引擎层的 redo log/undo log */

Eijux：​/* server 层的 bin log */

Eijux：​/* server 层的 bin log */

Eijux：​/* server 层的 bin log */

Eijux：​/* “Physiological Logging”日志的存储内容 */

Eijux：​/* 物理日志与逻辑日志的存储内容 */

Eijux：​建立内容为“category:MySQLcategory:Redis == 关于 == 日志主要分为： # '''逻辑日志''' （Logic log）； # '''物理日志''' （Physical log）； * 转…”的新页面

Eijux：/* 数据引擎层的 redo log/undo log */

Eijux：/* 数据引擎层的 redo log/undo log */

Eijux：/* server 层的 bin log */

Eijux：/* server 层的 bin log */

Eijux：/* server 层的 bin log */

Eijux：/* “Physiological Logging”日志的存储内容 */

Eijux：/* 物理日志与逻辑日志的存储内容 */

Eijux：建立内容为“category:MySQLcategory:Redis == 关于 == 日志主要分为： # '''逻辑日志''' （Logic log）； # '''物理日志''' （Physical log）； * 转…”的新页面