Database for sequencer in a canton fabric domain

Hi team,

I am working on the examples e01-fabric-domain. In the sequencer configuration there is a postgres database defined.

canton.sequencers.fabricSequencer1 {
    public-api {
        port = 3000
        address = "0.0.0.0"
    }
    admin-api {
        port = 4000
        address = "0.0.0.0"
    }
    storage {
        type = postgres
        config {
            dataSourceClass = "org.postgresql.ds.PGSimpleDataSource"
            properties = {
                serverName = "pg.database1"
                portNumber = "5432"
                databaseName = "db"
                user = "user"
                password = "pass"
            }
            numThreads = 20
        }
    }
    sequencer {
        type = "fabric"
        config {

(This setup is quite similar to a database domain. The difference is just the the sequencer.type is database instead of fabric.)

Questions about this database:
(1) What is the purpose of this database?
(2) Any impact, such as functionality or performance, if we do not use a database here?

I encountered a challenge that when I used a database for a new sequencer, There were chances some conflict on the data (read from the log) and the setup failed. The problem was gone if the database is not used. I am still studying the log but the questions above may give me some hints.

Thanks.

kc

Hi @kctam

You can understand the Canton Fabric Sequencer node to be a translation system which can interpret the payload on Fabric and translate it into Canton specific message that is independent of the underlying DLT layer used.

Now, participants (and other domain members) subscribe to the sequencer using their individual counters:

github.com

digital-asset/canton/blob/e2e9c85712caba07a27f06952af2f1ca81b17444/community/common/src/main/protobuf/com/digitalasset/canton/domain/api/v0/sequencer_service.proto#L33

      
        

            
rpc SendAsync (SubmissionRequest) returns (SendAsyncResponse);
            

            
// Submit a send request to the sequencer for sequencing asynchronously exactly like SendAsync, except that this
            
// meant to be used only by unauthenticated members for very specific operations that do not require authentication
            
// such as requesting that a participant's topology data gets accepted by the topology manager
            
rpc SendAsyncUnauthenticated (SubmissionRequest) returns (SendAsyncResponse);
            

            
// Establishes a stream with the server to receive sequenced events from the domain after the given
            
// counter. The delivered events will have a sequential counter and monotonically increasing timestamp.
            
// TBD: Message TTL - How far back should it go when the participant initiate a subscription ?
            
rpc Subscribe (SubscriptionRequest) returns (stream SubscriptionResponse);
            

            
// Establishes a stream with the server to receive sequenced events exactly like Subscribe, except that this is
            
// supposed to be used only by unauthenticated members similarly to SendAsyncUnauthenticated
            
rpc SubscribeUnauthenticated (SubscriptionRequest) returns (stream SubscriptionResponse);
            

            
// Allows a member to acknowledge that they have read all events up to and including the provided timestamp,
            
// and that they will never re-read these events again. This information is currently only used for informational
            
// purposes and to provide a watermark for which it is safe to prune earlier events from the sequencer data stores.
            
// There is no requirement for every event to be individually acknowledged, and in fact callers are encouraged to
            
// only periodically record acknowledgements (at an interval of minutes is expected to be more than sufficient for
        
      
    

Therefore, the DLT sequencer node needs to keep track of all this information, in addition to other, node specific information.

If you run your sequencer node without persistence, the data (including the initialisation) won’t survive a restart and the node won’t function anymore.

Therefore, for any production setting, you need to provide a Postgres database for the node to store data that does not belong onto the Fabric chain. The in-memory stores are really just there for testing and demos.

I hope this make it clear.

With respect to your failing setups: there was a race condition in 2.1.x sequencer initialization that could lead to failures during bootstrapping of a domain. This has been fixed in 2.2.0.

Cheers,
Ratko