[ https://issues.apache.org/jira/browse/HBASE-22784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Busbey resolved HBASE-22784. --------------------------------- Resolution: Fixed > OldWALs not cleared in a replication slave cluster (cyclic replication bw 2 > clusters) > ------------------------------------------------------------------------------------- > > Key: HBASE-22784 > URL: https://issues.apache.org/jira/browse/HBASE-22784 > Project: HBase > Issue Type: Bug > Components: regionserver, Replication > Affects Versions: 1.4.9, 1.4.10 > Reporter: Solvannan R M > Assignee: Wellington Chevreuil > Priority: Blocker > Fix For: 1.4.11, 1.5.0 > > Attachments: HBASE-22784.branch-1.001.patch, > HBASE-22784.branch-1.002.patch, HBASE-22784.branch-1.003.patch, > HBASE-22784.branch-1.004.patch > > > When a cluster is passive (receiving edits only via replication) in a cyclic > replication setup of 2 clusters, OldWALs size keeps on growing. On analysing, > we observed the following behaviour. > # New entry is added to WAL (Edit replicated from other cluster). > # ReplicationSourceWALReaderThread(RSWALRT) reads and applies the configured > filters (due to cyclic replication setup, ClusterMarkingEntryFilter discards > new entry from other cluster). > # Entry is null, RSWALRT neither updates the batch stats > (WALEntryBatch.lastWalPosition) nor puts it in the entryBatchQueue. > # ReplicationSource thread is blocked in entryBachQueue.take(). > # So ReplicationSource#updateLogPosition has never invoked and WAL file is > never cleared from ReplicationQueue. > # Hence LogCleaner on the master, doesn't deletes the oldWAL files from > hadoop. > NOTE: When a new edit is added via hbase-client, ReplicationSource thread > process and clears the oldWAL files from replication queues and hence master > cleans up the WALs > Please provide us a solution > -- This message was sent by Atlassian Jira (v8.3.4#803005)