Configuration & Environment Overrides

The cluster definition also supports overriding configuration properties and environment variables, either per role or per role group, where the more specific override (role group) has precedence over the less specific one (role).

Overriding certain properties which are set by the operator (such as the HTTP port) can interfere with the operator and can lead to problems.

Configuration Properties

For a role or role group, at the same level of config, you can specify: configOverrides for the following files:

  • runtime.properties

  • jvm.config

  • security.properties

For example, if you want to set the druid.server.http.numThreads for the router to 100 adapt the routers section of the cluster resource like so:

routers:
  roleGroups:
    default:
      config: {}
      configOverrides:
        runtime.properties:
          druid.server.http.numThreads: "100"
      replicas: 1

Just as for the config, it is possible to specify this at role level as well:

routers:
  configOverrides:
    runtime.properties:
      druid.server.http.numThreads: "100"
  roleGroups:
    default:
      config: {}
      replicas: 1

All override property values must be strings.

For a full list of configuration options please refer to the Druid Configuration Reference.

The security.properties file

The security.properties file is used to configure JVM security properties. It is very seldom that users need to tweak any of these, but there is one use-case that stands out, and that users need to be aware of: the JVM DNS cache.

The JVM manages it’s own cache of successfully resolved host names as well as a cache of host names that cannot be resolved. Some products of the Stackable platform are very sensible to the contents of these caches and their performance is heavily affected by them. As of version 26.0.0 Apache Druid performs poorly if the positive cache is disabled. To cache resolved host names, and thus speeding up Druid queries you can configure the TTL of entries in the positive cache like this:

  brokers:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
  coordinators:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
  historicals:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
  middleManagers:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
  routers:
    configOverrides:
      security.properties:
        networkaddress.cache.ttl: "30"
        networkaddress.cache.negative.ttl: "0"
The operator configures DNS caching by default as shown in the example above.

Environment Variables

In a similar fashion, environment variables can be (over)written. For example per role group:

routers:
  roleGroups:
    default:
      config: {}
      envOverrides:
        MY_ENV_VAR: "MY_VALUE"
      replicas: 1

or per role:

routers:
  envOverrides:
    MY_ENV_VAR: "MY_VALUE"
  roleGroups:
    default:
      config: {}
      replicas: 1