Welcome to docs.opsview.com

Using a read-only database

In Opsview 4.6.3, we added the ability to use a separate, read-only, database, for certain REST related database queries. This will, for the most part, increase the responsiveness of the main REST API calls that Dashboard uses, and reduce the load on the master database.

Here, we assume you have already replicated at least the opsview and runtime databases.

You'll need to make sure that the opsview and nagios users exist on the slave MySQL database server, and have select access to the opsview and runtime databases, respectively. You should allow them to connect from the Opsview master database server. For example,

CREATE USER 'opsview'@'masterserver' IDENTIFIED BY 'password';
GRANT SELECT ON opsview.* TO 'opsview'@'masterserver';
CREATE USER 'nagios'@'masterserver' IDENTIFIED BY 'password';
GRANT SELECT ON runtime.* TO 'nagios'@'masterserver';

/usr/local/nagios/etc/opsview.defaults has database related “_ro_” variables. Copy these to opsview.conf and change them to point to the slave MySQL server. The “opsview_ro_” variables are for the opsview user, and the “runtime_ro_” variables are for the nagios user. Any variables that aren't copied into opsview.conf or changed will default to their respective values from the non-read-only database. Be sure to double quote the variable values (see the other database related values around that area in opsview.defaults for some examples). You can obtain the encrypted versions of the passwords by running /usr/local/nagios/bin/opsview_crypt.

Restart opsview-web: “service opsview-web restart”. Dashboard and other parts of Opsview should now be using the slave MySQL database for most status views.


If Opsview doesn't start back up after a restart, check that you've changed the values of the correct “_ro_” variables in opsview.conf.