Database for sequencer in a canton fabric domain

Questions
,
1

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

2

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:

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

1 Like