Fabric 1.1 с внешним CouchDB сохраняет данные и внутри коллег.Зачем? - PullRequest
0 голосов
/ 10 апреля 2019

Я сохраняю файлы в моем регистре с тканью 1.1 и leveldb. Как и ожидалось, из-за этого контейнеры-докеры одноранговых узлов быстро исчерпывают пространство. Я думал, что переход на couchdb решит проблему (она переносит проблему в контейнер couchdb, но я могу справиться с этим), но, к своему удивлению, я проверил, что использование couchdb фактически сохраняет данные в контейнеры couchdb, но это также сохраняет данные внутри коллег! Например, загрузка файла 1,3 МБ в мое приложение, настроенное для использования couchdb, также создает «блочный файл» размером /var/hyperledger/production/ledgersData/chains/chains/mychannel в 1,3 МБ внутри задействованных узлов. Как это может быть? Можно ли отключить это поведение и сохранять данные только в контейнерах? (или смонтированные тома для этих контейнеров), эта ошибка исправлена ​​в новых версиях Fabric ?. Если это невозможно, как я могу настроить большие одноранговые узлы?.

Я знаю, что могу изменить решение для хеш-вложений, сохранять только ссылки на эти хеши в моей книге и хранить данные во внешнем хранилище данных, но я работаю над проектом с этим требованием, и изменение подхода не является возможность.

Спасибо.

1 Ответ

2 голосов
/ 10 апреля 2019

Пир имеет как файловый регистр («цепочка блоков»), так и базу данных состояний, в которой хранится / кэшируется последнее известное значение для любого заданного ключа.

Состояние может быть сохранено либо в goleveldb, либо в CouchDB. Главная книга всегда хранится в файловой системе партнера. (Обратите внимание, что файлы данных goleveldb также хранятся в одноранговой файловой системе).

Местоположение задается с помощью peer.fileSystemPath в core.yaml и значением по умолчанию является /var/hyperledger/production. Для этого вы также можете подключить внешний том, если хотите хранить файлы на хосте, а не внутри файловой системы контейнера.

...