Re: ANN: Riak KV 2.9.0 P4 - New patch update available

Riak KV 2.9.0 release, upgrading is recommended, but the update is not considered urgent unless running with Tictac AAE enabled. Regards On Mon, 9 Sep 2019 at 09:53, Martin Sumner wrote: > The latest patch for the 2.9.0 is now available. > > On github the release can be found at

ANN: Riak KV 2.9.0 P4 - New patch update available

The latest patch for the 2.9.0 is now available. On github the release can be found at - https://github.com/basho/riak/tree/riak-2.9.0p4. Updated packages are also available (thanks to Nick Adams at TI Tokyo) - https://files.tiot.jp/riak/kv/2.9/2.9.0p4/

Re: ANN: Riak 2.9.0 Urgent Patches Pending

immediate concern over use of the unpatched version. Sorry for causing false alarm. Regards Martin On Thu, 22 Aug 2019 at 01:36, Martin Sumner wrote: > There are 2 defects in the 2.9.0 release which should be patched within > the next 7 days, with a new version of 2.9.0 to be published

ANN: Riak 2.9.0 Urgent Patches Pending

There are 2 defects in the 2.9.0 release which should be patched within the next 7 days, with a new version of 2.9.0 to be published before the end of the month. The defects are: https://github.com/basho/riak_kv/issues/1706 https://github.com/basho/riak_kv/issues/1707 Note that the latter defect

Re: Riak 2.9.0 - Update Available

have been highlighted so far. Work on Riak 3.0 has slowed over the summer, but I hope we can pick up the pace again and make further progress in September. Regards Martin On Fri, 28 Jun 2019 at 09:34, Martin Sumner wrote: > There is now a second update available for 2.9.0: > https://gith

Re: Riak 2.9.0 - Update Available

oosing 2.9 thing has unnecessarily cramped naming up, which was my bad. I've turned Riak release numbering into a confusing mess. So apologies for that. Hopefully we can return to a more sane numbering system from 3.0. Perhaps someone else should choose! Regards On Fri, 28 Jun 2019 at 09:34

Re: Riak 2.9.0 - Update Available

s or just reading the code ? > > On Fri, 28 Jun 2019 at 09:35, Martin Sumner > wrote: > >> There is now a second update available for 2.9.0: >> https://github.com/basho/riak/tree/riak-2.9.0p2. >> >> This patch, like the patch before, resolves a memory managem

Re: Riak 2.9.0 - Update Available

scenario where there were a tens of thousands of 2MB objects stored in a portion of the keyspace at the end of the handoff - which led to memory issues until either more PUTs were received (to force a persist to disk) or a restart occurred.. Regards On Sat, 25 May 2019 at 09:35, Martin Sumner

Riak 2.9.0 - Update Available

Unfortunately, Riak 2.9.0 was released with an issue whereby a race condition in heavy-PUT scenarios (e.g. handoffs), could cause a leak of file descriptors. The issue is described here - https://github.com/basho/riak_kv/issues/1699, and the underlying issue here - https://github.com/martinsumner/

[ANN] Riak 2.9.0 - Release Candidate 7 Available

Release Candidate 7 for 2.9.0 is now available on github. It is available to build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc7. All usual caveats apply. All usual promises that this will be the last release candidate are duly made. Regards Martin ___

[ANN] Riak 2.9.0 - Release Candidate 6 Available

Release Candidate 6 for 2.9.0 is now available on github. It is available to build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc6. Apologies for the churn of release candidates on 2.9.0. As part of the move to 2.9 there has been a big update to the mochiweb/webmachine code,

[ANN] Riak 2.9.0 - Release Candidate 5 Available

