]>
Commit | Line | Data |
---|---|---|
6bb9b060 BP |
1 | <?xml version="1.0" encoding="utf-8"?> |
2 | <database name="ovsdb-server" title="ovsdb-server _Server schema"> | |
3 | <p> | |
4 | Every <code>ovsdb-server</code> (version 2.9 or later) always hosts an | |
5 | instance of this schema, which holds information on the status and | |
6 | configuration of the server itself. This database is read-only. This | |
7 | manpage describes the schema for this database. | |
8 | </p> | |
9 | ||
10 | <table name="Database" title="Databases."> | |
11 | <p> | |
12 | This table describes the databases hosted by the database server, with | |
13 | one row per database. As its database configuration and status changes, | |
14 | the server automatically and immediately updates the table to match. | |
15 | </p> | |
10621d79 BP |
16 | |
17 | <p> | |
18 | The OVSDB protocol specified in RFC 7047 does not provide a way for an | |
19 | OVSDB client to find out about some kinds of configuration changes, such | |
20 | as about databases added or removed while a client is connected to the | |
21 | server, or databases changing between read/write and read-only due to a | |
22 | transition between active and backup roles. This table provides a | |
23 | solution: clients can monitor the table's contents to find out about | |
24 | important changes. | |
25 | </p> | |
26 | ||
27 | <p> | |
28 | Traditionally, <code>ovsdb-server</code> disconnects all of its clients | |
29 | when a significant configuration change occurs, because this prompts a | |
30 | well-written client to reassess what is available from the server when it | |
31 | reconnects. Because this table provides an alternative and more | |
32 | efficient way to find out about those changes, OVS 2.9 also introduces | |
33 | the <code>set_db_change_aware</code> RPC, documented in | |
34 | <code>ovsdb-server</code>(7), to allow clients to suppress this | |
35 | disconnection behavior. | |
36 | </p> | |
37 | ||
38 | <p> | |
39 | When a database is removed from the server, in addition to | |
1b1d2e6d BP |
40 | <code>Database</code> table updates, the server sends |
41 | <code>canceled</code> messages, as described in RFC 7047 section 4.1.4, | |
42 | in reply to outstanding transactions for the removed database. The | |
43 | server also cancels any outstanding monitoring initiated by | |
44 | <code>monitor</code> or <code>monitor_cond</code> requested on the | |
45 | removed database, sending the <code>monitor_canceled</code> RPC described | |
46 | in <code>ovsdb-server</code>(7). Only clients that disable disconnection | |
10621d79 BP |
47 | with <code>set_db_change_aware</code> receive these messages. |
48 | </p> | |
49 | ||
6bb9b060 BP |
50 | <p> |
51 | Clients can use the <code>_uuid</code> column in this table as a | |
52 | generation number. The server generates a fresh <code>_uuid</code> every | |
53 | time it adds a database, so that removing and then re-adding a database | |
54 | to the server causes its row <code>_uuid</code> to change. | |
55 | </p> | |
56 | ||
57 | <column name="name"> | |
58 | The database's name, as specified in its schema. | |
59 | </column> | |
60 | ||
1b1d2e6d BP |
61 | <column name="model"> |
62 | The storage model: <code>standalone</code> for a standalone or | |
63 | active-backup database, <code>clustered</code> for a clustered database. | |
64 | </column> | |
65 | ||
6bb9b060 | 66 | <column name="schema"> |
1b1d2e6d BP |
67 | The database schema, as a JSON string. In the case of a clustered |
68 | database, this is empty until it finishes joining its cluster. | |
6bb9b060 | 69 | </column> |
1b1d2e6d BP |
70 | |
71 | <group title="Clustered Databases"> | |
72 | <p> | |
73 | These columns are most interesting and in some cases only relevant for | |
74 | clustered databases, that is, those where the <ref column="model"/> | |
75 | column is <code>clustered</code>. | |
76 | </p> | |
77 | ||
78 | <column name="connected"> | |
79 | True if the database is connected to its storage. A standalone or | |
80 | active-backup database is always connected. A clustered database is | |
81 | connected if the server is in contact with a majority of its cluster. | |
82 | An unconnected database cannot be modified and its data might be | |
83 | unavailable or stale. | |
84 | </column> | |
85 | ||
86 | <column name="leader"> | |
87 | True if the database is the leader in its cluster. For a standalone or | |
88 | active-backup database, this is always true. | |
89 | </column> | |
90 | ||
91 | <column name="cid"> | |
92 | The cluster ID for this database, which is the same for all of the | |
93 | servers that host this particular clustered database. For a standalone | |
94 | or active-backup database, this is empty. | |
95 | </column> | |
96 | ||
97 | <column name="sid"> | |
98 | The server ID for this database, different for each server that hosts a | |
99 | particular clustered database. A server that hosts more than one | |
100 | clustered database will have a different <code>sid</code> in each one. | |
101 | For a standalone or active-backup database, this is empty. | |
102 | </column> | |
103 | ||
104 | <column name="index"> | |
105 | <p> | |
106 | For a clustered database, the index of the log entry currently | |
107 | exposed to clients. For a given server, this increases | |
108 | monotonically. When a client switches from one server to another in | |
109 | a cluster, it can ensure that it never sees an older snapshot of data | |
110 | by avoiding servers that have <ref column="index"/> less than the | |
111 | largest value they have already observed. | |
112 | </p> | |
113 | ||
114 | <p> | |
115 | For a standalone or active-backup database, this is empty. | |
116 | </p> | |
117 | </column> | |
118 | </group> | |
6bb9b060 BP |
119 | </table> |
120 | </database> |