我们遵循instructions将具有单个分片的群集转换为副本集,但是一旦我们重新启动了第一个辅助节点(总共3个辅助节点+ 1个主节点),而没有--shardsvr
选项,所有数据库客户端(已经直接连接到replSet而不出现问题,而是连接到mongoS路由器)在查询数据库时收到以下错误:
Query failed with error code 211 and error message 'Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1585205456, 422) } with id: 6802955028354040016' on server our-db-server.domain.com:27017
因此,我们立即撤消了更改。 此错误使我们无法将单碎片群集转换为独立的replSet。 如何进行? 谢谢!
答案 0 :(得分:0)
我认为可能的情况是 vector clock clusterTime 在副本和/或您的客户端之间不同步。
此 section specifically 处理如何将 clusterTime 用于 HMAC signatures。
clusterTime 基本上每次写入 PRIMARY 时都会发生滴答,因此如果您以某种方式更改集群的配置,则会捕获滴答。如果您的客户端在那个勾号之后没有正确更新其 clusterTime,则可能会在尝试使用旧密钥对其请求进行 HMAC 签名时被发现。
如上所述,集群可能有问题,客户端 heartbeat 没有更正时钟。
也可能是您的客户端库在按照此票证进行身份验证握手时未更新 clusterTime:https://jira.mongodb.org/browse/GODRIVER-1584。
我只是想在这里做一些笔记,因为我在从 3.6 升级到 4.0.21 时也看到这个错误。
通过使用 sourcegraph 搜索存储库,我发现这是从 MongoDB 返回的。
错误来自 KeysCollectionManager::getKeysForValidation,根源在于 KeysCollectionCache::getInternalByKeyId 方法。
这个特定的 KeysCollectionManager 似乎只是为副本集实例化自己。它使用 kKeyManagerPurposeString 实例化,其值始终为“HMAC”。这是目的,我不确定。
go 客户端的 globalsign/mgo 分支有一些测试工具,表明他们以前遇到过这种情况,但不一定知道它来自哪里。他们假设只有当您的副本集使用内部身份验证密钥文件时才会发生这种情况。
我希望通过多次重试直到成功解决这种情况。我敢打赌,这主要是集群未处于就绪状态的问题。
我的情况与问题大不相同,因为我使用的是没有分片的独立副本集。我希望重试请求会有所帮助,但这可能是需要在 MongoDB 本身上解决的集群成员资格问题。
这个 post in the MongoDB community 可能表明这是一个集群内部问题,寻找可疑的 MongoDB 日志将是关键。