hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8229) Replication code logs like crazy if a target table cannot be found.
Date Sat, 30 Mar 2013 21:37:15 GMT

    [ 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

Mime
View raw message