This message was deleted.
# troubleshootings
Slackbot
10/25/2022, 12:43 PMThis message was deleted.
g
Gian Merlino
10/25/2022, 5:12 PMIt looks like there was a DROP command from the Coordinator; in that case it's normal for stuff to be deleted
Gian Merlino
10/25/2022, 5:12 PMDoes it seem to be causing a problem?
Gian Merlino
10/25/2022, 5:12 PMGenerally, we drop segments that are moving from server-to-server, or that are fully replicated elsewhere
a
Arda
10/26/2022, 5:44 AMthe problem we are dealing with is that, once the coordinator restarted itself we can't access the previously ingested data even though data is stored on the segments. We thought this DROP command is the suspect. If the drop command is natural behavior of the Druid. Is there any config for preventing this drops or how should we approach this problem?
g
Gian Merlino
10/26/2022, 2:19 PMwhen we drop on one server, it should generally be preceded by a load on a different server
Gian Merlino
10/26/2022, 2:19 PMdropping with no loads somewhere else means, for some reason, Druid thinks the data is no longer needed
Gian Merlino
10/26/2022, 2:20 PMI wonder what kind of metadata store you have? Is it possible it's the default (local disk on Coordinator) and it is getting cleared when the Coordinator leader changes, or something like that?
Gian Merlino
10/26/2022, 2:20 PMIf so you should switch to mysql/postgresql metadata store
d
Didip Kerabat
10/27/2022, 5:52 PMFirst thing first, did the UI report less than 100% availability? Because small data shuffling is normal from time to time.
a
Arda
10/28/2022, 7:19 AMthe problem solved by changing the metadatastore local -> postgresql. I guess that was mainly causing the problem as Gian suspected
2 Views