关于checkpoint的讨论

本文围绕Oracle数据库的Checkpoint展开,介绍了其定义,即把已修改数据从高速缓存刷新到磁盘并更新控制文件和数据文件。阐述了触发Checkpoint的多种情况,还讲解了增量检查点机制,以及检查点队列相关知识,包括队列结构、锁存器等内容。
部署运行你感兴趣的模型镜像

 

http://www.cnoug.org/viewthread.php?tid=21969

贴主: wanghai

 

checkpoint小议

什么是checkpoint?
checkpoint是一个数据库事件,它将已修改的数据从高速缓存刷新到磁盘,并更新控制文件和数据文件。

什么时候发生checkpoint?
我们知道了checkpoint会刷新脏数据,但什么时候会发生checkpoint呢?以下几种情况会触发checkpoint。
1.当发生日志组切换的时候
2.当符合LOG_CHECKPOINT_TIMEOUT,LOG_CHECKPOINT_INTERVAL,fast_start_io_target,fast_start_mttr_target参数设置的时候
3.当运行ALTER SYSTEM SWITCH LOGFILE的时候
4.当运行ALTER SYSTEM CHECKPOINT的时候
5.当运行alter tablespace XXX begin backup,end backup的时候
6.当运行alter tablespace ,datafile offline的时候;

增量检查点(incremental checkpoint)
oracle8以后推出了incremental checkpoint的机制,在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘,巨大的i/o对系统性能带来很大影响。为了解决这个问题,oracle引入了checkpoint queue机制,每一个脏块会被移到检查点队列里面去,按照low rdb(第一次对此块修改对应的redo block address)来排列,靠近检查点队列尾端的数据块的low rba值是最小的,而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变,这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件,记录checkpoint执行的情况。

数据字典
完全检查点
select * from X$KCCRT where indx=0;

ADDR           INDX    INST_ID      RTNUM      RTSTA RTCKP_SCN        RTCKP_TIM             RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB         RTOTF      RTOTB      RTNLF      RTLFH      RTLFT      RTCLN      RTSEQ RTENB            RTETS    RTDIS            RTDIT                     RTLHP RTSID            RTOTS
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
4084B228          0          1          1         15 720368521        06/25/2004 18:49:37           1           949             2     16 0600000000000000          2          0          3          1          3          1        949 1                05/16/2004 13:29:03  0                                               1389 tbdb2in1         06/12/2004 12:30:50

这里显示了上一次的完全检查点是在06/25/2004 18:49:37发生,所以我们推断06/25/2004 18:49:37发生了一次日志切换,再去操作系统上去看生产的归档,果然18:49有一个归档生产。
-rw-r-----    1 oracle   oinstall 83532800 Jun 25 18:49 1_948.dbf




增量检查点
SQL> select * from X$KCCCP where indx=0;

ADDR           INDX    INST_ID      CPTNO      CPSTA      CPFLG      CPDRT      CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF  CPODR_SEQ  CPODR_BNO  CPODR_BOF CPODS                CPODT                   CPODT_I      CPHBT CPRLS                 CPRLC      CPMID  CPSDR_SEQ  CPSDR_BNO  CPSDR_ADB
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- ----------
4084B45C          0          1          1          2          0      10762      29753        949      76847          0        949     106814              0 721554970        06/25/2004 21:05:10   529794310  529036227 1                 526310932 1413781667        949              1          0

这里显示了low-rba,on-disk rba,checkpoint time等信息。

 

biti_rainy:

每隔3秒钟ckpt会去更新控制文件和数据文件,记录checkpoint执行的情况。


这里应该是只更新控制文件,每3秒不是更新数据文件
说 记录 checkpoint 的执行情况,这个说法,没错,但不够详细,应该说,由于增量检查点和 checkpoint  queue 的原理,ckpt 进程每次只是告诉 dbwr ,写dirty  buffer将要一直写到最新这个位置,仅仅是告诉 dbwr 一个 checkpoint queue  中的结束点,而 ckpt 每3秒中,在控制文件中报告一下 dbwr 最新写入的位置。 这样使得,比如数据库要做恢复的时候(instance  recovery)可以从这个最新位置开始做恢复,而不是从数据文件中的 checkpoint  scn 开始做恢复,这样将缩短恢复时间,尤其是 instance  crash 的情况下启动更快

