wow Daniel, you've been busy ;) nice!!!!

On Tue, Mar 27, 2012 at 2:44 PM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: Module: sip-router Branch: master Commit: 201fc2d600e48fbb717531c79013c1b971f82d76 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=201fc2d… Author: Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> Committer: Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> Date: Tue Mar 27 14:38:57 2012 +0200 db_cluster: new module for generic database clustering - the module allow to group several DB connections and perform commands over them, based on policies such as round robin, serial try or parallel execution - any kind of db connection can make part from a cluster - example use case: write in parallel to two databases and do round robin read from them - the module is a middle layer between modules and databases, reusing existing db connectors. A module that wants to use such cluster, just have to set the db_url to "cluster://clusterid" - the module allow definition of multiple clusters - see README for more details - todo: enable/disable connections at runtime and via rpc --- modules_k/db_cluster/Makefile | 15 + modules_k/db_cluster/README | 162 +++++++++ modules_k/db_cluster/db_cluster_mod.c | 112 ++++++ modules_k/db_cluster/dbcl_api.c | 437 ++++++++++++++++++++++ modules_k/db_cluster/dbcl_api.h | 142 ++++++++ modules_k/db_cluster/dbcl_data.c | 479 +++++++++++++++++++++++++ modules_k/db_cluster/dbcl_data.h | 89 +++++ modules_k/db_cluster/doc/Makefile | 4 + modules_k/db_cluster/doc/db_cluster.xml | 37 ++ modules_k/db_cluster/doc/db_cluster_admin.xml | 167 +++++++++ 10 files changed, 1644 insertions(+), 0 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=201… _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

daniel, i gave db_cluster module a try. i configured serial connections and it worked fine: when i stopped mysql server behind the higher priority connection, queries started to work over the lower priority connection. there is one thing that bothers me. when higher priority connection is not available, i get these kind of error to syslog even when queries succeed over the lower priority connection: Mar 29 20:24:52 sip /usr/sbin/sip-proxy[18966]: ERROR: db_mysql [km_dbase.c:122]: driver error on query: Can't connect to MySQL server on '192.98.102.13' (115) Mar 29 20:24:52 sip /usr/sbin/sip-proxy[18966]: ERROR:<core> [db_query.c:156]: error while submitting query it would be nice if those error messages could somehow be suppressed when one of the connections is still operational and the queries actually succeed. someone may namely run such incomplete cluster many hours and during that time syslog will be filled with those (confusing) error messages.

Perhaps would be faster either to extend domain(s) to detect DB API version and use the one available or enhance domain(k) to offer same things as domain(s). AFAIK for the second, its about having a domain id in domain table and eventually loading domain attributes.

On 03/27/2012 03:44 PM, Daniel-Constantin Mierla wrote: Hello Daniel, I have a few questions regarding the db_cluster module and especially the way it deals with errors: For serial operation , lets consider two handlers DB1 and DB2 with the same priority. For the first write operation DB1 lets presume that itfails so the insert is done on DB2 (network congestion, mysql deadlock etc). But for a serial select the first DB1 is chosen (I looked thru the code and I see no ways of caching the initial error) and this means that the info returned from DB1 (it might be insert_update or update so info might be also present in DB1). How does the module handle this? Same scenarios and question I think it applies with round-robin mode as well. The way we do this in p_usrloc is by keeping a error counter per each handler that is associated with a state (on -off) and a timestamp (when it failed). This info can be used to disable usage of the DB handler( and later put the handler in Write-Only mode until the data is synchronized )

Cheers, Marius _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev