oracular (5) ovsdb-server.5.gz

Provided by: openvswitch-common_3.4.0-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.