dlg_id as primary key and single dialog table shared by multiple opensips instances

[mikomarrache]

Hi,

After the dialog table schema has been changed to replace the hash_entry and hash_id columns by the new dlg_id column, the dlg_id column is now the primary key of the table (while only an index - non UNIQUE - was defined before for the (hash_entry,hash_id) columns).

With a configuration where multiple opensips instances share the same dialog table, I can imagine a case where multiple instances create dialogs with the same (hash_entry,hash_id) pair. The problem is that if one instance inserts a dialog with the coordinates (6,2) and that some time after another instance inserts a new dialog with the coordinates (6,2), the database will reject the INSERT statement since the dlg_id will be the same for both dialogs.

Regards,
Mickael

[liviuchircu]

Hello Mickael,

Is this a real-life scenario? To me, this looks like a problem which should not be addressed, since there are alternatives (either deploy a backup instance for each primary instance, or put more load on one machine, and make the other one a backup). You can use dialog replication if you want "hot backups".

Looking at the problem from a generic perspective, it is similar to the "master-master replication" database scenario. Doing inserts on both nodes will eventually lead to inconsistencies even on the latest MySQL versions, since it just was not meant to be used this way.

[mikomarrache]

Hi Liviu,

This is the architecture we use for a long time.

We have N OpenSIPS instances that share the same dialog table. Traffic is load balanced over the instances. I agree that dialogs are exclusive to each instance (a dialog that doesn't belong to an instance would be ignored by this instance during a restart) but we use this to centralize the dialogs in a single table.

Mickael

[mikomarrache]

Hi Liviu,

I think your argumentation is right, we will think about using one dialog table per instance so that we never encounter this issue.

Regards,
Mickael