[
https://issues.apache.org/jira/browse/PHOENIX-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954218#comment-16954218
]
Geoffrey Jacoby commented on PHOENIX-5527:
------------------------------------------
Haven't had a chance to go through the patch yet, but initial thoughts:
# I like the idea of making the full write just part of step 3 and just having
the single KeyValue of indexedkey/UNVERIFIED_BYTES on step 1.
# I'm worried that in a case of multiple writers, the ts -1 on step 1 would
potentially "unverify" a previously verified row that had been committed one ms
prior to the current write. That would seem to impact correctness. We currently
have locking logic in place to make sure that there's no conflicting write at
ts = now, but not ts = now - 1. Does this patch address this case?
# I consider the previous solution (clean up once a week) to be fine, so no
need to rush this.
> Unverified index rows should not be deleted due to replication lag
> -------------------------------------------------------------------
>
> Key: PHOENIX-5527
> URL: https://issues.apache.org/jira/browse/PHOENIX-5527
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.0.0, 4.14.3
> Reporter: Kadir OZDEMIR
> Assignee: Kadir OZDEMIR
> Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5527.master.001.patch,
> PHOENIX-5527.master.002.patch
>
>
> The current default delete time for unverified index rows is 10 minutes. If
> an index table row is replicated before its data table row and the
> replication row is unverified at the time of replication, it can be deleted
> when it is scanned on the destination cluster. To prevent these deletes due
> to replication lag issues, we should increase the default time to 7 days.
> This value is configurable using the configuration parameter,
> phoenix.global.index.row.age.threshold.to.delete.ms.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