另外要注意的是,检查点发生的时候,ckpt 去更新数据文件头和控制文件,并不是把当前检查点发生时候的 scn 更新进去,而是把上一次dbwr写入已经完成的检查点发生时候的  scn 更新进去 ,也就是说,更新控制文件和数据文件头 是 滞后于检查点的发生的,这个从恢复的原理也很容易理解,因为检查点发生的时候 dirty buffer还没有写入,自然不能立即更新成当前的 scn 了。

jerrysun 转:

something about checkpoint queue latch

wanghai, the following is just for your reference. :)

Firstly we have two queue structures associated with checkpoints - the checkpoint queue - or thread queue - (CKPTQ), and the file queue.For each buffer to be checkpointed, it is linked to these two queues. The CKPTQ contains all buffers that need to be checkpointed for this instance.  The File queue contains all buffers that belong to a specific file that need to  be checkpointed. There is one file queue per file. The file queues are used by tablespace checkpoint requests.

Both these queues constitute a set of checkpoint queues.

Before a process can put a buffer on a checkpoint queue, it must make sure that the queue is not being used. There is one checkpoint queue latch per set of  checkpoint queues, that is used to control access to these queues. To reduce contention on this latch, the set of thread and file queues is replicated as per the number of working sets for the instance.

The determination of the number of working sets has changed across the DB versions.  For 9.2, the default number is calculated
internally as #CPUs  / 2 * 8.

The maximum of DBWR's (db_writer_processes) you can have at 9.2 is 20.  Working sets are assigned to DBWR's in a round-robin
fashion at startup.

 

关于checkpoint queue 与 write list 的关系,请参考

http://blog.youkuaiyun.com/biti_rainy/archive/2004/08/01/learn_oracle_20040801_1.aspx

 

您可能感兴趣的与本文相关的镜像

Wan2.2-T2V-A5B

Wan2.2-T2V-A5B

文生视频
Wan2.2

Wan2.2是由通义万相开源高效文本到视频生成模型,是有​50亿参数的轻量级视频生成模型,专为快速内容创作优化。支持480P视频生成,具备优秀的时序连贯性和运动推理能力

