-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Validator Config (use_tx_tables=0)
Validators generally should not be using transaction.db
.
Stock nodes and validators are both referred to as "p2p nodes."
In most payment processing systems (Visa, Mastercard, Amex, etc.) there is decoupling between reporting and transaction processing. The benefit is better optimization and simplification of both reporting and tx processing. Typically reporting is also run on a different machine. Heavy RPC traffic then has no impact on the p2p nodes. The second reason is scaling. There is a ton of redundant work happening when every node builds ledgers, processes txs, and stores data. The reporting servers can share data in a distributed cluster such as Cassandra or similar. Only one server needs to write to Cassandra; the others can all read. You can dynamically scale up or down by adding/removing reporting servers and adding/removing Cassandra nodes.
[ledger_tx_tables]
is configuration information about the transaction database. The transaction database is a relational database that is relied upon for tx
and account_tx
calls. This database can (and has been) implemented in various SQL databases (like PostgreSQL). p2p nodes use SQLite for this.
In that section, there is a parameter use_tx_tables
. When running in p2p mode, setting this parameter to 0
(it defaults to 1
) disables writing to the transaction database, which improves throughput but disables the tx
and account_tx
RPCs.