[jira] [Updated] (KUDU-521) Consider splitting the WAL in two, one for replicated operations and one for local operations

["Mike Percy (JIRA)" <ji...@apache.org>]

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

Mike Percy updated KUDU-521:
----------------------------
    Parent: KUDU-560

> Consider splitting the WAL in two, one for replicated operations and one for local operations
> ---------------------------------------------------------------------------------------------
>
>                 Key: KUDU-521
>                 URL: https://issues.apache.org/jira/browse/KUDU-521
>             Project: Kudu
>          Issue Type: Sub-task
>          Components: consensus, log
>    Affects Versions: Backlog
>            Reporter: David Alves
>            Priority: Minor
>
> Currently we rewrite the wal on replay because it has both local (the commits) and replicated operations (the replicates). But we could potentially split this in two separate WALs, one for the consensus replicated stuff and one for the local stuff.
> Keeping 2 different wals would have the following advantages:
> - Only replicates would be fsynced for writes.
> - On bootstrap the replicates WAL would not have to be rewritten
> - Replicate WAL segments could be checksummed across machines to make sure they are the same.
> - The order of commits w.r.t. replicates would not matter.
> - Flushing the WAL queue before we write the meta would only concern the "local" WAL.
> ... and the following disadvantages:
> - On bootstrap replaying would be slightly more complex. One would have to read from the replicated WAL and then advance the local wal until we find the commits we want.
> - GC would be more complex (but not as complex as dealing with commits before replicates in the current version though).



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