Re: Update metadata of entries in bucket

[Luke Bakken]

Hi Grigory,

Check out this article:
http://basho.com/posts/technical/webinar-recap-mapreduce-querying-in-riak/

Specifically, the use of riak:local_client() and C:put
--
Luke Bakken
Engineer
lbak...@basho.com


On Thu, Feb 23, 2017 at 10:38 AM, Grigory Fateyev  wrote:
> Hello!
>
> I'm trying to write riak_pipe command that updates metadata, the code:
> https://gist.github.com/greggy/7d7fa3102d89673019410c6e244650cd
>
> I'm getting every entry in update_metadata/1 then creating a new metadata,
> updating it in Item.
>
> My question is how to update r_object in a bucket?
>
> Thank you!
>
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Handoffs are too slow after netsplit

[Andrey Ershov]

Thanks guys for your replies.

Charlie, I've seen a ticket regarding this issue
https://github.com/basho/riak/issues/754 - I'm not calling vnode-status
command.
Douglas, I suppose vnode_inactivity_timeout

should
not influence riak_core_vnode_manager:force_handoff() execution time. As
far as I understand, when vnode_inactivity_timeout has triggered, vnode
initiates takeoff, but here I'm forcing take off and it does not start
right away.
Anyway, I've set vnode_inactivity_timeout to 2 seconds and no longer call
foce_handoff. Seems that handoffs are now faster, but still might take up
to 30 seconds.
Guys, probably there is some other timer should trigger before takeoff can
proceed?


2017-02-24 20:20 GMT+03:00 Charlie Voiselle :

> Andrey:
>
> Another thing that can stall handoff is running commands that reset the
> vnode activity timer.  The `riak-admin vnode-status` command will reset the
> activity timer and should never be run more frequently that then vnode
> inactivity timeout; if you do, that can permanently stall handoff.  We have
> seen this before at a customer site where they were collecting the statics
> from the vnode-status command into their metrics system.
>
> Regards,
> Charlie Voiselle
>
>
> On Feb 23, 2017, at 7:14 AM, Douglas Rohrer  wrote:
>
> Andrey:
>
> It's waiting for 60 seconds, literally...
>
> See https://github.com/basho/riak_core/search?utf8=%E2%9C%
> 93=vnode_inactivity_timeout - handoff is not initiated until a vnode
> has been inactive for the specified inactivity period.
>
> For demonstration purposes, if you want to reduce this time, you could set
> the riak_core.vnode_inactivity_timeout period lower ,which can be set in
> advanced.config. Also note that, depending on the backend you use, it's
> possible to have other settings set lower than the vnode inactivity
> timeout, you can actually prevent handoff completely - see
> http://docs.basho.com/riak/kv/2.2.0/setup/planning/
> backend/bitcask/#sync-strategy, for examnple.
>
> Hope this helps.
>
> Doug
>
> On Thu, Feb 23, 2017 at 6:40 AM Andrey Ershov 
> wrote:
>
> Hi, guys!
>
> I'd like to follow up on handoffs behaviour after netsplit. The problem is
> that right after network partition is healed, "riak-admin transfers"
> command says that there are X partitions waiting transfer from one node to
> another, and Y partitions waiting transfer in the opposite direction. What
> are they waiting for? Active transfers section is always empty. It takes
> about 1 minute for transfer to occur. I've increased transfer_limit to 100
> and it does not help.
> Also I've tried to attach to Erlang VM and execute
> riak_core_vnode_manager:force_handoff() on each node. This command
> returns 'ok'. But seems that it does not work right after network is
> healed. After some time 30-60 s, force_handoff() works as expected, but
> actually it's the same latency as in auto handoff case.
>
> So what is it waiting for? Any ideas?
>
> I'm preparing real-time coding demo to be shown on the conference. So it's
> too much time to wait for 1 minute for handoff to occur just for a couple
> of keys...
> --
> Thanks,
> Andrey
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
>


-- 
С уважением,
Ершов Андрей
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Handoffs are too slow after netsplit

[Charlie Voiselle]

Andrey:

Another thing that can stall handoff is running commands that reset the vnode 
activity timer.  The `riak-admin vnode-status` command will reset the activity 
timer and should never be run more frequently that then vnode inactivity 
timeout; if you do, that can permanently stall handoff.  We have seen this 
before at a customer site where they were collecting the statics from the 
vnode-status command into their metrics system. 

Regards,
Charlie Voiselle


> On Feb 23, 2017, at 7:14 AM, Douglas Rohrer  wrote:
> 
> Andrey:
> 
> It's waiting for 60 seconds, literally...
> 
> See 
> https://github.com/basho/riak_core/search?utf8=%E2%9C%93=vnode_inactivity_timeout
>  
> 
>  - handoff is not initiated until a vnode has been inactive for the specified 
> inactivity period.
> 
> For demonstration purposes, if you want to reduce this time, you could set 
> the riak_core.vnode_inactivity_timeout period lower ,which can be set in 
> advanced.config. Also note that, depending on the backend you use, it's 
> possible to have other settings set lower than the vnode inactivity timeout, 
> you can actually prevent handoff completely - see 
> http://docs.basho.com/riak/kv/2.2.0/setup/planning/backend/bitcask/#sync-strategy
>  
> ,
>  for examnple.
> 
> Hope this helps.
> 
> Doug
> 
> On Thu, Feb 23, 2017 at 6:40 AM Andrey Ershov  > wrote:
> Hi, guys!
> 
> I'd like to follow up on handoffs behaviour after netsplit. The problem is 
> that right after network partition is healed, "riak-admin transfers" command 
> says that there are X partitions waiting transfer from one node to another, 
> and Y partitions waiting transfer in the opposite direction. What are they 
> waiting for? Active transfers section is always empty. It takes about 1 
> minute for transfer to occur. I've increased transfer_limit to 100 and it 
> does not help. 
> Also I've tried to attach to Erlang VM and execute 
> riak_core_vnode_manager:force_handoff() on each node. This command returns 
> 'ok'. But seems that it does not work right after network is healed. After 
> some time 30-60 s, force_handoff() works as expected, but actually it's the 
> same latency as in auto handoff case. 
> 
> So what is it waiting for? Any ideas?
> 
> I'm preparing real-time coding demo to be shown on the conference. So it's 
> too much time to wait for 1 minute for handoff to occur just for a couple of 
> keys...
> -- 
> Thanks,
> Andrey
> ___
> riak-users mailing list
> riak-users@lists.basho.com 
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com 
> 
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

