Provided by: openvswitch-common_3.2.2-0ubuntu0.23.10.1_amd64 bug

NAME

       ovsdb-server - _Server database schema

       Every  ovsdb-server  (version 2.9 or later) always hosts an instance of this schema, which
       holds information on the status and configuration of the server itself. This  database  is
       read-only. This manpage describes the schema for this database.

TABLE SUMMARY

       The  following  list summarizes the purpose of each of the tables in the _Server database.
       Each table is described in more detail on a later page.

       Table     Purpose
       Database  Databases.

Database TABLE

       This table describes the databases hosted  by  the  database  server,  with  one  row  per
       database.  As  its database configuration and status changes, the server automatically and
       immediately updates the table to match.

       The OVSDB protocol specified in RFC 7047 does not provide a way for  an  OVSDB  client  to
       find  out  about  some  kinds  of  configuration changes, such as about databases added or
       removed while a  client  is  connected  to  the  server,  or  databases  changing  between
       read/write  and  read-only due to a transition between active and backup roles. This table
       provides a solution: clients can monitor the table’s contents to find out about  important
       changes.

       Traditionally,   ovsdb-server   disconnects   all   of  its  clients  when  a  significant
       configuration change occurs, because this prompts a well-written client to  reassess  what
       is  available  from  the  server  when  it  reconnects.  Because  this  table  provides an
       alternative and more efficient  way  to  find  out  about  those  changes,  OVS  2.9  also
       introduces the set_db_change_aware RPC, documented in ovsdb-server(7), to allow clients to
       suppress this disconnection behavior.

       When a database is removed from the server, in addition to  Database  table  updates,  the
       server  sends  canceled  messages,  as  described  in  RFC 7047 section 4.1.4, in reply to
       outstanding transactions for the removed database. The server also cancels any outstanding
       monitoring initiated by monitor or monitor_cond requested on the removed database, sending
       the  monitor_canceled  RPC  described  in  ovsdb-server(7).  Only  clients  that   disable
       disconnection with set_db_change_aware receive these messages.

       Clients  can  use  the  _uuid  column  in  this  table  as a generation number. The server
       generates a fresh _uuid every time it adds a database, so that removing and then re-adding
       a database to the server causes its row _uuid to change.

   Summary:
       name                          string
       model                         string, one of clustered, relay, or standalone
       schema                        optional string
       connected                     boolean
       Clustered Databases:
         leader                      boolean
         cid                         optional uuid
         sid                         optional uuid
         index                       optional integer

   Details:
       name: string
              The database’s name, as specified in its schema.

       model: string, one of clustered, relay, or standalone
              The storage model: standalone for a standalone or active-backup database, clustered
              for a clustered database, relay for a relay database.

       schema: optional string
              The database schema, as a JSON string. In the case of a clustered database, this is
              empty  until it finishes joining its cluster. In the case of a relay database, this
              is empty until it connects to the relay source.

       connected: boolean
              True if the database is connected to its storage. A standalone database  is  always
              connected.  A  clustered  database  is connected if the server is in contact with a
              majority of its cluster. A relay database is connected if the server is in  contact
              with  the  relay  source,  i.e.  is  connected  to  the  server  it  syncs from. An
              unconnected database cannot be modified and its data might be unavailable or stale.

     Clustered Databases:

       These columns are  most  interesting  and  in  some  cases  only  relevant  for  clustered
       databases, that is, those where the model column is clustered.

       leader: boolean
              True  if  the  database  is  the leader in its cluster. For a standalone or active-
              backup database, this is always true. For a relay database, this is always false.

       cid: optional uuid
              The cluster ID for this database, which is the same for all  of  the  servers  that
              host  this  particular clustered database. For a standalone, active-backup or relay
              database, this is empty.

       sid: optional uuid
              The server ID for this database, different for each server that hosts a  particular
              clustered  database. A server that hosts more than one clustered database will have
              a different sid in each one. For a standalone,  active-backup  or  relay  database,
              this is empty.

       index: optional integer
              For  a clustered database, the index of the log entry currently exposed to clients.
              For a given server, this increases monotonically. When a client switches  from  one
              server  to another in a cluster, it can ensure that it never sees an older snapshot
              of data by avoiding servers that have index less than the largest value  they  have
              already observed.

              For a standalone, active-backup or relay database, this is empty.