[jira] [Updated] (ACCUMULO-2931) Ensure correct ordering of updates to a tablet across different WALs

["Josh Elser (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ACCUMULO-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Elser updated ACCUMULO-2931:
---------------------------------
    Assignee:     (was: Josh Elser)

> Ensure correct ordering of updates to a tablet across different WALs
> --------------------------------------------------------------------
>
>                 Key: ACCUMULO-2931
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2931
>             Project: Accumulo
>          Issue Type: Bug
>          Components: replication
>            Reporter: Josh Elser
>            Priority: Minor
>
> I was talking to [~enis] today about common replication problems across HBase and Accumulo and he was telling me about the following:
> A tablet is hosted by tserver1 using WAL1. That tablet moves to a different tserver for whatever reason (tserver1 failed, the balancer, etc) and starts getting used by tserver2 with WAL2.
> In the simple case of replicating to another Accumulo instance with servers running NTP, this shouldn't be a big concern because the timestamp assigned to the updates will ensure a final consistent view. However, the intermediate view is incorrect. We can do a better job to ensure that we replicate the data in the correct order.
> We already know the WALs that are used by a tablet and the time in which that tablet began using it (done by the TabletServer before any updates hit that Tablet) in the metadata table. We can use these records, in addition to the timestamp on the {{log}} column entries to determine the correct ordering for this Tablet WRT to all WALs. All the information is present so that the Master can assign the replication work in the correct order.
> Some extra bookkeeping would also be required to either keep that {{log}} column around longer than the minc or recovery, or to record some additional piece of replication metadata that the master can read from the replication table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)