ovsdb-server - _Server database schema
Every
ovsdb-server (version 29 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
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
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 29 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 414, 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
- name
- string
- model
- string, either clustered or standalone
- schema
- optional string
- Clustered Databases:
- connected
- boolean
- leader
- boolean
- cid
- optional uuid
- sid
- optional uuid
- index
- optional integer
- name: string
- The database’s name, as specified in its schema
- model: string, either clustered or standalone
- The storage model: standalone for a standalone or active-backup
database, clustered for a clustered 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
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
- connected: boolean
- True if the database is connected to its storage A standalone or
active-backup database is always connected A clustered database is
connected if the server is in contact with a majority of its cluster An
unconnected database cannot be modified and its data might be unavailable
or stale
- leader: boolean
- True if the database is the leader in its cluster For a standalone or
active-backup database, this is always true
- 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 or
active-backup 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 or
active-backup 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 or active-backup database, this is empty