无法从对等方获取私有数据空成员身份-Hyperledged Fabric 1.4.6

如何解决无法从对等方获取私有数据空成员身份-Hyperledged Fabric 1.4.6

我遇到了一个1.4.6 Fabric网络的问题，该网络具有一个网络（27个对等点和5个订购者），其中组织中有一个对等点（锚点对等点）停止提交事务。我不明白为什么它开始显示此消息而网络上没有任何更新，但是在此之前它可以正常工作。

消息是：

2020-08-26 19:56:35.147 UTC [gossip.privdata] fetchPrivateData -> WARN fc2 Do not know any peer in the channel( xxxx ) that matches the policies,aborting
2020-08-26 19:56:35.147 UTC [gossip.privdata] fetchFromPeers -> WARN fc3 Failed fetching private data for block 743444 from peers: Empty membership
2020-08-26 19:56:36.149 UTC [gossip.privdata] fetchPrivateData -> WARN fc4 Do not know any peer in the channel( xxxx ) that matches the policies,aborting

我已经尝试过在所有对等方之间更新链码，以查看是否有所更改，但是即使所有其他对等方都已更新并且仍与各自的PDC一起使用，这个人也停止了对链码的更新。

我知道我们应该配置其他对等点来传播pvt数据，但是不幸的是我们没有这样做，现在我需要找到一种使该对等点再次工作的方法。其他所有26个都很好，它们都具有相同的配置（仅更改组织）。谁能帮助我找到一种方法，使该对等方接受并提交新交易，即使这会导致某些pvt数据丢失？

编辑以获取更多信息。当我尝试为该对等方发送新交易时，会发生以下情况：

2020-08-28 17:29:07.018 UTC [endorser] callChaincode -> INFO 3c0b [channel][6b3e2fcc] Entry chaincode: name:"chaincode"
2020-08-28 17:29:07.022 UTC [endorser] callChaincode -> INFO 3c0c [channel][6b3e2fcc] Exit chaincode: name:"chaincode"  (4ms)
2020-08-28 17:29:07.033 UTC [comm.grpc.server] 1 -> INFO 3c0d unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=172.21.0.4:40998 grpc.code=OK grpc.call_duration=17.194301ms
2020-08-28 17:29:53.670 UTC [gossip.privdata] StoreBlock -> WARN 3c2f [channel] Could not fetch all missing collection private write sets from remote peers. Will commit block [744876] with missing private write sets:[txID: bdeb55aa80d4c2a2f615abeefe0dbb97a60a08babb5ef2a1f9a0627fe4bf2ccb,seq: 0,namespace: chaincode,collection: collectionTestResults,hash: e0cde0ce12a35de1e7628e9283b26e20849ea5e112ef0daeb8a5a6d7aa1a1706
txID: f505a249ca1c4136711c8402cb2333a2e1b59cb02b573749f4c9488194e3a682,seq: 1,hash: ca65f8ed487f7e06201f25a7e0872c522afcb54c1c64c137cec8ef1d31e56d6d
txID: 3032cc2c4ce4702ef1ec0da28ca7e5a0bd4b2c4604915704ae63fc9d8342c138,seq: 2,hash: 35c4be3879a191f9e2f132188b313bf4f297e2881e4ad6149c40708191d972fb
]
2020-08-28 17:29:53.675 UTC [statebasedval] ValidateAndPrepareBatch -> WARN 3c30 Block [744876] Transaction index [0] TxId [bdeb55aa80d4c2a2f615abeefe0dbb97a60a08babb5ef2a1f9a0627fe4bf2ccb] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
2020-08-28 17:29:53.675 UTC [statebasedval] ValidateAndPrepareBatch -> WARN 3c31 Block [744876] Transaction index [1] TxId [f505a249ca1c4136711c8402cb2333a2e1b59cb02b573749f4c9488194e3a682] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
2020-08-28 17:29:53.699 UTC [kvledger] CommitWithPvtData -> INFO 3c32 [channel] Committed block [744876] with 3 transaction(s) in 29ms (state_validation=4ms block_and_pvtdata_commit=4ms state_commit=19ms) commitHash=[128eff402fae08d58f50e6529e8e9903116374cac557901bad4fd666153c55aa]

此后，我向分类帐查询此特定文档，在beddb中查看，但未将其添加到世界状态或PDC中。

另一件事可疑的是，他的代码块落后于订购者，但他似乎并没有获取它们，他正常地接受查询，甚至提交不使用此PDC的交易。

解决方法

如果八卦层在网络中找不到可以访问此集合的任何其他对等方，则会收到此错误。 检查对等日志中的八卦“成员资格视图”消息。这些消息将说明该对等方知道哪些其他对等方。如果看不到此类消息，请重新启动对等方，以便在日志中看到其他对等方显示在新的“成员资格视图”消息中。

通常这些问题与八卦配置有关-请仔细检查您的配置值：

peer.gossip.bootstrap

peer.gossip.endpoint

peer.gossip.externalEndpoint

并确保对等方可以访问引导对等方地址，并且组织中的其他对等方可以通过端点地址访问此对等方，并且其他组织中的其他对等方可以通过externalEndpoint地址访问此对等方。

一旦您的对等方连接到属于同一集合的另一个对等方，它将协调（检索）在此期间丢失的私有数据。