Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 29 Aug 2014 17:19:54 +0000 (UTC)
From: "Dave Marion (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12737597.1409267876940.3797.1409332794164@arcas>
In-Reply-To: <JIRA.12737597.1409267876940@arcas>
References: <JIRA.12737597.1409267876940@arcas>
Subject: [jira] [Commented] (ACCUMULO-3090) VolumeChooser should be able to
 decide per-file
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

I'm speaking in traditional database terms.

Replication is one way to implement high availability, for example an active - standby pair of databases. Typically in this scenario the standby is lagging behind by some amount of time. A Backup contains the files and metadata associate with a database to recover it fully or to some point in time.

If you use replication only and your active instance fails and cannot be recovered, then you would likely need to copy the entire database from the standby system back to the failed system to bring the database back up.

I'll create a new ticket so we don't continue to hijack this thread.

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