[Question] Restarting redisearch sometimes doesn't reload all indexes from disk #4471
Comments
|
Cancelling background indexing should only happen if the index was altered with |
|
We don't drop indexes. But it's really imposible to tell if that happened or not. We went through the whole aof file and didn't find any evidence of drops. But the file is just a segment. Is there another way to ensure that that command didn't happen? Thank for the response. @GuyAv46 |
|
No problem :) |
|
It's a single Redis contianer, running with docker-compose inside of a VM. Something like this: Here's the |
|
Thank you for your cooperation!
After I'll dig a bit deeper on the AOF section, I can confirm there is no real problem, and that the scans were canceled because the index was actually dropped in the AOF file. Can you add the output of |
|
Thank you here's the ft._list Is there a way to reconstruct the who AOF file? given that's its partial? Got these files: |
|
So basically the AOF mechanism includes a manifest file, a base RDB, and an incremental file/s. Depending on your setup, every once in a while a forked process "applies" the changes in the When loading an index from an RDB, there is no BG indexing and when the loading is done the index is ready. The AOF file contains more commands to apply, and it may create or delete indexes and thus may trigger a background scan. Since the entire loading event happens while holding the redis GIL, the BG index tasks cannot start until the entire loading process is done. When it's done (at the The RDB file is binary, but the AOF incremental files are mostly text and you can verify that the indexes that got their BG scan canceled are both created and dropped in it. TL;DR: Not a bug. expected and correct behavior. You can read more about AOF and persistence here. |
GuyAv46
changed the title
|
Thanks for the explanation! That makes 100% sense. What I'm trying to understand then is why these indexes try to get loaded and get cancelled, given that the AOF (latest segment) file doesn't have any I just want to make 100% sure that command actually happen to ensure that my setup isn't somehow dropping data in some other way. Please let me know if my assumptions are incorrect, and again thanks for your help. |
|
Yes, if an index was dropped and the change was applied to the RDB file, it won't be created when loaded. We can also see in the log what indexes were created from the RDB (before |
|
This issue is stale because it has been open for 60 days with no activity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I'm running redisearch in a docker container, sometimes it restarts and doesn't load all of the data from disk.
Here's the startup logs:
I noticed these:
So for some reason some of these operations are getting
cancelled. I believe causing some indexes to not get created.Expected behavior
All indexes get re-created.
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: