Skip to content

Latest commit

 

History

History
150 lines (118 loc) · 4.34 KB

File metadata and controls

150 lines (118 loc) · 4.34 KB

Configuration

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).

Important
Do not override port numbers. This will lead to faulty installations.

Configuration Properties

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

  • access-control.properties

  • config.properties

  • node.properties

  • security.properties

  • exchange-manager.properties

  • spooling-manager.properties

For a list of possible configuration properties consult the Trino Properties Reference.

Tip
For fault-tolerant execution configuration, use the dedicated faultTolerantExecution section in the cluster configuration instead of configOverrides. See usage-guide/fault-tolerant-execution.adoc for detailed instructions.
workers:
  roleGroups:
    default:
      config: {}
      replicas: 1
      configOverrides:
        config.properties:
          query.max-memory-per-node: "2GB"

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

workers:
  configOverrides:
    config.properties:
      query.max-memory-per-node: "2GB"
  roleGroups:
    default:
      config: {}
      replicas: 1

All override property values must be strings. The properties are passed on without any escaping or formatting.

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 414, Trino performs poorly if the positive cache is disabled. To cache resolved host names, and thus speeding up queries you can configure the TTL of entries in the positive cache like this:

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

Environment Variables

Environment variables can be (over)written by adding the envOverrides property.

For example per role group:

workers:
  roleGroups:
    default:
      config: {}
      replicas: 1
      envOverrides:
        JAVA_HOME: "path/to/java"

or per role:

workers:
  envOverrides:
    JAVA_HOME: "path/to/java"
  roleGroups:
    default:
      config: {}
      replicas: 1

Here too, overriding properties such as http-server.https.port will lead to broken installations.

Resource Requests

home:concepts:stackable_resource_requests.adoc

A minimal HA setup consisting of 1 coordinator and 2 worker instances has the following resource requirements:

  • 3350m CPU request

  • 11700m CPU limit

  • 12704m memory request and limit

  • 3072Mi persistent storage

Corresponding to the values above, the operator uses the following resource defaults:

spec:
  coordinators:
    config:
      resources:
        cpu:
          min: '500m'
          max: '2000m'
        memory:
          limit: '4Gi'
  workers:
    config:
      resources:
        cpu:
          min: '1000m'
          max: '4000m'
        memory:
          limit: '4Gi'
Warning
The default values are most likely not sufficient to run a proper cluster in production. Adapt according to your requirements.