Zsolt, I have no immediate help I can offer wrt compiling leveldb on Power 9. I have had some thoughts about getting Riak running without leveldb ( https://github.com/basho/riak/issues/961), but have nothing currently available to help you right now. Martin __

[ANN] Riak 2.9.0 - Release Candidate 5 Available

Release Candidate 5 for 2.9.0 is now available on github. It is available to build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc5 . Apologies for the churn of release candidates on 2.9.0. This is as a result of issues discovered in the leveled refactoring in RC2, having side

RE: Leveled and auto-expiry (ジョハンガル)

Johan, Leveled does have TTL support for objects, but this is not added yet into riak_kv. I've raised an issue to look at this - https://github.com/basho/riak_kv/issues/1684. As mentioned in the issue, there is some thinking required first to make sure that expiry works well with anti-entropy.

[ANN] Riak 2.9.0 - Release Candidate 2 Available

Release Candidate 2 for 2.9.0 is now available on github. It is available to build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc2 . The changes from Release Candidate 1 are described here - https://github.com/basho/riak/blob/develop-2.9/doc/Release%202.9%20Series%20-%20Overvi

[ANN] Riak 2.9.0 - Release Candidate 1 Available

All, There is now a publicly available release candidate for Riak 2.9.0 for users to test in their own environment. The release candidate is available to build from source here - https://github.com/basho/riak/tree/riak-2.9.0rc1 There is only one significant change to Riak 2.2.6 for users maintai

RE: RIAK Manchester Workshop

Andrew, It would be good at the Manchester workshop to talk about some of the work we've been doing for the next release. - A short reminder of the bugs and fixes that made it into 2.2.5 and 2.2.6; - Report on the testing and production-readiness of leveled - Quviq's work on property-based testin

Re: Node Recovery Questions

many times within the active file, that space will not be recovered if all the replacements amount to < 2GB per vnode. So at these small data sizes - you may get a relatively significant discrepancy between an old and recovered node in terms of disk space usage. On 8 August 2018 at 17:37, Martin

RE: Node Recovery Questions

Sean, Some partial answers to your questions. I don't believe force-replace itself will sync anything up - it just reassigns ownership (hence handoff happens very quickly). Read repair would synchronise a portion of the data. So if 10% of you data is read regularly, this might explain some of w

KV Index Tictac Tree - potential feature proposal for Riak 3.0

One of the design goals around Leveled was to make the production of anti-entropy trees easier to achieve. Originally I intended this as a backend feature (i.e. it would be only available in Riak + leveled). Over the past few months I've worked on KV Index Tictac Tree - which is an AAE library, t

Re: WARNING: Not all replicas will be on distinct nodes

distinct nodes" after the final set of transfers, which > incidentally involved riak21 (although it did appear earlier in the plan). > Is it true that if that warning appears anywhere in the plan then it's a > bad plan? > > Thank you again for the quick response! >

Re: WARNING: Not all replicas will be on distinct nodes

Daniel, See this post ( http://lists.basho.com/pipermail/riak-users_lists.basho.com/2017-August/019488.html) and the links in it for some more details on issues with the core claim algorithm. The fix is in the pending release 2.2.5 which Russell is adding the finishing touches to at the moment.

Re: Riak KV performance in sensor data storage application

I suspect with the test environment having only 4GB of RAM and a single slow disk per node - both Leveldb and Leveled are going to struggle in terms of the write throughput. As n=1 in this test, some of the advantages of Leveled will be lost also (e.g. the n HEADs advantage). I thought the paper

Re: Leveled and Anti-Entropy

Heinz, No I haven't, but I will. Thanks Martin On 21 July 2017 at 15:43, Heinz N. Gies wrote: > Have you taken a look at the changes here https://github.com/ > Kyorai/riak_core/pull/24 > > It pulls the AAE work for riak_kv into riak_core. > > > On 21. Jul 201

Leveled and Anti-Entropy

I've added some anti-entropy features to Leveled (the pure-Erlang KV store designed as a Riak backend). These features are in-part an experiment in how to approach both anti-entropy and full-sync multi-data centre replication in the future. There's a long write-up, including some history of AAE i

Re: Changing Bitcask Expiry Policy

Felipe, I've not played around with this myself. However, after a brief look at the bitcask code, it looks like a timestamp is given to each object as it is written to bitcask - to represent the time it was written, not the time it will expire. The expiry_time is part of the state of the bitcask

Re: Core Claim and Property-Based Tests

hm to move a small number of unnecessary partitions to see if > that would free things up and get better balance/diversity. > > For improving v2 you might try seeing if there's a way to > deterministically shuffle the starting point where it starts to look for > patitions

Re: Core Claim and Property-Based Tests

Jon, With regards to this snippet below, I think I get your point, but I don't think the example is valid: >>> If with N=3 if a node goes down, all of the responsibility for that node is shift to another single node in the cluster. n1 | n2 | n3 | n4 | n1 | n2 | n3 | n4(Q=8 S=4,TargetN4)

Re: Core Claim and Property-Based Tests

Jon, Many thanks for taking the time to look at this. You've given me lots to think about, so I will take some time before updating my write-up to take account of your feedback. I need to go back and look at the safe transfers issues. I spent some time trying to work out how the claimaint trans

Re: Core Claim and Property-Based Tests

is mailing list won't last much > > longer, either. I'm happy to personally contribute time and resources to > > help maintain the community. > > > > Tom > > > > On Tue, May 16, 2017 at 11:51 AM, Martin Sumner > > wrote: > >> > >>

Core Claim and Property-Based Tests

I've raised an issue with Core today ( https://github.com/basho/riak_core/issues/908), related to the claim algorithms. There's a long-read associated with this, which provides a broader analysis of how claim works with the ring: https://github.com/martinsumner/riak_core/blob/mas-claimv2issues/do

Leveled, Riak and Hashtree rebuilds

The next phase of Riak and Leveled testing is now complete, with this phase focused on achieving stable throughput during hashtree rebuilds. this scenario has been tested due to a history of issues with the cost of hashtree rebuilds in Riak production environments, and looks at improvements offere

Riak + leveled - volume testing with 2i

I've now completed the first phase of testing Riak/leveled with 2i query load on top of standard GET/PUT Key/Value pressure. In the previous tests without 2i Riak/leveldb was throttled by write pressure, which was exaggerated by enabling sync_on_write, using traditional HDDs or using larger object

Re: Leveled - Another Erlang Key-Value store

as well. Is there a basho bench configuration? This reminds me a > bit if fractal trees but with a focus on NoSQL operational semantics, how > else do you see this adding improvements? It seems index requests could be > cheaper with this backend configuration. > > On Tue, Feb 28,

Re: Leveled - Another Erlang Key-Value store

nd patches on > this. > > On Tue, Feb 28, 2017 at 9:04 AM, Martin Sumner > wrote: > > > > Over the past few months I've been working on an alternative pure-Erlang > > Key/Value store to act as a backend to Riak KV. This is now open source > and > >

Leveled - Another Erlang Key-Value store

Over the past few months I've been working on an alternative pure-Erlang Key/Value store to act as a backend to Riak KV. This is now open source and available at https://github.com/martinsumner/leveled The store is a work-in-progress prototype, originally started to better understand the impact

Re: Experimental branch - 2i query improvements

bly memory efficient. Do you use very large keys? > > Sent from my iPhone > > On 16/04/2013, at 23.50, "Martin Sumner" <mailto:martin.sum...@adaptip.co.uk>> wrote: > > I've been working on an experimental branch to offer some improvements to > the fun

Re: Experimental branch - 2i query improvements

hes a > certain criteria (eg get all data between 08:00-16:00 in august for > all years). At least facilitating for more advanced matching functions > could be a good idea. > > Olav > > 2013/4/16 Martin Sumner : > > I've been working on an experimental branch to offer

Experimental branch - 2i query improvements

I've been working on an experimental branch to offer some improvements to the functionality and performance of 2i queries in Riak: https://github.com/martinsumner/riak_kv Explanation: https://github.com/martinsumner/riak_kv/blob/master/docs/index_speedup.md There are four basic features that are

2i performance and ring-creation-size

Hello, We've just been re-running some performance tests today following a number of changes - and we've found our use of secondary indexes to be much slower than previously, and much slower than we expected. I think I know why, but could someone confirm if I have understood the theory correctly?