helix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erwin Karbasi <er...@optinity.com>
Subject Re: Leader election - Distributed lock manager
Date Mon, 13 May 2013 17:38:42 GMT
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 <g.kishore@gmail.com> 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 <erwin@optinity.com> 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 <erwin@optinity.com>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 <g.kishore@gmail.com> 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 <erwin@optinity.com>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 <g.kishore@gmail.com>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 <erwin@optinity.com>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 <ek128b@att.com>
>>>>>>> AT&T, Senior Software Architect
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message