Rachana,
I recently had a similar problem. I solved it with the following.
On Ubuntu 12.04 I ran the following commands to compile and install Erlang from
source.
sudo apt-get install libssl-dev
./configure --enable-m64-build
sudo make install
Now rebar runs without any problem.
I believe on
OK, the disk space used by AAE is a function of the number of keys rather than
the size of the objects stored in Riak. Let us know the disk usage after the
AAE trees are finished building.
When nodes go down in a Riak cluster, the remaining nodes spin up fallback
partitions to handle writes/re
Brian,
the used version is 1.4.2. No, not all aae-Trees are built. We had to
free disk space on two nodes last weekend, these are currently building
their tree. And I also saw missing parts on two other nodes. The others
currently consume between 80GB and 110GB. The ones building their trees
Rachana,
This appears to be an issue with how the Erlang you are trying to run
was built. It looks like it did not build with OpenSSL support. Please
ensure that the `openssl-devel` package is installed before
recompiling Erlang.
--
Hector
On Tue, May 20, 2014 at 8:08 AM, Rachana Shroff wrote:
Ingo,
Sorry for the lack of response. What version of Riak are you using? At this
point, i assumee riak-admin aae_status shows alls trees as built across the
cluster. How much space is the AAE directory currently using?
Thanks,
Brian
--
Brian Sparrow
Developer Advocate
Basho Technologies
Se
Hi,
sorry to bother again, can anyone shed a light on this issue?
Best,
Ingo
Am 12.05.2014 15:44, schrieb Ingo Rockel:
Hi,
we had a little outage of our 12 node riak cluster yesterday, the first
so far, four nodes had gone down because of exhausted disk space.
What happened: our bac
For what it's worth, in the integration tests of our client libraries we
have moved to generating random bucket and key names for each test/example.
This reduces setup/teardown time and is less susceptible to the types of
unexpected behaviors you are seeing from list-keys. If possible, I highly
rec
Ok, so, from what I understand, this is going to be expected behavior from
strongly consistent buckets. (I'm in the process of confirming this, and
we'll see if we can add it to the documentation). The delete_mode:
immediate is ignored, and the tombstone is kept around, to ensure the
consistency of
Ok then,
I've stopped riak, wiped bitcask and anti_entropy directories, updated
config, started riak.
I've tried to verify it with:
riak config generate -l debug
Got output:
[...]
10:25:46.260 [info] /etc/riak/advanced.config detected, overlaying proplists
-config /var/lib/riak/generated.con