Lost splits #1987
Labels
bug
Something isn't working
Comments
|
Can you share the logs of your indexer? In the other issue, it seems you were using kubernetes and local file system as data dir. Maybe you are using an ephemeral file system? |
|
This is most likely the same misconfiguration as #1989. We are happy to help but need more information. |
|
Reopening as it might not be related to #1989. If the problem persists, can you confirm that this is a one server setting and share some of the indexer logs? In your source settings, you seem to have used a template variable. Can you confirm that this is not really the configuration? |
Thanks, I have some scripts to replace the |
|
I give some detail on the #1989, but yes, this problem doesn't like 1989, so I will provide all my configuration. quickwit.yamlindex.yamldocker-compose.yamlprivate quickwit's Dockerfilesome error log |
Closed
|
The splits lost again, and I confirm container never restart. |
|
@yangjinming1062 thank you for the report. The error in the logs are unrelated to your problem. This can happen from time to time, if the hardware hangs etc. This is what I see on this line. Give me a minute to have a look at your docker-compose configuration. |
|
@yangjinming1062 I could not find anything wrong with your configuration.. Can you add the following command attribute to your postgres docker config: postgres:
image: postgres:14.5
command: ["postgres", "-c", "logging_collector=on", "-c", "log_directory=/var/lib/postgresql/data/pglogs", "-c", "log_filename=postgresql.log", "-c", "log_statement=all"]
...It will force postgresql to log all of the statement sent to it into the same directory in your host computer. We can them have a look at them. If the file is more or less empty, it means docker trashed the volume. |
OK, I will add the postgres docker config and try again. |
|
|
|
It seem like the |
|
ah yes mystery solved then! good find! Thank you for your perseverance! |
This time I confirm the index not changed, but split lost. first time split
second time split
some logssplit_id: db log |
|
This is normal behavior.
More explanation: After creating 10 such splits, Quickwit triggered a merge, and merged these 10 splits into one -> 01GDMFPBPQMZ69Z5406WVT12HK. If you sum the number of docs, you should see they match. This grace period is just a way to make sure htat we do not disrupt ongoing search queries. |
Thank you, now I know the merge mechanism. But why did the number of documents change from 76 to 39? Maybe that means I can't find those 37 documents anymore? |
Excellent point. Let me investigate |
|
It is a bug in the UI. The UI is simply summing num docs over all splits. I'm opening an issue. |
|
|
@yangjinming1062 search is meant to ignore splits marked as deleted. If it does not do that it is a bug. Are you sure you just did not simply index more document since last time? Just to be sure can you send the current list of splits (I see you have 7 splits right now). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I used the same way to query, the first time the results, after a few minutes again query query failed
Expected behavior
Same query same result.
Configuration:
Please provide:
`---
version: 0 # File format version.
index_id: traceback
doc_mapping:
field_mappings:
- name: id
type: u64
fast: true
- name: raw_content
type: text
tokenizer: default
record: position
search_settings:
default_search_fields: [raw_content]
sources:
- source_id: source-kafka
source_type: kafka
params:
topic: UserAction
client_params:
bootstrap.servers: $(KAFKA)
group.id: FullText
security.protocol: PLAINTEXT
`
The text was updated successfully, but these errors were encountered: