Hi team, I'm still using druid (~ 5 years), I'm running Druid 27 and trying to separate the coordinator from the overlord (previously running in combined mode with

druid.coordinator.asOverlord.enabled=true

). Problem: After applying the new configuration with separate coordinator and overlord StatefulSets, the coordinator keeps crashing with OOM errors. What I've done: 1. Updated the Druid CR to have separate

coordinators

and

overlords

sections 2. Deleted the existing coordinator StatefulSet (required due to immutable field changes like port) 3. Manually created the missing task tables (

druid_tasks

,

druid_tasklogs

,

druid_tasklocks

) since they didn't exist - my metadata DB only had the 7 base tables (druid_audit, druid_config, druid_datasource, druid_pendingsegments, druid_rules, druid_segments, druid_supervisors) 4. Schema I used: https://gist.github.com/renatocron/8056649b67cc53b02a44a6f98fd30d5b - generated via claude from server/src/main/java/org/apache/druid/metadata/SQLMetadataStorageActionHandler.java - this file do not exists anymore in 35 Current state: • Tables are created, no more "relation does not exist" errors But coordinator is now OOM crashing, I reverted everthing and dropped tables now, I set druid.metadata.storage.connector.createTables=true on coordinator but even then it would not ceate table, was this a bug in the older version?

How much heap are you giving it compared to the previous config?

I had been using the following for years:

extra.jvm.options: |-
    -Xms1664m
    -Xmx1664m

I then changed it to:

extra.jvm.options: |-
    -Xms1664m
    -Xmx2664m

I made the change because I saw a sudden coordinator restart. I only discovered today that in this mode it doesn’t track tasks properly, which is why it wasn’t using the table correctly. I thought, “Okay, this means it’s time to separate the roles,” but since that was taking too long, I reverted the change. Later today I found out the sudden restart was actually caused by the descheduler. Yesterday I changed some configs during the Cloudflare outage, so I think the cluster temporarily violated the anti-affinity rule.