目录
常见日志级别
数据库日志
Undo log 逻辑日志
redolog binlog
慢查询日志
AOF 文本文件
RDB 二进制文件
常见日志级别
-
DEBUG:用于详细记录应用程序的运行过程,如变量值、执行流程等。DEBUG级别的日志通常用于开发和调试过程中,以便于了解程序的内部运行状态。
-
INFO:用于记录应用程序的一般信息,如状态变更、操作结果等。INFO级别的日志通常用于生产环境中,以便于了解应用程序的运行状况。
-
WARNING:用于记录可能导致问题的事件,如性能瓶颈、配置错误等。WARNING级别的日志通常用于提醒开发者关注潜在的问题和风险。
-
ERROR:用于记录应用程序运行过程中出现的错误和异常。ERROR级别的日志通常包含错误发生的时间、位置、详细描述和堆栈跟踪等信息,以便于问题排查。
-
CRITICAL:用于记录应用程序中的严重错误和问题,如数据丢失、系统崩溃等。CRITICAL级别的日志通常用于处理紧急情况和重大事件。
这些日志级别通常按照从低到高的顺序排列,即DEBUG < INFO < WARNING < ERROR < CRITICAL。在配置logging
库时,可以设置日志记录的最低级别,以便于过滤不需要的日志信息。
数据库日志
先讲一下三种日志类型(主要区别在于记录的信息和恢复数据的方式):
-
逻辑日志(Logical Log):逻辑日志记录了数据库操作的高级描述,例如插入、更新和删除操作。逻辑日志关注数据的变更内容,而不关注底层数据结构的改变。
UndoLog
就是一种逻辑日志,它记录了对数据库表的操作,以便在需要时撤销这些操作。 -
物理日志(Physical Log):物理日志记录了数据库底层数据结构的改变,例如磁盘上的数据页的变化。物理日志关注数据存储的具体实现,而不关注数据的逻辑变更。物理日志通常用于数据库的故障恢复、备份等场景。
-
二进制日志(Binary Log,也称为Binlog)是MySQL数据库中用于记录数据库操作的一种日志文件。它记录了对数据库进行的所有更改操作(如插入、更新、删除等)以及这些操作发生的时间。二进制日志以二进制格式存储。在某种程度上类似逻辑日志,因为它记录了操作的高级描述。
Undo log 逻辑日志
实际上,UndoLog
日志文件中的记录格式取决于你的应用程序需求和日志记录方式。通常,日志文件中的记录会以文本形式存储,每行一个记录,可以是JSON、CSV或其他自定义格式。以下是一个以JSON格式存储的UndoLog
日志文件记录示例:
{"id": 1, "operation": "UPDATE", "timestamp": "2022-08-01T12:34:56Z", "table_name": "User", "primary_key": 1, "old_data": {"name": "Alice", "age": 25}, "new_data": {"name": "Alice", "age": 26}}
{"id": 2, "operation": "INSERT", "timestamp": "2022-08-01T12:35:30Z", "table_name": "User", "primary_key": 2, "old_data": null, "new_data": {"name": "Bob", "age": 30}}
{"id": 3, "operation": "DELETE", "timestamp": "2022-08-01T12:36:10Z", "table_name": "User", "primary_key": 3, "old_data": {"name": "Charlie", "age": 22}, "new_data": null}
示例中,日志文件包含3条UndoLog
记录,分别是一条更新操作、一条插入操作和一条删除操作。每条记录都是一个JSON对象,占据一行。这种格式便于解析和处理。
redolog binlog
重做日志redo log和binlog 日志都是以二进制的形式保存的,不能直接“看”,
mysqlbinlog
工具查看的binlog日志记录类似:
# at 4
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x12345678
Start: binlog v 4, server v 8.0.27-0ubuntu0.20.04.1-log created 211001 12:00:00 at startup# at 123
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x23456789
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
BEGIN
/*!*/;
# at 456
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x34567890
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
UPDATE users SET age=26, last_login='2021-10-02 10:00:00' WHERE id=100
/*!*/;
# at 789
#211001 12:00:00 server id 1 end_log_pos 0 CRC32 0x45678901
Query: thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1633080000/*!*/;
COMMIT
/*!*/;
而redo log
主要用于数据库内部处理,通常不需要直接查看或分析。在需要恢复数据时,数据库管理系统会自动处理redo log
。
慢查询日志
MySQL的慢查询日志记录了执行时间超过指定阈值的查询。慢查询日志可以帮助您发现性能瓶颈并优化数据库性能。慢查询日志的格式和内容可能因MySQL版本和配置而异,但通常包括查询的SQL语句、执行时间、锁定时间等信息。
简化的示例
# Time: 211001 12:00:00
# User@Host: example_user[example_user] @ localhost []
# Thread_id: 1 Schema: example_db Last_errno: 0 Killed: 0
# Query_time: 5.123456 Lock_time: 0.000123 Rows_sent: 1 Rows_examined: 1000 Rows_affected: 0
# Bytes_sent: 100 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: Yes Filesort_on_disk: No Merge_passes: 0
SET timestamp=1633080000;
SELECT * FROM example_table WHERE some_column = 'some_value';
记录了一个SELECT
操作,涉及到名为example_table
的表。此操作的查询时间(Query_time
)为5.123456秒,超过了慢查询阈值。慢查询日志还包含了其他元数据,如锁定时间(Lock_time
)、发送的行数(Rows_sent
)、查询类型(全表扫描、文件排序等)等。
启用慢查询日志并设置阈值,您需要在MySQL配置文件(如my.cnf
或my.ini
)中添加以下配置:
slow_query_log = 1
slow_query_log_file = /path/to/your/slow-query.log # 日志文件路径
long_query_time = 1 # 慢查询阈值设置为1s
AOF 文本文件
AOF(Append Only File)属于Redis数据库的持久化日志。它记录了操作Redis的所有命令,以便在Redis服务器重启时恢复数据。AOF日志以文本格式存储,每一行都是一个Redis命令。通常具有 .aof
扩展名,例如 appendonly.aof。
*2
$6
SELECT
$1
0
*3
$3
SET
$3
key
$5
value
*3
$5
LPUSH
$6
mylist
$4
item
例中的AOF文件包含了三个Redis命令:SELECT 0
(选择数据库0)、SET key value
(设置键值对)和LPUSH mylist item
(将元素推入列表)。当Redis服务器启动时,它会自动执行这些命令以恢复数据。
RDB 二进制文件
Redis的RDB(Redis Database)文件是一个二进制文件,用于存储Redis数据库在某个时间点的数据快照。RDB文件通常具有.rdb
扩展名,例如dump.rdb
。由于RDB是二进制格式,因此它的内容无法直接阅读。
RDB文件包含了Redis数据库中的键值对数据,以及一些元数据,如过期时间等。RDB文件的结构和格式由Redis内部实现,通常不需要关注。(虚晃一枪收尾)