This message was deleted.
# troubleshooting
s
This message was deleted.
s
If they are available on the historicals, are they queryable?, perhaps you could try reingesting them.
s
yes they are available in historical and we can query them
we r doing the delta load and it's keeping the intermediate copies which metadata is aware but we are not able to delete them
kind of similar situation
Any inputs/suggestion
v
In your question you said "Is it possible to move data from historical to deep storage"? In general any data in a historical should already be in deep storage - that is where historicals load their data from. If you find yourself in a situation where a historical has some data that is not in deep storage then you are in deep deep shit. The typical way to get into that situation is if an intern (who will not be named!) messes up an
aws s3
cli command and helpfully cleans your deep storage for you. I pray that you are not actually in that situation. If you are say so and I will try to help as best as I can.
in the second part of your question you mentioned "We have stale segments in deep storage (metadata is not aware of them) and the kill command is not taking care of cleaning." which suggests that you want to clean your deep storage and kill tasks are not working for you. If this is actually where you are then lets all be grateful it is not the previous thing I posted. 😛
So which one is it?
s
we are in second part of situation, druid_segments where used='false' gives the positive number(which shows we have versions of the segments which came with delta load) so we are trying to clean them from deep storage. For example we a dataset with one segment but in deep storage we see 200plus files for it. we tried all possibilities of kill command but the kill command is not working
v
How are you launching the kill task?
Also do you have realtime ingestion in this datasource?
s
we have both batch and stream , this case batch injestion one, below is the jsaon the last segment is on 4-1 so we are killing until 3-31. We are submitting this to the coordinator through curl { "type": "kill", "dataSource": "abc", "interval" : "2022-03-01/2022-03-31" }
v
Can you share the logs for that kill task?
s
we were able to run it successfully after initating it from coordinator dynamic config
Configure the coordinator/runtime.properties with the following
Copy code
druid.coordinator.kill.on=true 
druid.coordinator.kill.durationToRetain=P30D 
druid.coordinator.kill.maxSegments=100
druid.coordinator.kill.period=P1D
• druid.coordinator.kill.on, has to be set to true to trigger the kill task. • druid.coordinator.kill.durationToRetain, data to be retained in the Deep storage. • druid.coordinator.kill.maxSegments, maximum/total segments to be removed per kill task. • druid.coordinator.kill.period, this determines how often to run the kill task.
When we updated our parameters above, nothing was running
so our question is druid.coordinator.kill.on=true only works when we do through coordinator
k
Just read through the thread . The property
druid.coordinator.kill.on
will only take effect on coordinator restart
s
We got that kiran, The point i want to mention is even though u have that property u have to have the job through coordinator otherwise these parameters are of no use.
anyone have idea, where we specify the no of parallel sessions to run with kill job?
k
the job through coordinator otherwise these parameters are of no use.
How are you launching the kill task job ?
v
They are sending a kill task via curl (see above in thread)
k
Ah I see. Yeah we would need to kill task job logs.
anyone have idea, where we specify the no of parallel sessions to run with kill job?
I donot understand what you mean by this. Do you want to control how many kill tasks can run in parallel ?
s
Correct
k
I donot think we can control that. Is there a reason you would want to control it though. I guess after the initial pruning, where it might launch a lot of tasks, things would become stable. No ?