background:
I am developing Hyperledger Fabric Network(v1.1) and are using couchdb.
For continuing operation. It is necessary to persist data go each component(peer, orderer etc..).
Issue:
I don't know what I should persist couchdb's data for continuing operation in production environment.
Question:
(1)Should I persist these data in the below? And, if there is insufficient, please tell me that what I should persist data.
/opt/couchdb/data
/opt/couchdb/etc
(2)If I don't persist these couchdb's data. what will happen? (For example,
querying error,clush the data and difference from block's data).Please tell me.
sincerely.
If you don't persist the CouchDB data, then if you delete or upgrade the container you will lose the data. The good news is that if you have persisted the ledger from your peer, it will rebuild the data in CouchDB on startup but of course this will delay how long it takes for the peer to be able to serve any type of request.
The CouchDB image uses /opt/couchdb/data as the volume where it stores the data so you'll want to mount an external volume there.
Related
I'm using hyperledger fabric 2.0. I have successfully ran chaincodes on the fabric network and my data is storing on the couch db. I'm viewing the data stored on the couch DB using
But I want to prove to my faculty that the data is being stored on the transaction log too. Is there any way to view the data that is stored on the transaction log?
If I understand it correctly you basically want to retrieve the ledger data while you're already able to access the world state (couch-db).
One way could be, depending upon what SDK you're using, you can use an instance of 'Channel' and run queries against the ledger data.
Following are the methods available in NodeSDK which could help you to run queries against your ledger:
queryBlock
queryBlockByHash
queryBlockByTxID
queryTransaction
I am pretty new to Hyperledger Fabric. I read a bit about gossip protocol but did not get a clear idea. Please help me with these questions.
How could a node recover old data from a channel after a crash?
What if the channel had only a single peer node and this node crashed?
A peer can get old data from a channel from other peers when it recovers. Another way, if you are pointing to a volume were it is storing the ledger information and all its credentials when it recovers can read it from there, thats why it is recomended to use a persistance storage.
Thats bad practice as you are not going to offer High availability, so without peers you are going to stop giving service and your ledger is not going to be available. But, as you can read from the documentation, you can recover from the orderer.
All ledger, blocks etc stores in below particular location in the peer container
/var/hyperledger/production
All you have todo is create a backup volume and map it
Sample snippet below
Create Volume:
volumes:
backup_peer1:
Add Volume to container:
- backup_peer1:/var/hyperledger/production
Reading the docs ,I understand that there are two options to maintain the world state LEVELDB and COUCHDB .
In case of LevelDB ,"LevelDB is the default state database embedded in the peer node" I am assuming it is local to a peer . As in every peer has a copy of LevelDB running .
In case of CouchDB there is a separate container to run it ,and all the peers can use it to execute transactions (all the peers see the same data )
In the first case for LevelDB ,how is the version of the data synced across all the peers?
Is this a plug and play feature , Can I for
example use an ETCD cluster ,instead of CouchDB ?
It's actually the same for both LevelDB and CouchDB. The database is basically used as a persistent last know value store. It can be rebuilt at any time for the ledger (the block chain) which is actually what is replicated across all peers via the ordering service
EDIT To clarify, peers receive blocks from the orderer. Each peer than validates the transactions in each block and for each valid transaction it will update the state in the database. In the case of LevelDB, it's an embedded call and in the case of CouchDB the peer communicates with CouchDB via the CouchDB HTTP API. Of course it also writes the blocks to the ledger files on disk as well.
It's not plug and play ... only LevelDB and CouchDB are currently supported. The codebase itself supports adding additional databases, but someone would need to implement the support in the actual codebase.
Suppose I have started fabric with two peers in a single organization. After running my application/rest-server through composer and submitting transactions. I was able to make changes in the values of Couchdb instance of peer1 by going on the address http://localhost:6984/_utils/#/_all_dbs. Now, the two peers are not in sync with each other - application should throw some error but it isn't. Mostly, because it is getting data just from the first peer i.e. peer1.
So, firstly how can I get data from multiple peers - if I want to get data from peer2 aswell?
Secondly, why it is getting data from state database not from ledger?
Thirdly, data should remain in sync even after committed how can I configure this? if some peer tampered its database it should be notified. I have read consensus part and got that it is for the correct order of transactions and blocks but what if someone tampered with the state database?
If you're able to change the entries in state database for 1 peer, with a strong endorsement policy such as AND, your transactions will fail validation because of difference in the data for the two peers. This is one of the most important pros of decentralized network.
State database and the Ledger are not same thing. this should help you in understanding the differences between the both.
Every participating member of a Hyperledger Fabric network is a known entity per se (since Fabric being a permissioned blockchain). Said that, a change in state database of a single peer will again lead to scenario #1 above, where the Read/Write sets in a transaction won't match for multiple peers (as their state databases contain different values of an asset). This will lead to invalidation of the transactions. Now it just becomes a question of how can the network know about the corrupted peer(and subsequent state db). There can be multiple solutions for the same.
But most importantly, Fabric being a permissioned blockchain network, the state databases must be very strictly access protected and authorized outside of the network too.
the fact that you modified the world db doesn't mean anything. any changes you make to that database are not a representation of the ledger.
The ledger itself, the blocks and the transactions they contain are stored in a physical file. The world state db is simply a collection of the current state for each asset. This is a good design because an application will not care about every state change an item went through, it will only care about the current state. The world state db can easily be recreated whenever there is a need for it.
Now, you should not make any changes directly to to the world state db, because that's useless. Any change needs to go through the proper process, via a proposal submitted by a peer which then goes through the orderer. Only when everything is followed, does a change go onto the ledger and get synced with every peer and the world state db will reflect that.
In terms of where you should get the data, the answer is that it doesn't matter. Each peer will have an exact copy of the ledger so if you get data from peer 1 or 2 is irrelevant, it will be the same thing.
Again, just because you changed the world state, that doesn't mean anything, the ledger is untouched, but your application reports the current state from the world state db, which is now incorrect because of your change.
Ok, we have a commiting peers - running containers. As i assume, there is an LevelDB or CouchDB database server in containers, that stores world state. As far as i know, data must be available only from blockchain. Why can't I just connect to that database throught container and see the data or change it? If it protected, tell me, please, how protection is creating.
By default, the CouchDB container cannot be accessed from the outside--only the attached peer is allowed to access it. Also, it can be set up with name/password login.
LevelDB does not have its own container.