[
https://issues.apache.org/jira/browse/PHOENIX-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960166#comment-16960166
]
Geoffrey Jacoby commented on PHOENIX-5250:
------------------------------------------
[~elserj] [~vkrava4] - the new consistent index framework won't have the
problem, but when upgrading to one of the versions that have it (4.14.3 and up,
and the forthcoming 4.15 and 5.1.0), existing indexes have to be either
upgraded using the new IndexUpgradeTool, or dropped and recreated. New indexes
will get the new framework automatically. Before upgrading a table's indexes,
the old indexing logic will still work (but still have all the problems it had
before, such as this one)
The new framework doesn't use IndexedKeyValues, so there's no longer "faked"
WALEdits that need to be cleaned.
> The accumulated wal files can't be cleaned
> ------------------------------------------
>
> Key: PHOENIX-5250
> URL: https://issues.apache.org/jira/browse/PHOENIX-5250
> Project: Phoenix
> Issue Type: Bug
> Reporter: Jaanai Zhang
> Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: image-2019-04-19-21-31-27-888.png
>
>
> Because of the modification of HBASE-20781, the faked WALEdits won't be
> filtered, all WALEdits will be saved into Memstore with a status that
> inMemstore is true(uses WAL->append method).
> !image-2019-04-19-21-31-27-888.png|width=755,height=310!
> The family array of IndexedKeyValue is WALEdit.METAFAMILY that is used to
> describe a fake WALEdit, and it will put into Memstore with WALedits of data
> table during sync global index.
> WAL files can't be cleaned, except for restarting RS, Many WAL files will
> decrease the percent of disk free.
> !https://gw.alicdn.com/tfscom/TB1n3cDQVzqK1RjSZFCXXbbxVXa.png|width=422,height=159!
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
