Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Enhance handling of Flint index data deletion to prevent dangling metadata log entry #356

Closed
dai-chen opened this issue May 23, 2024 · 0 comments
Assignees
Labels
0.5 enhancement New feature or request

Comments

@dai-chen
Copy link
Collaborator

dai-chen commented May 23, 2024

Is your feature request related to a problem?

Currently, users can directly delete an OpenSearch index without using DROP and VACUUM index statement. This action can lead to issues where the index cannot be recreated because the metadata log entry persists. This scenario occurs frequently when indices are created with auto-refresh enabled, which can lead to errors.

Although the recent improvements in pre-validation (as seen in PR#297) have reduced these incidents, it is still possible for an OpenSearch index to be left dangling after a forceful deletion.

What solution would you like?

Enhances the handling of direct Flint index data deletions, particularly one that can intelligently manage or clean up metadata logs to avoid leaving dangling indices. This could possibly involve additional checks or cleanup processes when an index is deleted.

What alternatives have you considered?

One alternative is to improve user education regarding the management of indices. Users could be encouraged to use Flint SQL for index manipulations and avoid direct interactions with the OpenSearch index. However, this approach relies heavily on user compliance.

Do you have any additional context?

We've added such cleanup logic in recoverIndex API in #241.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.5 enhancement New feature or request
Development

No branches or pull requests

1 participant