[ANN] Riak KV operating system packaging deprecations

[Charlie Voiselle]

As part of our release process, we regularly review our list of supported 
operating systems(OS) and OS versions for additions and deprecations. 

Deprecations fall into one of two categories:
 1) deprecation of an aging OS version 
 2) deprecation of an entire operating system.

When it comes to the deprecation of aging OS versions, we closely monitor 
end-of-life notices from OS vendors to determine when to stop building for a 
specific OS version. Stability and availability are the reasons you chose Riak 
KV, and without active vendor support for an underlying operating system, both 
of these values can be compromised.

The deprecation of an entire OS is a more difficult decision because we would 
love to have a Riak package for any platform where someone wants to run Riak. 
However, attempting to support too many platforms risks inadequate support for 
some platforms. Thus, we monitor statistics for which operating systems are 
most  frequently used by our customers and community members.  We have found a 
few that are significantly less popular among Riak users. Basho will be 
removing official support for these operating systems to allow us to focus more 
attention on the ones most often deployed. 

So, let’s get to the details:
Starting with Riak KV 2.0.8, we have stopped building packages for SmartOS 1.3 
and Debian 6.
For all future Riak KV releases, we will cease building packages for all 
SmartOS versions, all Solaris versions, and all Fedora Core versions.

Basho customers with any questions are encouraged to contact either their 
account managers or the Basho Client Services  team.

Basho community members can contact us via the riak-users mailing list. 

Best regards,
Charlie Voiselle
Senior Product Manager - Riak KV, Basho Technologies
@angrycub

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Node is not running!

[Jurgen Ramaliu]

Hello Magnus,

I have attached logs directory in this e-mail.


Best Regards,
Jurgen

On Fri, Feb 24, 2017 at 9:56 AM, Magnus Kessler  wrote:

> On 23 February 2017 at 13:58, Magnus Kessler  wrote:
>
>> On 23 February 2017 at 13:38, Jurgen Ramaliu 
>> wrote:
>>
>>> Hello Magnus,
>>>
>>> Attached is console.log.
>>>
>>>
>>
>>
> Hi Jurgen,
>
> If you haven't deleted any older logs since, could you please also run
> 'riak-debug' and post the resulting archive file? A Basho engineer would
> like to see if there were similarities to another issue he's investigating.
>
> Kind Regards,
>
> Magnus
>
> --
> Magnus Kessler
> Client Services Engineer
> Basho Technologies Limited
>
> Registered Office - 8 Lincoln’s Inn Fields London WC2A 3BP Reg 07970431
>


logs.rar
Description: application/rar
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Node is not running!

[Magnus Kessler]

On 23 February 2017 at 13:58, Magnus Kessler  wrote:

> On 23 February 2017 at 13:38, Jurgen Ramaliu 
> wrote:
>
>> Hello Magnus,
>>
>> Attached is console.log.
>>
>>
>
>
Hi Jurgen,

If you haven't deleted any older logs since, could you please also run
'riak-debug' and post the resulting archive file? A Basho engineer would
like to see if there were similarities to another issue he's investigating.

Kind Regards,

Magnus

-- 
Magnus Kessler
Client Services Engineer
Basho Technologies Limited

Registered Office - 8 Lincoln’s Inn Fields London WC2A 3BP Reg 07970431
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Node is not running!

[Jurgen Ramaliu]

Hello Magnus,

Attached is console.log.


On Thu, Feb 23, 2017 at 2:32 PM, Magnus Kessler  wrote:

> On 23 February 2017 at 07:19, Jurgen Ramaliu 
> wrote:
>
>> Hi Paul and Magnus,
>> I have resolve it by using command :
>>
>>
>>- riak stop
>>
>>
>>- changing nodename into file riak.conf from nodename = riak@127.0.0.1
>>to riak@192.168.1.10
>>
>>
>>- riak-admin reip riak@127.0.0.1 riak@192.168.1.10
>>
>> But I have another problem, riak starts with this IP but shut down after
>> about 15 seconds.
>>
>>
>> Can you tell me how can I resolve this?
>>
>> Regards,
>> Jurgen
>>
>
> Hi Jurgen,
>
> Can post the portion of the console.log since the last restart of Riak,
> please? Without further information it's hard to guess what may have gone
> wrong.
>
> Kind Regards,
>
> Magnus
>
>
> --
> Magnus Kessler
> Client Services Engineer
> Basho Technologies Limited
>
> Registered Office - 8 Lincoln’s Inn Fields London WC2A 3BP Reg 07970431
>


console.log
Description: Binary data
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com