Hi Erwin, Both Master-Slave and Leader-Standby have offline states. There are two differences
1)Just a standard convention where master-slave means there is some kind of replication of data between master and slave which means slave is not idle. In case of LeaderStandBy, there is no data movement between the leader standby nodes and in most cases standby is idle until it is asked to become leader. 2) Other difference is the state machine, to become a master one should always become a slave, but in case of leader standby, there is no need to be in standby mode to become a leader. Thanks, Kishore G On Mon, May 13, 2013 at 8:21 AM, Erwin Karbasi <[email protected]> wrote: > Hello All, > > IMO, the most appropriate demo for our use case is the Rsync replicated > file system > http://helix.incubator.apache.org/recipes/rsync_replicated_file_store.html > . > > Is it correct that the ONLY difference between Leader-Standby and > Master-Slave state models is that Master-Slave has one more state that > calls Offline? > > Thanks, > Erwin > > > > On Mon, May 13, 2013 at 7:46 AM, Erwin Karbasi <[email protected]> wrote: > >> *Sorry, same message with typo correction.* >> >> >> hank you a lot Kishore. >> Your first pointed out option could be appropriate to our requirement. >> If the Server A will get up to date routing table from the server group >> B, it could be sufficient. >> >> Our requirement is that server A will access one of the members in >> cluster B (that is the leader) and this leader will be active for any >> operation. After that server will be unavailable other member in the >> cluster B will take the place of the leader, *but server A should be >> updated about this change. >> * >> Thanks again, >> Erwin >> >> On Sun, May 12, 2013 at 8:44 PM, kishore g <[email protected]> wrote: >> >>> Hi Erwin, >>> >>> The code i sent basically shows how Server A can send the request >>> directly to current Leader in server B group. Note, when leader changes in >>> server B, server A dynamically discovers that change and updates it routing >>> table. >>> >>> But looks like what you want is server A sends request to any one of the >>> server in Server B cluster and that server will re-direct the request to >>> the leader. In this case, the code i sent you must be included in every >>> server in Server B group. To server A you can simply provide list of >>> ip:port address and it can randomly select one of server and send the >>> request to it. >>> >>> >>> thanks, >>> Kishore G >>> >>> >>> >>> >>> On Sun, May 12, 2013 at 10:27 AM, Erwin Karbasi <[email protected]>wrote: >>> >>>> Hi Kishroe, >>>> >>>> Thank for the information. >>>> I'll deep dive into the code that you sent tomorrow. >>>> Is that code will ensure that I have one cluster that i can send to it >>>> requests and one member from that cluster (leader) will grab the request >>>> and treat it. >>>> >>>> Thanks again, >>>> Erwin Karbasi >>>> AT&T, Senior Software Architect >>>> >>>> >>>> On Sun, May 12, 2013 at 7:57 PM, kishore g <[email protected]> wrote: >>>> >>>>> Hi Erwin, >>>>> >>>>> Thanks for looking into Helix. In Helix, most of the time the only >>>>> configuration needed is the zookeeper address and cluster name. This is >>>>> the >>>>> code you can use to contact a server. >>>>> >>>>> //in the server A code at start up >>>>> final RoutingTableProvider routingTable = new RoutingTableProvider(); >>>>> //Default Externalview implementation >>>>> manager = HelixManagerFactory.getZKHelixManager(clusterName, >>>>> instanceName, InstanceType.SPECTATOR, zkConnectString) >>>>> manager.connect(); >>>>> manager.addExternalViewChangeListener(routingTable) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> //Any time you want to talk to servers B >>>>> //you can get a instances for a specific resource, partition in specific >>>>> state. e.g getInstances("LockGroup", "lockGroup_0", "LEADER"); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> List<InstanceConfig> instances = getInstances(String resourceName, String >>>>> partitionName, String state) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> //Get all instances in given resource in a specific state e.g >>>>> getInstances("LockGroup", "LEADER"); >>>>> Set<InstanceConfig> instances = getInstances(String resource, String >>>>> state) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> InstanceConfig can give you all details about the server like host, >>>>> port or anything else you want to add. >>>>> >>>>> Hope this helps. Thanks for bringing this up, we need to add an >>>>> example code for this. >>>>> >>>>> Thanks, >>>>> Kishore G >>>>> >>>>> On Sun, May 12, 2013 at 9:00 AM, Erwin Karbasi <[email protected]>wrote: >>>>> >>>>>> >>>>>> Hello Masters, >>>>>> >>>>>> We'd like to use Helix for Leader Election mechanism. >>>>>> Following our scenario: >>>>>> >>>>>> We have one server (server A) that need to connect to group of other >>>>>> servers (server B). >>>>>> How server A can access the server B's group - cluster. >>>>>> >>>>>> As I know from other cluster frameworks, we can concatenate multiple >>>>>> server ip:port and the cluster will pass the requests to the leader >>>>>> process >>>>>> that in the cluster. >>>>>> >>>>>> How above scenario could be implemented by using Helix leader >>>>>> election (Distributed lock manage) as demonstrated here: >>>>>> http://helix.incubator.apache.org/recipes/lock_manager.html >>>>>> >>>>>> Your insight would be highly appreciated. >>>>>> >>>>>> Thanks, >>>>>> Erwin Karbasi <[email protected]> >>>>>> AT&T, Senior Software Architect >>>>>> >>>>>> >>>>> >>>> >>> >> >
