Database Worker heading-link-icon

The database worker is the sole worker with access to the database (apart from the crypto worker A worker that manages the cryptographic materials of the Corda cluster and virtual nodes. It connects to any Hardware Security Modules (HSM) used to hold private keys, as well as database(s) used as a software HSM to hold wrapped and encrypted private keys. ), which has its own dedicated database. As a result, the activities carried out within the database worker pertain to the database.

The database worker is responsible for handling and serving persistence requests originating from various Corda worker types, such as the flow worker A worker that runs the CorDapp application code and translates flow API calls into function requests to the relevant workers. The flow workers are designed to share work between themselves and to record checkpoints at each stage of the application's progress, so that in the event of worker failure, the operations can be retried. or the MGM Membership Group Manager. May also be referred to as the Network Manager. It is a virtual node and Corda identity that acts as a central registrar for group membership. worker. The flow Communication between participants in an application network is peer-to-peer using flows. persistence requests metrics presented in this section measure:

  • The time taken to handle the flow persistence requests.
  • The time the flow persistence requests remained on Kafka The means by which Corda workers communicate, acting as a central message bus between the worker processes. , from the moment they were added by flows until they were received by the database worker (Kafka lag).

The ledger persistence requests metrics measure the time needed to execute the ledger transaction database requests against the database.

The membership persistence requests metrics presented in this section measure:

  • The time taken to handle the membership persistence requests, which included acquiring a connection and executing a transaction.
  • The time taken to execute a transaction, which allows you to compare against the previous metric to determine the percentage of time spent acquiring connections vs executing transactions.

Additionally, there are background processes occurring within the database worker, namely the reconciliations. The reconciliations are responsible for ensuring the alignment of Kafka compacted topics with the database (the database being the primary source of truth). The reconciliations run at regular intervals, loading in-memory database and Kafka records, identifying the differences, and synchronizing the Kafka state to match that of the database. The reconciliations metrics listed in this section measure:

  • The time taken for a reconciliation run to complete.
  • The number of reconciled records per reconciliation. This could be useful to identify cases where a reconciliation run could be over-reconciling things (for example, up-to-date Kafka records could be re-published from the database when they shouldn’t).
MetricTypeTagsDescription
corda_db_entity_persistence_request_time_secondsTimer
  • entityRequest_type
  • entityRequest_outcome
The time it takes to process an entity An organization or individual that participates in one or more application networks that can provide attestation that they are whom they claim to be. persistence request, from the moment the request is received from Kafka.
corda_db_entity_persistence_request_lag_secondsTimer
  • entityRequest_type
The lag between the flow putting the entity persistence request to Kafka and the EntityMessageProcessor.
corda_ledger_persistence_time_secondsTimer
  • flowId
  • ledger_type
  • operation_name
The time it takes to execute ledger transaction database request against the database.
corda_membership_persistence_transaction_time_secondsTimer
  • operation_name
  • group
  • virtualnode
The time it takes to execute membership persistence transactions. Excludes time spent acquiring a database connection.
corda_membership_persistence_handler_time_secondsTimer
  • operation_name
  • group
  • virtualnode
The time it takes to execute membership persistence handlers. Includes time taken to get database connection and execute the transaction.
corda_db_reconciliation_run_time_secondsTimer
  • reconciliation_reconciler_type
  • reconciliation_outcome
The time needed for a full reconciliation run.
corda_db_reconciliation_records_countCounter
  • reconciliation_reconciler_type
  • reconciliation_outcome
The number of reconciled records for a reconciliation run.
Tags:
  • entityRequest.type: The type of persistence request.
  • entityRequest_outcome: The outcome of processing a request (SUCCESS, FAILURE).
  • flowId: The flow ID to correlate with the flow.
  • ledger_type: It can be UTXO Unspent Transaction Output. The unspent output of a cryptocurrency transaction, representing the amount of digital currency that has not been spent and is available for use in future transactions. or CONSENSUAL.
  • operation_name: The MGM persistence request name/type.
  • group: The membership group A logical grouping of multiple Corda identities, which communicate and transact with each other using a specific set of CorDapps. within which peer-to-peer communication happens.
  • virtualnode: The virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. identity.
  • reconciliation_reconciler_type: The type of reconciler that run, for example, CPI metadata, virtual node metadata.
  • reconciliation_outcome: The outcome of a reconciliation run (SUCCESS or FAILURE).
Previous
Crypto Worker
Next
Flow

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.