[
https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241542#comment-16241542
]
Lars Hofhansl edited comment on HBASE-12091 at 11/7/17 7:04 AM:
----------------------------------------------------------------
Yeah. This is not ready, yet. The test is flawed still.
And with namespaces this throws a completely different exception message, from
I cannot safely extract tablename.
And this
{code}
if (table != null && !conn.getAdmin().tableExists(table)) {
{code}
is the _wrong_ connection. It's the one for the peer - which obviously always
won't have the table if it was dropped at the peer. I need to invent a way to
get a connection to the local cluster.
Let's aim for 1.4.1.
was (Author: lhofhansl):
Yeah. This is not ready, yet. The test is flawed still.
And with namespaces this throws a completely different exception message, from
I cannot safely extract tablename.
Let's aim for 1.4.1.
> Optionally ignore edits for dropped tables for replication.
> -----------------------------------------------------------
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 1.4.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt,
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt,
> 12091-v6-branch-1.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and
> the sink, but the source still has outstanding edits that now it could not
> get rid of. Now all replication is backed up behind these unreplicatable
> edits.
> We should have an option to ignore edits for tables dropped at the source.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
