[
https://issues.apache.org/jira/browse/HBASE-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620484#comment-13620484
]
Lars Hofhansl commented on HBASE-8229:
--------------------------------------
Wouldn't it recreate the set of edits to ship in
readAllEntriesToReplicateOrNextFile(...) called from run().
To just last point. Hmm... I see your point. If the table did not exist in the
peer cluster *and* the local replication_scope was changed to 0, do we still
want to ship the data?
I am just concerned that replication will not be able to make any progress for
any table, until the table is created on the peer cluster and there is no other
way out of this situation.
> 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
> Components: Replication
> Reporter: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 8229-0.94.txt, 8229-0.94-V2.txt
>
>
> 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
