[
https://issues.apache.org/jira/browse/HBASE-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002552#comment-14002552
]
Enis Soztutar commented on HBASE-11183:
---------------------------------------
Thanks Stack for taking a look.
bq. When is phase 1 coming in? How is it going?
Phase 1 work is nearly finished. Out of 40+ subtasks and linked issues of
HBASE-10070, all of the 5 remaining jiras are not critical, and can be done in
phase 2. We'll send an overview to the dev list soon.
bq. What happens again if a file is compacted away and the replica tries to
read it?
We read the file from the archive location as long as HFile TTL is set long
enough it should be fine. Otherwise the secondary will reject the request. The
user documentation at HBASE-10513 mentions this in the configuration settings:
(referring to hbase.regionserver.storefile.refresh.period) If the files cannot
be refreshed for longer than HFile TTL (hbase.master.hfilecleaner.ttl) the
requests are rejected. Configuring HFile TTL to a larger value is also
recommended with this setting.
bq. Throw the exception to the replicating client only?
Yes. Only to the replicating client.
bq. Anoop needs something like this for his in-memory compaction of memstores.
Yep, I think I am watching that issue. This is useful in general.
bq. Are "Memstore snapshots on the secondary (no flushes for the secondary
regions) " and "Allow Flushes for the secondary regions " mutually exclusive –
one or the other?
I think they are. We would like to evaluate both approaches to see which one we
should go with.
bq. X-DC replication, each regionserver hosts a client that writes the WAL
edits to a RS on remote cluster for it to distribute. Here, we'd host the
distributing HTable instance inside the src RS?
Yes. We can directly do puts against the secondary regions in the replication
thread.
bq. How will this work?
I think we can call the flush RPC and wait until we see that event. Actually,
we will not start serving until we see the flush, so it is after region open
and before serving.
bq. So, replication will update zk per region? What sort of update rates in zk
you thinking?
Initial design was a replication queue per region. Now it is replication queue
per table per region replication count. (2 tables with 3 region replicas = 2 *
(3-1) queues).
bq. Is this what the client does currently when replicating? Send WAL*s? These
are FAAAAAATTTTT objects.
It is using:
{code}
message ReplicateWALEntryRequest {
repeated WALEntry entry = 1;
}
{code}
> Timeline Consistent region replicas - Phase 2 design
> ----------------------------------------------------
>
> Key: HBASE-11183
> URL: https://issues.apache.org/jira/browse/HBASE-11183
> Project: HBase
> Issue Type: Sub-task
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Attachments: PhaseIIDesignforHBASE-10070.pdf
>
>
> Now that Phase 1 of parent issue HBASE-10070 is mostly done, it is time to
> think about remaining items in Phase 2 as per the design doc
> https://issues.apache.org/jira/secure/attachment/12616659/HighAvailabilityDesignforreadsApachedoc.pdf
> Phase 2 will conclude the work and include at least the following major
> features:
> - Async WAL Replication
> - Replication Interface changes (HBASE-10504)
> - Replication should guarantee seqId order (for region moves and RS failure)
> - Flush / Compaction events should be written to WAL
> - Flush / Memstore handling from secondary regions
> - Region split / merge handling for replicated regions
> In this issue, we can discuss the proposed design, and keep it as like a
> parent jira for Phase 2 work. We'll open subtasks agains the HBASE-10070 jira
> for individual patches.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
