Hi John, Next is just my opinion. And I didn’t explore source code OpenSIPS for syncing data.
The problem is little bit deeper. As we have cluster, we potentially have split-brain. We can disable seed node at all and just let nodes work after disaster/restart. But it means that we can’t guarantee consistency of data. So nodes must show this with «Not in sync» state. Usually clusters use quorum to trust on. But for OpenSIPS I think this approach is too expensive. And of course for quorum we need minimum 3 hosts. For 2 hosts after loosing/restoring interconnection it is impossible to say, which host has consistent data. That’s why OpenSIPS uses seed node as artificial trust point. I think «seed» node doesn’t solve syncing problems, but it simplifies total work. Let’s imagine 3 nodes A,B,C. A is Active. A and B lost interconnection. C is down. Then C is up and has 2 hosts for syncing. But A already has 200 phones re-registered for some reason. So we have 200 conflicts (on node B the same phones still in memory). Where to sync from? «Seed» host will answer this question in 2 cases (A or B). Of course if C is «seed» so it just will be happy from the start. And I actually don’t know what happens, if we now run «ul_cluster_sync» on C. Will it get all the contacts from A and B or not? We operate with specific data, which is temporary. So syncing policy can be more relaxed. May be it’s a good idea to connect somehow «seed» node with Active role in the cluster. But again, if Active node restarts and still Active - we will have a problem. ----- Alexey Vasilyev > 31 Dec 2018, в 18:04, John Quick <john.qu...@smartvox.co.uk> написал(а): > > Hi Alexei, > > Many thanks for your reply to my query about syncing the seed node for > usrloc registrations. > I just tried the command you suggested and it does solve the problem. I also > read the other thread you pointed to. > > I do not really understand the need for the seed node, especially not for > the case of memory based registrations. > A seed node makes sense if that node has a superior knowledge of the > topology or the data than the other nodes. It's view of the universe is to > be trusted more than the view held by any other node. > However, in the case of a cluster topology that is pre-defined (no > auto-discovery) and for full-sharing of usrloc registration data held > exclusively in memory, then all the nodes are equal - there is no superior > knowledge that can exist in one node. The one with the most accurate view of > the world is the one that has been running the longest. > > I am wondering if there is a justifiable case for an option that would > disable the concept of the seed node and make it so that, on startup, every > instance will attempt to get the usrloc data from any other running instance > that has data available. In effect, I can mimic this behaviour by adding the > command line you suggested just after opensips has started: > opensipsctl fifo ul_cluster_sync > > Am I missing something here about the concept of the seed node? > It concerns me that this seed concept is at odds with the concept of true > horizontal scalability. > All nodes are equal, but some are more equal than others! > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
