[
https://issues.apache.org/jira/browse/KUDU-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KUDU-521:
-----------------------------
Labels: roadmap-candidate scalability (was: )
> 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
> Labels: roadmap-candidate, scalability
>
> 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
(v8.3.4#803005)
