accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Marion (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3090) VolumeChooser should be able to decide per-file
Date Fri, 29 Aug 2014 15:10:53 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115313#comment-14115313
] 

Dave Marion commented on ACCUMULO-3090:
---------------------------------------

I would argue that Accumulo does not currently have a Backup & Recovery strategy. At least
with mutliple volumes you could create a backup by copying the files on each namespace to
the other by: 

1. quiesce or shutdown the database
2. use the HDFS snapshot feature to create a snapshot of each volume
3. un-quiesce or start up the database
4. Distcp the snapshot to the other volume.

Recovery scenarios will be different depending on the circumstances.

> 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)

Mime
View raw message