MarkLogic - XDMP-NEWSTAMP 异常

Question

我们正在使用

MarkLogic-8

（具有三个节点 - 每个节点有两个森林）并且经常面临

XDMP-NEWSTAMP

异常。 我们有

default merge policy

并且不使用任何

point in time

查询。 但我们确实使用

xdmp:eval

和

xdmp:invoke-fuction

（在代码中大量使用）来避免

locks

只在

update transactions

中读取（查询模式）文档。

除了

XDMP-NEWSTAMP

以及

XDMP-NEWSTAMP

MarkLogic 查询部分中的提及之外，

App developer guide's

文档中也没有与

point in time

相关的非常全面的信息；两者都经历过，但都没有帮助。

请帮助我理解此异常（并分享是否有任何文档包含与此相关的详细信息）。 以下是供参考的日志片段：

2020-07-16 03:07:31.712 Warning: Forest XXX-YY-003 fast query timestamp (15948687770144645) lags commit timestamp (15948688205890165) by 43574 ms
2020-07-16 03:08:03.583 Warning: Forest XXX-YY-003 fast query timestamp (15948687770144645) lags commit timestamp (15948688803306468) by 103316 ms
2020-07-16 03:08:03.632 Info: Merging 2 MB from G:\Forests\xxxx03\000048af to G:\Forests\xxxx03\000048b1, timestamp=15948682803306468
2020-07-16 03:08:03.933 Debug: OnDiskStand G:\Forests\xxxx03\000048b1, disk=3MB, memory=1MB
2020-07-16 03:08:03.934 Info: Merged 3 MB at 10 MB/sec to G:\Forests\xxxx03\000048b1
2020-07-16 03:08:03.960 Debug: Forest xxxx03 setting minQueryTimestamp to 15948682803306468 due to merge
2020-07-16 03:08:04.936 Debug: ~OnDiskStand G:\Forests\xxxx03\000048af
2020-07-16 03:08:07.166 Info: Deleted 2 MB at 703 MB/sec G:\Forests\xxxx03\000048af
2020-07-16 03:08:17.617 Debug: Forest XXX-YY-003 participant 1232761274262892690 not found in participantBumpMinCommitTimestamp()

2020-07-16 03:22:23.750 Info: XXX-WorkApi: Status 500: XDMP-NEWSTAMP: Timestamp too new for forest XXX-YY-003 (15948695621461959)
2020-07-16 03:22:23.750 Info: XXX-WorkApi: Status 500: XDMP-NEWSTAMP: Timestamp too new for forest XXX-YY-003 (15948695621461959)

Answer 1

这可能是由于一些长时间运行的查询造成的。

在 XDMP-NEWSTAMP 之前，为该林记录了“快速查询时间戳”消息： https://community.progress.com/s/article/warning-messages-for-lagging-operations

每个森林都有一个“快速查询时间戳”的概念，有时也称为“非阻塞时间戳”。这是查询可以运行而无需等待林的时间戳提前的最大时间戳；它指示森林具有完整状态来回答查询的最新时间。森林具有此时间戳有多种原因。

第一个与事务提交有关，在此期间，森林在提交期间将手指放在提交时间戳上。这样做的目的是确保查询将已提交的事务视为原子事务。在任何给定的时间点，只要将手指放在不同的时间戳上，就可以有多个（甚至多个）交易。

此警告将有助于标记可能阻碍查询的过长事务的任何问题。该警告有助于更早而不是更晚地标记滞后问题。

Answer 2

将应用程序服务器配置

distribute timestamps

更改为

strict

（之前设置为

fast

），现在

XDMP-NEWSTAMP

的出现次数已显着减少。这一变化是否会带来任何可能的负面影响？增加

network load

是我所期待的。还有其他的吗？