[
https://issues.apache.org/jira/browse/ACCUMULO-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115476#comment-14115476
]
Sean Busbey commented on ACCUMULO-3090:
---------------------------------------
{quote}
So, when Sean asked how a tablet spread across volumes would affect disaster
recovery, I took it to mean backup and recovery.
{quote}
Correct, I meant recovering a given crashed cluster. Replication is needed for
a real disaster recovery plan, but there will be plenty of folks who need to
fix broken systems without having a hot-swappable backup.
Even those with one would probably prefer to avoid copying as much as possible,
esp those who have large enough clusters to warrant the complications of
multiple volumes.
For example, how does [recovering from a lost ZK
quorum|http://accumulo.apache.org/1.6/accumulo_user_manual.html#zookeeper_failure]
get impacted if the files for a given tablet are spread across volumes?
> VolumeChooser should be able to decide per-file
> -----------------------------------------------
>
> Key: ACCUMULO-3090
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3090
> Project: Accumulo
> Issue Type: Improvement
> Affects Versions: 1.6.0
> Reporter: Christopher Tubbs
>
> Currently, the VolumeChooser decides only once per-tablet which volume to use
> for that tablet. The directory is "sticky" after the decision is made. This
> can cause unexpected behavior for users, which makes it harder to manage
> volume usage/capacity.
> One unexpected behavior is that data will still be written to an existing
> tablet's predetermined volume, even if the volume is removed from
> instance.volumes.
> Another unexpected behavior this causes for users is when adding a new
> volume. One might expect to compact tablets after adding a new volume, and
> have the new usage to be balanced across all the volumes (using the provided
> RandomVolumeChooser), but due to the stickiness, that is not the behavior
> seen. Instead, only new tablets (from new tables, or new splits) will begin
> to randomly use the new volume.
> If the sticky behavior is desired, a volume chooser could still do that, by
> accepting a "preferredTabletVolume"/"preferredTabletDirectory" in its
> environment, provided by the caller, to use to make decisions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
