#hyperledger-fabric #hyperledger
#hyperledger-fabric #hyperledger
Вопрос:
У меня возникла проблема с сетью 1.4.6 Fabric Network с сетью (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, namespace: chaincode, collection: collectionTestResults, hash: ca65f8ed487f7e06201f25a7e0872c522afcb54c1c64c137cec8ef1d31e56d6d
txID: 3032cc2c4ce4702ef1ec0da28ca7e5a0bd4b2c4604915704ae63fc9d8342c138, seq: 2, namespace: chaincode, collection: collectionTestResults, 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]
После этого я запрашиваю реестр для этого конкретного документа, заглянул в couchdb, но он не добавлен в мировое состояние или в PDC.
Еще одна подозрительная вещь заключается в том, что его блоки сильно отстают от исполнителя заказа, но он, похоже, не извлекает их, он нормально принимает запросы и даже совершает транзакции, которые не используют этот PDC.
Комментарии:
1. Как ваша конфигурация PDC?
2. * Конфигурация коллекции PDC: { «name»: «collectionName», «policy»: «OR(‘Org-SP.member’)», «requiredPeerCount»: 0, «maxPeerCount»: 3, «blockToLive»: 0, «memberOnlyRead»: true } Этот конкретный узел является привязанным узлом Org-SP.
Ответ №1:
Вы получите эту ошибку, если уровень сплетен не сможет найти других одноранговых узлов в сети, которые имеют доступ к этой коллекции. Проверьте журналы одноранговых узлов на наличие сообщений gossip «Просмотр членства». В этих сообщениях будет указано, какие другие одноранговые узлы известны этому одноранговому узлу. Если вы не видите таких сообщений, перезапустите одноранговый узел, чтобы вы могли видеть в журналах, какие другие одноранговые узлы отображаются в новых сообщениях «Просмотр членства».
Обычно эти проблемы связаны с конфигурацией gossip — дважды проверьте значения вашей конфигурации на:
peer.gossip.bootstrap
peer.gossip.endpoint
peer.gossip.externalEndpoint
И убедитесь, что одноранговый узел может получить доступ к адресам одноранговых узлов начальной загрузки, и что другие одноранговые узлы в организации могут получить доступ к этому узлу через адрес конечной точки, и что другие одноранговые узлы в других организациях могут получить доступ к этому узлу через адрес externalEndpoint.
Как только ваш одноранговый узел установит соединение с другим одноранговым узлом, принадлежащим к той же коллекции, он согласует (извлекает) личные данные, которые были пропущены в течение этого периода.
Комментарии:
1. Привет, Дэйв. Большое спасибо. В этом случае у нас есть большая проблема, заключающаяся в том, что в организации есть только один одноранговый узел. Я знаю, что у нас должно быть больше, но сейчас это главная проблема. Я хотел бы знать, можно ли что-нибудь сделать, чтобы «игнорировать» потерянные данные pvt и продолжать работать оттуда, потому что в текущем состоянии ни одна транзакция фактически не передается в данные реестра / pvt на этом узле.
2. Вы правы, у вас должно быть не менее двух одноранговых узлов на организацию для избыточности и HA. Имеют ли какие-либо одноранговые узлы в других организациях доступ к той же коллекции? Если это так, то этот одноранговый узел все еще может получить от них личные данные.
3. Обратите внимание, что транзакции фиксируются, просто личные данные не найдены или сохраняются вместе с транзакцией. Если личные данные недоступны на других одноранговых узлах, вы также можете «повторно связать» личные данные с ключом, выполнив «слепую запись» (запись без предварительного чтения ключа) в цепном коде для сброса ключа личных данных.
4. Привет, Дэйв. Да, к сожалению, у нас нет другого однорангового узла с доступом к коллекции. Но для этой второй части новые транзакции не фиксируются, потому что они используют один и тот же PDC, и я не понимаю, почему после выполнения цепного кода он просто печатает то же сообщение, которое я опубликовал изначально. У нас есть другой канал, который также использует PDC на этом узле, который в порядке (мы можем видеть сообщение журнала CommitWithPvtData для каждой транзакции), но для этого канала, который потерял данные на pdc, время ожидания новой транзакции всегда истекает. Не могли бы вы предоставить мне более подробную информацию об этом подходе «слепой записи»?
5. В сообщении, которое вы опубликовали, просто говорится, что одноранговый узел попытался получить личные данные. Он будет пытаться в течение 60 секунд (по умолчанию), прежде чем отказаться и совершить транзакцию без личных данных. Любой вызов chaincode, который пытается прочитать недостающие личные данные, завершится неудачей. Чтобы исправить слепую запись, напишите новую функцию chaincode, которая вызывает PutPrivateData (коллекция, ключ, значение), не читая ее сначала, предполагая, что в вашем клиентском приложении все еще есть личные данные для перезаписи.