Hi Kishore, Thanks for clarification. Leader-Standby with Spectator example code would be significantly helpful.
Thanks, Erwin On Mon, May 13, 2013 at 6:50 PM, kishore g <[email protected]> wrote: > 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
