[
https://issues.apache.org/jira/browse/HBASE-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618164#comment-13618164
]
Lars Hofhansl commented on HBASE-8229:
--------------------------------------
If we skip, we can never go back a reapply these edits; I don't think that
would be a good idea.
Like Jieshan I was thinking we should treat like the peer cluster is not
available (at least in terms waiting - we do not have the rechoose the sinks in
that case).
> Replication code logs like crazy if a target table cannot be found.
> -------------------------------------------------------------------
>
> Key: HBASE-8229
> URL: https://issues.apache.org/jira/browse/HBASE-8229
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
>
> One of our RS/DN machines ran out of diskspace on the partition to which we
> write the log files.
> It turns out we still had a table in our source cluster with
> REPLICATION_SCOPE=>1 that did not have a matching table in the remote cluster.
> In then logged a long stack trace every 50ms or so, over a few days that
> filled up our log partition.
> Since ReplicationSource cannot make any progress in this case anyway, it
> should probably sleep a bit before retrying (or at least limit the rate at
> which it spews out these exceptions to the log).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
