[
https://issues.apache.org/jira/browse/IGNITE-27466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-27466:
-------------------------------------
Description:
On node restart, in case of not null LWM earliest catalog version will be
calculated as
{code:java}
catalogService.activeCatalogVersion(lwm.longValue(){code}
In that case, destructionEventsQueue won't be populated with DestroyZoneEvent,
and thus abandoned zone resources won't be handled. Proper abandoned resource
handling assumes corresponding zone partitions startup if there are records in
txStateStorage (it's required since corresponding records might be used for WI
resolution), otherwise all zone resources should be dropped.
* TableManager#cleanUpResourcesForDroppedTablesOnRecoveryBusy might be used as
a reference of how to detect abandoned resources.
* PartitionReplicaLifecycleManager#removeZonePartitionsIfPossible might be
used as a reference of resources to be dropped on cleanup.
There are at least two alternative approaches:
* Prevent catalog compaction, if there are non-handled dropped resources and
evaluate earliestCatalogVersion as
catalogService.earliestCatalogVersion(). In that case destructionEventsQueue
repopulation will do the trick:
{code:java}
if (nextCatalog0 != null && nextCatalog0.zone(zoneId) == null) {
destructionEventsQueue.enqueue(new DestroyZoneEvent(nextCatalog0.version(),
zoneId));
}{code}
* Or it's possible to persist destructionEventsQueue on it's own.
> Handle abandoned resources for destroyed zones in catalog
> ---------------------------------------------------------
>
> Key: IGNITE-27466
> URL: https://issues.apache.org/jira/browse/IGNITE-27466
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
>
> On node restart, in case of not null LWM earliest catalog version will be
> calculated as
> {code:java}
> catalogService.activeCatalogVersion(lwm.longValue(){code}
> In that case, destructionEventsQueue won't be populated with
> DestroyZoneEvent, and thus abandoned zone resources won't be handled. Proper
> abandoned resource handling assumes corresponding zone partitions startup if
> there are records in txStateStorage (it's required since corresponding
> records might be used for WI resolution), otherwise all zone resources should
> be dropped.
> * TableManager#cleanUpResourcesForDroppedTablesOnRecoveryBusy might be used
> as a reference of how to detect abandoned resources.
> * PartitionReplicaLifecycleManager#removeZonePartitionsIfPossible might be
> used as a reference of resources to be dropped on cleanup.
> There are at least two alternative approaches:
> * Prevent catalog compaction, if there are non-handled dropped resources and
> evaluate earliestCatalogVersion as
> catalogService.earliestCatalogVersion(). In that case destructionEventsQueue
> repopulation will do the trick:
> {code:java}
> if (nextCatalog0 != null && nextCatalog0.zone(zoneId) == null) {
> destructionEventsQueue.enqueue(new
> DestroyZoneEvent(nextCatalog0.version(), zoneId));
> }{code}
> * Or it's possible to persist destructionEventsQueue on it's own.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
