Main.News0035 History

Hide minor edits - Show changes to markup

April 25, 2013, at 03:04 PM by razvancrainea -
Added line 1:

(:redirect About/News0035 quiet=1:)

July 31, 2009, at 10:26 AM by bogdan -
Changed lines 1-40 from:

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: 
		it provides to other modules a (virtual) db_url that maps multiple (real) db_urls to real dbs.

	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.
	This mode is called failover and can be used for write and read operations.

	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.
	This mode is called parallel and makes sence for write operations(insert, update, delete).

	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.
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id226415

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).
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id228157

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.
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id227167

So: The virtual db module provides means to:

	create virtual urls
	populate them with many real db urls
	get state info about real connection
	enable or disable their use
	reconnect failed connections
to:

Main -> 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:
it provides to other modules a (virtual) db_url that maps multiple (real) db_urls to real dbs.

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.
This mode is called failover and can be used for write and read operations.

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.
This mode is called parallel and makes sense for write operations(insert, update, delete).

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.

Find more at : http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id226415

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).

See: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id228157

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.

See: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id227167

So, the virtual db module provides means to:

  • create virtual urls
  • populate them with many real db urls
  • get state info about real connection
  • enable or disable their use
  • reconnect failed connections
July 31, 2009, at 10:22 AM by bogdan -
Added lines 1-41:

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: 
		it provides to other modules a (virtual) db_url that maps multiple (real) db_urls to real dbs.

	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.
	This mode is called failover and can be used for write and read operations.

	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.
	This mode is called parallel and makes sence for write operations(insert, update, delete).

	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.
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id226415

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).
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id228157

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.
	see: http://www.opensips.org/html/docs/modules/devel/db_virtual.html#id227167

So: The virtual db module provides means to:

	create virtual urls
	populate them with many real db urls
	get state info about real connection
	enable or disable their use
	reconnect failed connections

Page last modified on April 25, 2013, at 03:04 PM