About -> News -> Virtual DB
Virtual DB module as DB conn mixer
Why a virtual db module?
Until now all modules requiring db support had only one (real) db_url connection and it was bad if that connection went down.
Here is where virtual db module comes in:
The real connections are handled transparently to the module using the virtual url. Now if the current real connection goes down the virtual db_url will just switch to a new one transparently to the module, giving uninterrupted db access.
The virtual url could just as well use all the real connections at the same time . Ex: when an insert operation takes place it will insert in all the real dbs.
Yet another mode would be to use the real dbs in a round-robin fashion maybe for load-balancing. This could be used to spread queries, inserts across multiple db servers.
What if i don't want the module to use a real db at runtime?
There is MI support to get the state information for all real dbs (per virtual url).
The module also provides a MI function to set the state(enabled/disabled) for each real db (per virtual url).
What happens when a connection fails?
If a real connection fails it will be marked globally and closed. The module that uses it will not spent time trying to reconnect and will not block waiting for timeout.
A separate timer process will probe the real url. If is succeeds connecting, the connection will be marked globally and considered for reconnection by each process that uses it.
So, the virtual db module provides means to: