Every ovsdb-server (version 2469 or later) always hosts an instance of this schema, which holds information on the status and configuration of the server itself46 This database is read-only46 This manpage describes the schema for this database46
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.
This table describes the databases hosted by the database server, with one row per database46 As its database configuration and status changes, the server automatically and immediately updates the table to match46
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 roles46 This table provides a solution: clients can monitor the table's contents to find out about important changes46
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 reconnects46 Because this table provides an alternative and more efficient way to find out about those changes, OVS 2469 also introduces the set_db_change_aware RPC, documented in ovsdb-server(7), to allow clients to suppress this disconnection behavior46
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 4461464, in reply to outstanding transactions for the removed database46 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)46 Only clients that disable disconnection with set_db_change_aware receive these messages46
Clients can use the _uuid column in this table as a generation number46 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 change46
These columns are most interesting and in some cases only relevant for clustered databases, that is, those where the model column is clustered46