accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser" <josh.el...@gmail.com>
Subject Re: Review Request 24855: ACCUMULO-1454 design doc
Date Thu, 21 Aug 2014 16:58:47 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24855/#review51183
-----------------------------------------------------------


Thanks for the changes, Keith. I think this is much more approachable. I'm guessing that there
are still some devils lying in wait, but I like the general approach.


docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment89206>

    The re-assignment of the tablets from the node that was restarted should get reassigned
back to that node because of the last location in for the tablet, right?



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment89209>

    stop-here.sh and start-here.sh already can't be used when running more than one tserver
per host (e.g. Slider -- accumulo on yarn) because those scripts assume that there is only
one process per node.
    
    This is a bigger problem in regards to the assumptions that the scripts make. I've come
to the conclusion already that we need to rethink the scripts to support this.
    
    I think what you've outlined for rolling restarts still makes sense with multiple tservers
per host (assuming the last loc is host:port and not just host)



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment89210>

    Important to note that some properties (instance.* specifically) cannot be changed and
restarted sequentially as the SystemCredential will have changed.



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment89211>

    Preemption is a big consideration here in regards to major compactions and scans.
    
    MajC's over very large tablets, with iterators applied, could take a significant amount
of time.
    
    Scans which are performing large filtering (IntersectingIterator-like operations) could
induce a bit of extra latency to the user. They shouldn't see it fail (as long as no external
system kills the scan), but it will take a while.
    
    I think with majc we just want to cancel them. Do we wait for scans to finish before unloading?
I can think of considerations for both waiting on them or cancelling them.



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment89212>

    Would decomission(String) do more/less than what `accumulo admin stop tserver` currently
does?


- Josh Elser


On Aug. 20, 2014, 5:40 p.m., kturner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24855/
> -----------------------------------------------------------
> 
> (Updated Aug. 20, 2014, 5:40 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-1454
>     https://issues.apache.org/jira/browse/ACCUMULO-1454
> 
> 
> Repository: accumulo
> 
> 
> Description
> -------
> 
> Positing ACCUMULO-1454 design doc for review
> 
> 
> Diffs
> -----
> 
>   docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/24855/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> kturner
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message