[BUG/HELP] dialog replication.

[volga629-1]

Opensips 3.1-dev

With PgSQL dialog module in cluster latest master 3.1-dev active/active setup tries insert duplicate data from each node.
This setup contain 3 vips for each node on LAN and WAN sides.
Each node contain same configuration in term of routing logic.

/usr/sbin/opensips[1727986]: ERROR:db_postgres:db_postgres_submit_query: 0x7f4eb5e95e28 PQsendQuery Error: ERROR:  duplicate key value violates unique constraint "dialog_pkey"#012DETAIL:  Key (dlg_id)=(7546448396242) already exists.#012 Query:

Might be some miss configuration or bug, but can't find what the issue

#### Dialog
loadmodule "dialog.so"
#modparam("dialog", "db_url", "postgres:///opensips")
modparam("dialog", "db_mode", 2)
modparam("dialog","profiles_with_value","outbound; inbound")
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 3600)
modparam("dialog", "options_ping_interval", 900)
modparam("dialog", "profiles_with_value", "caller ; domain")
modparam("dialog", "dialog_replication_cluster", 1)


       if(!has_totag() && is_method("INVITE") && !has_body("application/csta+xml")) {

                create_dialog();
		topology_hiding();

                ### Set profile ###
                ### Set profile ###
                set_dlg_profile("caller",$fU@$fd);
                set_dlg_profile("domain",$fd);

                get_profile_size("caller",$fU@$fd,$var(ccaller));
                get_profile_size("caller",$fd,$var(cdomain));
                xlog("Number of calls from user $fU@$fd is $var(ccaller)");
                xlog("Number of calls from domain $fd is $var(cdomain)");


	xlog("Got request on ip addr [$socket_in(ip)] and call dir $avp(DLG_dir)\n");
	# Wan route
	$var(ip_lst) = $shv(vip_wan_lst);
	route(SET_SOURCE_SOCKET);
	if($avp(DLG_dir)=="topbx") {
        	switch($(avp(req_ip){s.select,3,.})) {
            	case "38":
                	set_dlg_sharing_tag("vip1");
                	xlog("[$rm] Set dialog tag vip1 ~> $(avp(req_ip){s.select,3,.})\n");
                	break;
            	case "39":
                	set_dlg_sharing_tag("vip2");
                	xlog("[$rm] Set dialog tag vip2 ~> $(avp(req_ip){s.select,3,.})\n");
                	break;
            	case "40":
                	set_dlg_sharing_tag("vip3");
               		xlog("[$rm] Set dialog tag vip3 ~> $(avp(req_ip){s.select,3,.})\n");
                	break;
            	default:
                	xlog("[$rm] Unknown last octet ~> $(avp(req_ip){s.select,3,.})\n");
        	}
	}
}

Any help thank you, volga629

[rvlad-patrascu]

Hi @volga629-1 ,

When enabling dialog replication, each node expects to have its own, separate database/table. In this case, the DB is an alternative for the cluster based restart persistency.

[rvlad-patrascu]

Do check the paragraph about DB usage from this documentation section.

[volga629-1]

@rvlad-patrascu Thank you for reply. Right now cluster is use shared PgSQL db cluster. So we don't need replicate dialogs ?
I am just trying understand what is for shared tag. I red docs and it seems it not matching 3.1 version.

set_dlg_sharing_tag("vip1");

[rvlad-patrascu]

If you want to use the sharing tags mechanism you do need to replicate the dialogs through clusterer. When you say the docs are not matching the 3.1 version, what exactly are you referring to?

[volga629-1]

The section is pointed to tutorial. It really unclear how to use shared tags in cluster with shared db. in version 3.1-dev

[rvlad-patrascu]

Again, the sharing tags (and the overall dialog replication through clusterer mechanism) are not meant to be used with a shared DB so there is not much I can assist you with if you want to use it this way.

[volga629-1]

Cluster fully enabled in setup with shared db. The only option I see is point dialog for each node to separate database table.

[rvlad-patrascu]

Yes, this is perfectly fine. I've just meant that you should not use the same table for both nodes.

[volga629-1]

@rvlad-patrascu Ideally will be nice to have shared db flag in parameters which will help identify the nodes. Add two more tables for dialog is not in issue, just some management overhead if need add or remove cluster nodes.

[stale]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[volga629-1]

Work in progress

[volga629-1]

Work in progress

[rvlad-patrascu]

Hi @volga629-1 ,

For the moment, we do not see clear advantages in implementing support for using the same table for multiple nodes when replicating dialogs. This kind of goes in opposition with the idea that each nodes handles its own DB data and might create some more confusion for people. After all, the recommended scenario is to actually have a local database for each clustered node. As such, if the DB is in fact shared, we believe that the extra effort of creating a few more dialog tables is not an issue.

[volga629-1]

@rvlad-patrascu I understand, the only one think is might clarify is documentation . Which can describe share db setup.