Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 20 Jun 2014 16:53:25 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12722815.1403282425872.18293.1403283205726@arcas>
In-Reply-To: <JIRA.12722815.1403282425872@arcas>
References: <JIRA.12722815.1403282425872@arcas>
Subject: [jira] [Commented] (ACCUMULO-2932) Increased control over write
 durability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Elser commented on ACCUMULO-2932:
--------------------------------------

bq. It would be preferable to prevent tablets that have different durability configurations from using the same WAL. Presuming that the user configuring things tunes down durability on some table because they need the performance gain.

This would be much easier if a tablet could use multiple WALs (ACCUMULO-1083), but that's a difficult problem in itself. Specifying the explicit file name log in each tablet row does make this easier to track, but it's not required to do what it outlined here.

bq. Should we really always sync the WALs involved in accumulo.metadata? I can see defaulting to it or even requiring that changing it be done at the table level (presuming we still ahve some system-wide default used for tables). But what if the user has stable backup power and isn't worried about other sources of sudden machine loss?

Sure, that's a valid point.

> Increased control over write durability
> ---------------------------------------
>
>                 Key: ACCUMULO-2932
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2932
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Josh Elser
>
> ACCUMULO-2842 introduced the ability to configure the HDFS method that is use to sync WALs. This was mainly done as a means to investigate the performance characteristic of hflush and hsync. As such, it was was trivially done system-wide.
> However, there is also practical application to allowing this configuration, in addition to some internal concerns.
> # We should *always* sync WALs involved in {{accumulo.metadata}}
> # Data loss may be acceptable on some user tables and not on others (we may want to use hflush for some tables, hsync for other). The option must have the granularity to specify at least on the table (if not locality group).
> When multiple tablets are using a WAL with differing durability guarantees, we should choose the higher durability.
> If we compare this to HBase, we could also implement it on the per Mutation level, however that's beyond the scope here.


--
This message was sent by Atlassian JIRA
(v6.2#6252)