The KSQL servers are run separately from the KSQL CLI client and Kafka brokers. You can deploy servers on remote machines,
VMs, or containers and then the CLI connects to these remote servers.

You can add or remove servers from the same resource pool during live operations, to elastically scale query processing. You
can use different resource pools to support workload isolation. For example, you could deploy separate pools for production
and for testing.

You can only connect to one KSQL server at a time. The KSQL CLI does not support automatic failover to another KSQL server.

Follow these instructions to start KSQL server using the ksql-server-start script.

Tip

These instructions assume you are installing Confluent Platform by using ZIP or TAR archives. For more information, see On-Premises Deployments.

Specify your KSQL server configuration parameters. You can also set any property for the Kafka Streams API, the Kafka
producer, or the Kafka consumer. The required parameters are bootstrap.servers and listeners. You can specify
the parameters in the KSQL properties file or the KSQL_OPTS environment variable. Properties set with KSQL_OPTS
take precedence over those specified in the properties file.

A recommended approach is to configure a common set of properties using the KSQL configuration file and override
specific properties as needed, using the KSQL_OPTS environment variable.

By default KSQL attempts to store its logs in a directory called logs that is relative to the location
of the ksql executable. For example, if ksql is installed at /usr/local/bin/ksql, then it would
attempt to store its logs in /usr/local/logs. If you are running ksql from the default Confluent Platform
location, <path-to-confluent>/bin, you must override this default behavior by using the LOG_DIR variable.