Priority

MUST

Type of change request

FIX

Epic link
Status

DRAFT

Target release

1.2.3

Vision: 

According to the information from the infrastructure team, there is a risk in case if Iroha network is running in a centralized environment – if more than f nodes will malfunction, the network operations will be stopped. 

To mitigate the risk, we have set up a backup for the block storage of each peer. However, it brings another issue – potential high startup time in case of a big amount of blocks. Also, backup of blockstore is regular, but the data from the last backup to the last moment of the working network may be lost.

Therefore, there are several possible solutions:

  1. Start using "reuse WSV" flag and configure backing up of WSV in database
    1. Continuous mirroring of the database data to external hosts. In that case, we will need to fix the issue if the WSV is "in front of" current blockstore – Iroha should sync lost blocks from other peers in the network and then proceed with startup sequence and reusing WSV.
    2. Regular backups of data together with the backup of blockstore. 
  2. Improve the performance of DB operations
    1. For "read data from blockstore to WSV" operation, disable indexing during the operation and enable it at the end only (it will require disabling data validation, also)
    2. For "store blockstore in DB" feature, use more appropriate storage for blocks, instead of raw binary data. The current solution makes PostgreSQL work much slower on a big amount of blocks stored in it.
  3. Store blocks inside the DB and backup DB only (using it as a single place of data storage)
  4. Create a special "sync" type of Iroha node, when the node not taking part in consensus but synchronizes data with main nodes; it can also answer queries from applications.
  5. Replace current Postgres storage by more flexible and in-memory oriented "RocksDB"; then configure the backup of its data according to the selected strategy.

Tasks

key summary type created updated due assignee reporter priority status resolution

JQL and issue key arguments for this macro require at least one Jira application link to be configured


Template data

Priorities MUST SHOULD COULD WON'T

Change request type FEATURE BUG FIX

Status BACKLOG WORK IN PROGRESS DONE


  • No labels