Table of Contents
List of Examples
A virtual DB will expose the same front DB api however, it will backed by many real DB. This means that a virtual DB URL translates to many real DB URLs. This virtual layer also enables us to use the real dbs in multiple ways such as: parallel, failover(hotswap) and round-robin. Therefore: each virtual DB URL with associated real dbs and a way to use(mode) it's real dbs must be specified.
The implemented modes are:
Use the first URL; if it fails, take the next URL and redo the operation.
Use all the URLs in the virtual DB URL set. Fails if all the URLs fail.
Use the next URL each time; if it fails, use the next one, redo operation.
When choosing the db virtual mode, be sure that there is a full compatibility between the DB operations you want to do (inserts, updates, deletes,...) and the relation (if any) between the real DB URLs you have in the set - can be completely independent, can be nodes of the same cluster, or any other combination.
For each set (or new virtual DB URL), the capabilities are automatically calculated based on the capabilities provided by the real DB URLs from the set. A logical AND is done for each cabability over all the URLs in the set. Shortly, in order for the virtual URL to provide a certain capability, ALL its real URLs must provide that capability.
Note that starting with version 2.2 db_virtual supports async_raw_query and async_raw_resume functions currently implemented only by the mysql database engine.
When an operation from a process on a real DB fails: it is marked (global and local CAN flag down) its connection closed Later a timer process (probe): foreach virtual db_url foreach real db_url if global CAN down try to connect if ok global CAN up close connection Later each process: if local CAN down and global CAN up if db_max_consec_retrys * try to connect if ok local CAN up
Note *: there could be inconsistencies between the probe and each process so a retry limit is in order. It is reset and ignored by an MI command.
The following modules must be loaded before this module:
At least one real DB module.
Multiple value parameter used for virtual DB URLs declaration.
Example 1.1. Set
... modparam("group","db_URL","virtual://set1") modparam("presence|presence_xml", "db_URL","virtual://set2") modparam("db_virtual", "db_URLs", "define set1 PARALLEL") modparam("db_virtual", "db_URLs", "mysql://opensips:opensipsrw@localhost/testa") modparam("db_virtual", "db_URLs", "postgres://opensips:opensipsrw@localhost/opensips") modparam("db_virtual", "db_URLs", "define set2 FAILOVER") modparam("db_virtual", "db_URLs", "mysql://opensips:opensipsrw@localhost/testa") ...
Time interval after which a registered timer process attempts to check failed(as reported by other processes) connections to real dbs. The probe will connect and disconnect to the failed real DB and announce others.
Default value is 10 (10 sec).
After the timer process has reported that it can connect to the real db, other processes will try to reconnect to it. There are cases where although the probe could connect some might fail. This parameter represents the number of consecutive failed retries that a process will do before it gives up. This value is reset and suppressed by a MI function(db_set).
Default value is 10 (10 consecutive times).
Example 1.3. Set
... modparam("db_virtual", "db_max_consec_retrys", 20) ...
Return information about global state of the real dbs.
MI FIFO Command Format:
Sets the permissions for real dbs access per set per db.
Sets the reconnect reset flag.
db_set 3 2 0 1 means:
MI FIFO Command Format:
db_set 3 2 0 1 _empty_line_