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.
The database's name, as specified in its schema.
The storage model: standalone
for a standalone or
active-backup database, clustered
for a clustered database,
relay
for a relay database.
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.
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.
These columns are most interesting and in some cases only relevant for
clustered databases, that is, those where the
column is clustered
.
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.
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.
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.
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 less than the
largest value they have already observed.
For a standalone, active-backup or relay database, this is empty.