[SR-Users] dmq issues

Fri Dec 1 12:59:59 CET 2017

Hi Charles, great trick the FQDN + multi_notify

I am guessing that with the multi_notify setting, the problem I was
refering too may be solved.

I will document it in a github issue.

On Fri, Dec 1, 2017 at 3:26 AM, Charles Chance <
charles.chance at sipcentric.com> wrote:

> Hello,
>
> It seems you have already solved your issue, but just to add, it's often
> better to provide an FQDN as notification_address which resolves to
> multiple IPs (and set "multi_notify" parameter).
>
> There should be no issues when shutting down multiple nodes at once, as
> long as the remaining nodes are still in contact with each other - at
> least, that is my experience across several long-established (and highly
> dynamic) clusters. When the disabled nodes are re-enabled, providing they
> have the address of at least one active node (or better, an FQDN resolving
> to multiple) they'll rejoin seamlessly.
>
> Of course, if others have a different experience, it would be good to
> learn more about it.
>
> Cheers,
>
> Charles
>
>
> On 1 December 2017 at 11:00, Julien Chavanton <jchavanton at gmail.com>
> wrote:
>
>> Forgot to mention
>>
>> 192.168.150.225 must have another node as notitifcation peer, not himself
>> else he will not replicate data to other nodes
>>
>> On Fri, Dec 1, 2017 at 2:33 AM, Julien Chavanton <jchavanton at gmail.com>
>> wrote:
>>
>>> Hi Aydar,
>>>
>>> You can have only one notification_address in this case the last one
>>> will be used "192.168.150.225" this will be you DMQ master node
>>>
>>> I know the bus can break if you shutdown multiple nodes at the same time
>>> and one of them is the master node and then you restart them. (not sure if
>>> this is your case)
>>>
>>> If this happens the only option I can see is to restart all nodes one by
>>> one.
>>>
>>> I think this case could be handled better maybe by adding a dmq resync
>>> command that can recreate the bus .
>>>
>>>
>>> On Fri, Dec 1, 2017 at 12:32 AM, Aidar Kamalov <aidar.kamalov at gmail.com>
>>> wrote:
>>>
>>>> Hello. I have 4  kamailio nodes with same config:
>>>>
>>>> modparam("dmq", "server_address", "sip:LOCALIP:5050")
>>>> modparam("dmq", "notification_address", "sip:192.168.8.213:5050")
>>>> modparam("dmq", "notification_address", "sip:192.168.10.54:5050")
>>>> modparam("dmq", "notification_address", "sip:192.168.107.195:5050")
>>>> modparam("dmq", "notification_address", "sip:192.168.150.225:5050")
>>>> modparam("dmq", "num_workers", 6)
>>>> modparam("dmq_usrloc", "enable", 1)
>>>> modparam("dmq_usrloc", "sync", 1)
>>>> modparam("dmq_usrloc", "batch_size", 2000)
>>>> modparam("dmq_usrloc", "batch_usleep", 1000)
>>>>
>>>>
>>>> regularly (don't know why) I've got issues - replication is broken, for
>>>> example now at all nodes I have:
>>>> # kamcmd dmq.list_nodes
>>>> {
>>>> host: 192.168.8.213
>>>> port: 5050
>>>> resolved_ip: 192.168.8.213
>>>> status: 2
>>>> last_notification: 0
>>>> local: 0
>>>> }
>>>> {
>>>> host: 192.168.10.54
>>>> port: 5050
>>>> resolved_ip: 192.168.10.54
>>>> status: 2
>>>> last_notification: 0
>>>> local: 0
>>>> }
>>>> {
>>>> host: 192.168.150.225
>>>> port: 5050
>>>> resolved_ip: 192.168.150.225
>>>> status: 8
>>>> last_notification: 0
>>>> local: 0
>>>> }
>>>> {
>>>> host: 192.168.107.195
>>>> port: 5050
>>>> resolved_ip: 192.168.107.195
>>>> status: 2
>>>> last_notification: 0
>>>> local: 1
>>>> }
>>>>
>>>> but at node 192.168.150.225:
>>>> # kamcmd dmq.list_nodes
>>>> {
>>>> host: 192.168.150.225
>>>> port: 5050
>>>> resolved_ip: 192.168.150.225
>>>> status: 2
>>>> last_notification: 0
>>>> local: 0
>>>> }
>>>> {
>>>> host: 192.168.150.225
>>>> port: 5050
>>>> resolved_ip: 192.168.150.225
>>>> status: 2
>>>> last_notification: 0
>>>> local: 1
>>>> }
>>>>
>>>> nodes restart doesn't help. but if i exec
>>>> systemctl stop kamailio && sleep 15 && systemctl start kamailio
>>>> it is partially solve my issue - dmq.list_nodes show all nodes, but at
>>>> 192.168.150.225 i see not all user locations: they are added gradually
>>>>
>>>> There is no errors in logs
>>>> Dec  1 08:28:37 sipufa /usr/sbin/kamailio[18252]: NOTICE: <script>:
>>>> ROOT: KDMQ notification_peer [15f3edf9258014d1-7114 at 192.168.8.213]
>>>> Dec  1 08:28:38 sipufa /usr/sbin/kamailio[18271]: NOTICE: <script>:
>>>> ROOT: KDMQ notification_peer [7acb9eae627482f8-87828 at 192.168.10.54]
>>>> Dec  1 08:28:39 sipufa /usr/sbin/kamailio[18250]: NOTICE: <script>:
>>>> ROOT: KDMQ notification_peer [621ad9f474b335e2-18272 at 192.168.150.225]
>>>> Dec  1 08:28:40 sipufa /usr/sbin/kamailio[18252]: NOTICE: <script>:
>>>> ROOT: KDMQ notification_peer [7b817f6a6244f923-8872 at 192.168.107.195]
>>>> Dec  1 08:28:47 sipufa /usr/sbin/kamailio[18271]: NOTICE: <script>:
>>>> ROOT: KDMQ usrloc [7acb9eae627482f2-87794 at 192.168.10.54]
>>>> Dec  1 08:29:20 sipufa /usr/sbin/kamailio[18251]: NOTICE: <script>:
>>>> ROOT: KDMQ usrloc [7acb9eae627482ef-87790 at 192.168.10.54]
>>>>
>>>>
>>>> --
>>>> Aydar A. Kamalov
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171201/df016b33/attachment.html>