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



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97635>

    How about: "Recovering from a scheduler backup"



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97640>

    This is a bit doom-and-gloom, and jarrin to the reader since it doesn't 
include background.  What does 'prepare' mean?  What does 'data loss' mean?
    
    Consider re-wording to something like:
    
    > Be sure to read the entire page before attempting to restore from a 
backup, as it may have unintendd consequences.



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97642>

    "requires full scheduler outage" is ambiguous, and sounds scary.  How about 
"requires all schedulers to be taken down temporarily while restoring."



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97645>

    I'd also add:
    
    > Usually, it is a bad idea to attempt to restore an update that is not 
extremely recent, usually less then a few hours old.  This is because the 
scheduler will expect the cluster to look exactly as the backup does, so any 
tasks that have been rescheduled since the backup was taken will be killed.



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97647>

    Is the "and disable..." part necessary?  Presumably an operator knows to 
use the process manager to stop a scheduler.



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97648>

    Please elaborate on "concurrent access"



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97649>

    Please elaobrate on the purpose of "prevent[ing] accidental task GC".



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97655>

    Some prose in each of these sections would help a lot to improve flow of 
the document.  For example, at this point i'm not clear if i'm assessing the 
damage of the scheduler configuration changes i made in 'preparation'.



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97651>

    Avoid falling back to HTML if you can.  In this case, triple backticks will 
do the same thing.



docs/storage_recovery.md
<https://reviews.apache.org/r/26851/#comment97657>

    How do i know the integrity of the replicated log?


- Bill Farner


On Oct. 17, 2014, 1:51 a.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26851/
> -----------------------------------------------------------
> 
> (Updated Oct. 17, 2014, 1:51 a.m.)
> 
> 
> Review request for Aurora, Kevin Sweeney and Bill Farner.
> 
> 
> Bugs: AURORA-839
>     https://issues.apache.org/jira/browse/AURORA-839
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Summarizing recovery from backup steps.
> 
> 
> Diffs
> -----
> 
>   docs/storage_recovery.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/26851/diff/
> 
> 
> Testing
> -------
> 
> https://github.com/maxim111333/incubator-aurora/blob/storage_config_doc/docs/storage_recovery.md
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to