检查点和日志修剪交互
概述
检查点是将所有挂起的页面更新从页面缓存刷新到存储文件的过程。这对于确保需要在恢复期间重放的事务数量保持在合理范围内是必要的，主要目的是减少在不当关闭后恢复时间。无论检查点是否存在，数据库操作都保持安全，因为所有未确认其更改已持久保存到存储的事务都将在下次数据库启动时重放。但是，这取决于这些事务包含的一组更改的存在，这些信息保存在事务日志中。保持未应用事务列表较长（检查点之间的间隔较大）会导致事务日志累积，因为它们对于恢复是必要的。检查点在事务日志中引入一个特殊的“检查点”条目，该条目标记发生检查点的最后一个事务。这用于确定哪些事务日志不再必要，因为它们包含的所有事务都已安全地持久保存到存储文件。
删除不再需要恢复的事务日志的过程称为修剪。从上述描述可以看出，修剪依赖于检查点，因为检查点决定了哪些日志可以被修剪，或者换句话说，何时可以进行修剪，因为如果未进行检查点，则可修剪的事务日志文件集不会发生变化。此依赖关系通过在每次发生检查点时触发修剪（这可能包括或不包括检查其是否存在，如下所述）来表达。这种关系是不变的，并适用于以下讨论的全部内容。
触发检查点（和修剪）事件
检查点是修剪的驱动事件，可以通过几种不同的方式触发。
最简单的方法称为“周期性”，默认情况下每 15 分钟检查一次是否存在待刷新的更改（即尚未检查点的事务）。如果是，则执行检查点并随后触发日志修剪。请注意，没有执行检查点意味着不会发生修剪。这是默认行为，也是社区版中唯一可用的行为。
在企业版中，还有两种额外的检查点策略。最简单的一种称为“连续”，顾名思义，它会不断检查检查点是否可行（即自上次成功检查点以来是否提交了任何事务），如果可行，则执行检查点。修剪在其完成后立即触发，就像周期性策略一样。
第三种也是最后一种检查点策略是“容量”。它每 10 秒检查一次是否有任何日志可供修剪，如果有，则触发检查点并随后修剪日志。此策略似乎颠倒了检查点和修剪之间的控制，但实际上它只改变了检查点必须发生的时间标准。它不依赖于时间触发器（如前两个），而是依赖于修剪检查。与其他两种策略一样，修剪仍将在检查点发生后进行。然而，由于检查取决于可修剪的事务日志文件的存在，因此此策略依赖于修剪配置，如下一节所述。
要使用的策略由设置 dbms.checkpoint 控制，默认为“周期性”。
日志记录和指标
以下详细说明了在检查点事件发生时预期出现在 logs\debug.log 中的消息
基于 dbms.checkpoint.interval.time 的检查点
2019-08-28 12:55:05.174+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for time threshold" @ txId: 49 checkpoint started... 2019-08-28 12:55:05.253+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for time threshold" @ txId: 49 checkpoint completed in 79ms
基于 dbms.checkpoint.interval.tx 的检查点
2019-08-28 13:08:51.603+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for tx count threshold" @ txId: 118 checkpoint started... 2019-08-28 13:08:51.669+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for tx count threshold" @ txId: 118 checkpoint completed in 66ms
当 dbms.checkpoint=continuous 时进行检查点
2019-08-28 13:17:21.927+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for continuous threshold" @ txId: 171 checkpoint started... 2019-08-28 13:17:21.941+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Scheduled checkpoint for continuous threshold" @ txId: 171 checkpoint completed in 13ms
数据库关闭导致的检查点
2019-08-28 12:35:56.272+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Database shutdown" @ txId: 47 checkpoint started... 2019-08-28 12:35:56.306+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Database shutdown" @ txId: 47 checkpoint completed in 34ms
Neo4j 3.5.6 中引入的 call dbms.checkpoint(); 导致的检查点
2019-08-28 12:31:56.463+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Call to dbms.checkpoint() procedure" @ txId: 47 checkpoint started... 2019-08-28 12:31:56.490+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Call to dbms.checkpoint() procedure" @ txId: 47 checkpoint completed in 27ms
备份运行导致的检查点
2019-08-28 12:33:30.489+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Full backup" @ txId: 47 checkpoint started... 2019-08-28 12:33:30.509+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Checkpoint triggered by "Full backup" @ txId: 47 checkpoint completed in 20ms
检查点指标 也可用，并在 metrics/ 和以下文件中详细说明
neo4j.check_point.check_point_duration.csv neo4j.check_point.total_time.csv neo4j.check_point.events.csv
控制事务日志修剪
事务日志修剪配置主要涉及指定应保留多少事务日志。保留超过恢复所需的绝对最小数量的主要原因来自集群部署和在线备份的要求。由于数据库更新是通过事务日志在集群成员和备份客户端之间进行通信的，因此保留超过必要数量的日志允许仅传输增量更改（以事务的形式），而不是整个存储文件，这可以节省大量的时间和网络带宽。这对 HA 部署、备份和因果集群中的读取副本适用。但是，在因果集群中核心成员的情况下，重要的不是事务日志，而是 Raft 日志内容。这种情况在单独的知识库文章中进行了介绍。
修剪操作后剩余的事务日志数量由设置 dbms.tx_log.rotation.retention_policy 控制，它可以采用多种值。它们的形式为 <数值> <度量>。
<度量> 可以是“files”（文件）、“size”（大小）、“txs”（事务）、“entries”（条目）、“hours”（小时）或“days”（天）。
-
**“files”** 确定修剪后剩余的事务日志文件的最小数量。这意味着一旦执行检查点，就会删除一定数量的日志文件，以保留至少指定数量的文件——例如，值“5 files”将至少保留 5 个事务日志文件。
-
**“size”** 的行为类似，但它不是计算文件数量，而是计算总文件大小。例如，“500M size”将至少保留 500M 的文件。
-
**“txs”** 和 **“entries”** 是同义词。它们的行为类似于上述，但它们计算文件中存在的事务，而不管文件数量或大小。“100 txs”将在每次操作后至少保留 100 个事务的日志未被修剪。
-
**“hours”** 和 **“days”** 测量时间而不是大小或事务计数，但在其他方面行为类似。将值设置为“20 hours”将确保日志中至少存在 20 小时的交易。
此页面是否有帮助？