On Sep 17, 2012, at 10:34 AM, Kresten Krab Thorup <[email protected]> wrote:

> As I understand Paul's situation, the 3 nodes are up and running again.  
> Should that not be enough to avoid the "insufficient vnodes" error?

Ah, yes. I've misunderstood. Serves me right for responding before I've had my 
morning coffee :)
I'm not immediately sure what could cause this (other than those 2 nodes not 
being available
_at the time of the request_).

Paul, can you verify that you're getting this same error from each node? Do all 
three
nodes return the same information for 'ring_status'?

Reid


> 
> After a node down, I can see that it should matters better by running "riak 
> repair" of the involved partitions, but 2i should be able to run again when 
> sufficient nodes comes back on line?
> 
> Kresten
> 
> On Sep 17, 2012, at 4:20 PM, Reid Draper 
> <[email protected]<mailto:[email protected]>> wrote:
> 
> Paul,
> 
> It looks like you're running a 3-node cluster. If two of the nodes fail, 
> you'll likely
> not be able to run `coverage` queries like 2i and list-keys. If you need to 
> be able
> to sustain losing 2 nodes and still successfully run 2i, I'd suggest running 
> at least
> a 5 node cluster.
> 
> Reid
> 
> 
> On Sep 17, 2012, at 6:07 AM, Paul Scheltema 
> <[email protected]<mailto:[email protected]>> wrote:
> 
> recently 2 of the vm's running riak crashed. (probably not due to riak)
> When i now run "curl $riak/buckets/$2/keys?keys=true" i get the following 
> error message:
> 
> <html><head><title>500 Internal Server Error</title></head><body><h1>Internal 
> Server Error</h1>The server encountered an error while processing this 
> request:<br><pre>{error,{error,{badmatch,{error,insufficient_vnodes_available}},
>              [{riak_kv_wm_keylist,produce_bucket_body,2},
>               {webmachine_resource,resource_call,3},
>               {webmachine_resource,do,3},
>               {webmachine_decision_core,resource_call,1},
>               {webmachine_decision_core,decision,1},
>               {webmachine_decision_core,handle_request,2},
>               {webmachine_mochiweb,loop,1},
>               
> {mochiweb_http,parse_headers,5}]}}</pre><P><HR><ADDRESS>mochiweb+webmachine 
> web server</ADDRESS></body></html>
> 
> == ring_status
> root@03:/usr/local/riak/bin# ./riak-admin ring_status
> ================================== Claimant 
> ===================================
> Claimant:  '[email protected]<mailto:[email protected]>'
> Status:     up
> Ring Ready: true
> 
> ============================== Ownership Handoff 
> ==============================
> No pending changes.
> 
> ============================== Unreachable Nodes 
> ==============================
> All nodes are up and reachable
> 
> == ring ready
> root@03:/usr/local/riak/bin# ./riak-admin ringready
> TRUE All nodes agree on the ring 
> ['[email protected]<mailto:[email protected]>',
>                                  
> '[email protected]<mailto:[email protected]>',
>                                  
> '[email protected]<mailto:[email protected]>']
> 
> == member status
> root@03:/usr/local/riak/bin# ./riak-admin member_status
> ================================= Membership 
> ==================================
> Status     Ring    Pending    Node
> -------------------------------------------------------------------------------
> valid      34.4%      --      
> '[email protected]<mailto:[email protected]>'
> valid      32.8%      --      
> '[email protected]<mailto:[email protected]>'
> valid      32.8%      --      
> '[email protected]<mailto:[email protected]>'
> -------------------------------------------------------------------------------
> Valid:3 / Leaving:0 / Exiting:0 / Joining:0 / Down:0
> 
> == ulimit:
> root@03:/usr/local/riak/etc# ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 15584
> max locked memory       (kbytes, -l) 64
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 15584
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> 
> 
> --
> groeten
> /paul
> 
> _______________________________________________
> riak-users mailing list
> [email protected]<mailto:[email protected]>
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> _______________________________________________
> riak-users mailing list
> [email protected]<mailto:[email protected]>
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> 
> 
> Mobile: + 45 2343 4626 | Skype: krestenkrabthorup | Twitter: @drkrab
> Trifork A/S  |  Margrethepladsen 4  | DK- 8000 Aarhus C |  Phone : +45 8732 
> 8787  |  www.trifork.com<http://www.trifork.com>
> 
> 
> 
> 


_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to