[
https://issues.apache.org/jira/browse/HBASE-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618218#comment-13618218
]
Lars Hofhansl commented on HBASE-8229:
--------------------------------------
yeah, I think that is out of the question. The replication marks the last edit
it sent to the peer(s); if we skip edits we would have to keep track of ranges
of edit that are still outstanding, or lose replication data.
Presumably if you marked a table with REPLCATION_SCOPE = 1 you want that
table's data to replicated. An admin can fix this by dropping the table or to
setting REPLICATION_SCOPE back to 0 (at least that is how should work - need to
look at the code again).
For this issue, I'll just add the same waiting we do when the peer is down
(which is the same logical behavior we currently have, but without the insane
busy retrying).
> 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
