# ovsdb-server

## 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.
    


* * *