<think> 我们正在讨论Flink的checkpoint机制,用户之前询问了如何下载数据到./data目录,但随后转向了Flink checkpoint的查看方法。根据引用内容,用户可能在使用Flink时遇到了checkpoint超时等问题,现在想了解如何查看checkpoint的相关信息。 查看Flink checkpoint的方法可以从多个角度进行: 1. **Web UI查看**:这是最直观的方式,通过Flink的Web界面可以查看checkpoint的统计信息,包括大小、持续时间、最新完成的checkpoint等。 2. **命令行查看**:使用Flink的命令行工具可以列出和检查checkpoint的元数据。 3. **日志文件分析**:Flink的TaskManager和JobManager日志会记录checkpoint的详细信息。 4. **REST API查询**:通过Flink的REST API可以获取作业的checkpoint统计信息。 下面我将详细介绍这些方法: ### 1. Web UI查看 Flink的Web UI提供了一个监控checkpoint的界面,通常在作业的Overview页面中有一个“Checkpoints”选项卡,点击后可以看到: - **Checkpoint Counts**:成功、失败、进行中的checkpoint数量。 - **Latest Completed Checkpoint**:最近完成的checkpoint的详细信息,包括ID、完成时间、大小、持续时间和对齐时间(如果是对齐的checkpoint)。 - **Latest Failed Checkpoint**:最近失败的checkpoint及其失败原因。 - **Summary**:最小/最大持续时间、大小等统计信息。 此外,在“Task Managers”页面,也可以查看各个TaskManager的checkpoint相关指标。 ### 2. 命令行查看 使用Flink的`flink`命令行工具可以查看checkpoint元数据。首先,你需要知道作业的JobID(可以通过`flink list`查看运行中的作业,或者通过`flink list -a`查看所有作业)。 然后,使用以下命令: ```bash bin/flink savepoint <jobId> [targetDirectory] # 手动触发一个savepoint(可以用于停止作业时保留状态) bin/flink cancel -s [targetDirectory] <jobId> # 停止作业并触发savepoint # 查看savepoint的元数据(适用于手动触发的savepoint和自动的checkpoint) bin/flink savepoint -d <savepointPath> # 显示savepoint的详细信息,包括算子状态路径 ``` 注意:自动的checkpoint通常存储在配置的文件系统目录中(如HDFS、S3),其路径结构通常为: ``` hdfs:///flink/checkpoints/<job-id>/chk-<checkpoint-id> ``` 你可以通过文件系统命令(如`hdfs dfs -ls`)直接查看这些文件,但元数据通常需要借助工具解析。 ### 3. 日志文件分析 在JobManager和TaskManager的日志中,搜索关键词“Checkpoint”可以找到详细的checkpoint记录。例如: - “Starting checkpoint”表示开始一次checkpoint。 - “Completed checkpoint”表示成功完成。 - “Failed checkpoint”则会附带失败原因。 日志级别设置为DEBUG或TRACE可以获取更详细的信息,但要注意日志量会很大。 ### 4. REST API查询 Flink的REST API提供了获取checkpoint信息的接口。例如,获取某个作业的checkpoint统计信息: ``` GET /jobs/<jobId>/checkpoints ``` 返回的JSON数据包含了最近完成的checkpoint和最近失败的checkpoint的详细信息。 另外,还可以通过以下接口获取更详细的信息: ``` GET /jobs/<jobId>/checkpoints/details/<checkpointId> ``` 使用REST API需要知道Flink JobManager的REST端口(默认8081)和作业的JobID。 ### 总结 根据你的需求,选择合适的方法查看checkpoint: - 实时监控:使用Web UI或REST API。 - 离线分析:查看日志或使用命令行工具。 如果你的checkpoint持续超时,可以尝试调整配置(如增加超时时间)或使用非对齐checkpoint(见引用[4])[^4]。同时,检查网络和资源情况,确保没有资源不足的问题[^2]。 §§相关问题§§ 1. 如何配置Flink的checkpoint超时时间? 2. 非对齐checkpoint如何启用? 3. 如何通过REST API获取Flink作业的checkpoint信息? </think> ### 查看 Flink Checkpoint 的方法 以下是三种实用的 Checkpoint 查看方法,可帮助您监控和诊断问题(基于引用内容优化): #### 1. **Web UI 可视化查看(推荐)** ```bash # 启动 Flink 集群后访问 http://<jobmanager-host>:8081 ``` - **查看位置**: `Job Overview → Checkpoints` 标签页 ![Checkpoint UI](https://flink.apache.org/img/checkpointing/checkpoints_tab.png) - **关键指标**: - ✅ **最近完成**:ID、触发时间、时长、大小 - ❌ **最近失败**:失败原因(如超时[^1]) - 📊 **统计信息**:最小/最大持续时间(识别反压) - **优势**:实时监控对齐/非对齐检查点状态[^4] #### 2. **命令行检查 Checkpoint 元数据** ```bash # 列出所有 savepoint/checkpoint ./bin/flink list -m <jobmanager-host>:8081 # 检查指定 checkpoint 元数据 ./bin/flink savepoint -d <checkpoint-path> ``` **输出示例**: ```plaintext Checkpoint ID: 42d5ac (completed) State Size: 78.4 MB Duration: 4.2s/6.0s (对齐/总时长) # 对齐耗时接近超时需预警[^1] Operator States: - SourceOperator (3.2 MB) - WindowOperator (75.2 MB) # 识别大状态算子 ``` #### 3. **日志分析诊断** 在 `taskmanager.log` 中搜索关键词: ```log # 成功案例 INFO - Completed checkpoint 89 (78MB) in 4.3s # 失败诊断(引用问题[^1][^3]) WARN - Checkpoint 90 expired before completing ERROR - Barrier alignment timeout at WindowOperator -> 建议: 启用非对齐检查点[^4] ``` **日志配置建议**: 在 `log4j.properties` 中添加: ```properties logger.checkpoint.name = org.apache.flink.runtime.checkpoint logger.checkpoint.level = DEBUG ``` ### 关键配置关联(引用内容优化) | 配置项 | 作用 | 问题关联 | |--------|------|----------| | `setCheckpointTimeout(6000L)`[^1] | 超时阈值 | 超出即失败 | | `enableUnalignedCheckpoints()`[^4] | 启用非对齐检查点 | 解决反压场景超时 | | `setTolerableCheckpointFailureNumber(Integer.MAX_VALUE)`[^3] | 容错机制 | 失败时任务继续运行 | --- ### 诊断流程图 ```mermaid graph TD A[Checkpoint失败] --> B{查看Web UI} B --> C1[超时?] B --> C2[对齐阻塞?] C1 --> D1[增加setCheckpointTimeout] C2 --> D2[启用非对齐检查点[^4]] D1 --> E[观察反压指标] D2 --> E E --> F[优化算子/扩容] ```
评论 4
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值