[OpenSIPS-Users] Opensips presence active-active cluster in 2.4.7

Thu Jun 25 04:36:08 EST 2020

Hi Forum Members,

We have successfully brought of Federated opensips presence cluster and now focusing on getting Active-Active Configuration with shared DB (in each region) working for HA scenario.

We are facing some basic issues and would like to hear if we are missing something very basic. We are writing this mail after some long sessions of debugging.

Presence related configuration:

modparam("presence","server_address","sip:sa at 10.207.232.168:5060")
modparam("xcap|presence|clusterer", "db_url","mysql://bhanu:WElcome12#@10.207.232.168/opensips")
modparam("presence_xml", "force_active", 1)
modparam("presence", "fallback2db", 1)
modparam("presence", "cluster_id", 1)
modparam("presence", "cluster_federation_mode", 1)
modparam("presence", "cluster_sharing_tags", "A=active")
#modparam("presence", "cluster_sharing_tags" ,"B=backup")
modparam("presence", "cluster_pres_events" ,"presence, dialog;sla, message-summary")
modparam("presence", "db_update_period", 1)
#modparam("presence", "clean_period", 10)
modparam("presence", "active_watchers_table", "active_watchers")

Issue 1: Publish on one server(Server A) results in cluster replication on other server(Server B). Handle_replicated_publish method is invoked in Server B, however the below error is seen, as server B is also inserting the entry to presentity table, which seems wrong. Is it a race scenario? If yes we don't how to mitigate it. We have the shared DB outside both opensips servers running.

Logs:

Jun 25 00:17:38 [18288] DBG:presence:handle_replicated_publish: Updating presentity
Jun 25 00:17:38 [18288] DBG:presence:update_pres_etag: etag = a.1593058326.29320.3.1
Jun 25 00:17:38 [18288] DBG:presence:update_presentity: inserting 8 cols into table
Jun 25 00:17:38 [18288] CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry '1000-10.207.232.168-presence-a.1593058326.29320.3.1' for key 'presentity.presentity_idx'
Jun 25 00:17:38 [18288] ERROR:core:db_do_insert: error while submitting query
Jun 25 00:17:38 [18288] ERROR:presence:update_presentity: inserting new record in database
Jun 25 00:17:38 [18288] DBG:presence:next_turn_phtable: new current turn is 1 for <sip:1000 at 10.207.232.168>
Jun 25 00:17:38 [18288] ERROR:presence:handle_replicated_publish: failed to update presentity based on replicated Publish
Jun 25 00:17:38 [18288] ERROR:presence:handle_replicated_publish: failed to handle bin packet 101 from node 2

Issue 2: Active Watcher table is not getting update with entry. Not able to conclude is it a delay in writing the cache entry to DB or something else. If it is delay to write to db, not sure if there are any parameters available to make this entry faster (to take of server going down - HA)

Also in one case, we thought even though active_watchers table did not had an entry, opensips will be able to operate with cache values, but when replicated publish is received, seeing this log,

Logs:

Jun 25 00:13:16 [29319] DBG:presence:handle_replicated_publish: Updating presentity
Jun 25 00:13:16 [29319] DBG:presence:search_phtable_etag: pres_uri= sip:1001 at 10.207.232.168, event=1, etag= a.1593058321.18289.1.0
Jun 25 00:13:16 [29319] DBG:presence:search_phtable_etag: found etag = a.1593058321.18289.1.0
Jun 25 00:13:16 [29319] DBG:presence:update_presentity: pres <sip:1001 at 10.207.232.168> my turn is 1, current turn is 1
Jun 25 00:13:16 [29319] DBG:presence:update_pres_etag: etag = a.1593058321.18289.3.1
Jun 25 00:13:16 [29319] DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected
Jun 25 00:13:16 [29319] DBG:presence:get_subs_db: querying database table = active_watchers
Jun 25 00:13:16 [29319] DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected
Jun 25 00:13:16 [29319] DBG:core:db_new_result: allocate 48 bytes for result set at 0x7fe80282a240
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: 16 columns returned from the query
Jun 25 00:13:16 [29319] DBG:core:db_allocate_columns: allocate 448 bytes for result columns at 0x7fe80284f880

--------
-------
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fe80284f9e0)[14]=[local_contact]
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fe80284f9f0)[15]=[version]
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Jun 25 00:13:16 [29319] DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query
Jun 25 00:13:16 [29319] DBG:presence:get_subs_db: The query for subscribtion for [uri]= sip:1001 at 10.207.232.168 for [event]= presence returned no result
Jun 25 00:13:16 [29319] DBG:core:db_free_columns: freeing result columns at 0x7fe80284f880
Jun 25 00:13:16 [29319] DBG:core:db_free_rows: freeing 0 rows

As always Thanks for all help.,

__________________________________________________________
INFORMATION CLASSIFICATION: IPC PROPRIETARY

Rajeshkumar Govindaraj
Senior Software Engineer
777 Commerce Drive,
Fairfield, CT-06825

Follow us on twitter: @ipc_Systems_Inc    www.ipc.com<http://www.ipc.com/>

[cid:image006.jpg at 01D1940F.3E021840]

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. 
If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. 
Please delete it and any attachments and notify the sender that you have received it in error. 
Unintended recipients are prohibited from taking action on the basis of information in this e-mail. 
E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, 
deleted or interfered with without the knowledge of the sender or the intended recipient. 
If you are not comfortable with the risks associated with e-mail messages, 
you may decide not to use e-mail to communicate with IPC. IPC reserves the right, 
to the extent and under circumstances permitted by applicable law, 
to retain, monitor and intercept e-mail messages to and from its systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/8bacc5b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3563 bytes
Desc: image003.jpg
URL: <http://lists.opensips.org/pipermail/users/attachments/20200625/8bacc5b0/attachment-0001.jpg>