Upgrade one KSQL server at a time (i.e. rolling restart). The remaining KSQL servers should have sufficient spare capacity to take over temporarily for unavailable, restarting servers.
Upgrading from KSQL 0.x (Developer Preview) to KSQL 4.1¶
KSQL 4.1 is not backward-compatible with the previous KSQL 0.x developer preview releases.
In particular, you must manually migrate queries running in the older preview releases of KSQL to the 4.1 version by
issuing statements like
CREATE STREAM and
CREATE TABLE again.
Notable changes in 4.1:
ksql-clicommand was renamed to
- The CLI no longer supports what was formerly called “standalone” or “local” mode, where
ksql-cliwould run both the CLI and also a KSQL server process inside the same JVM. In 4.1,
ksqlwill only run the CLI. For local development and testing, you can now run
confluent start(which will also launch a KSQL server), followed by
ksqlto start the CLI. This setup is used for the Confluent Platform quickstart. Alternatively, you can start the KSQL server directly as described in Starting the KSQL Server, followed by
ksqlto start the CLI.
- The default
listenersaddress was changed to
http://localhost:8088(KSQL 0.x used
- Assigning KSQL servers to a specific KSQL cluster has been simplified and is now done with the
ksql.service.idsetting. See Configuring KSQL Server for details.
- The default
.sqlfiles: To run pre-defined KSQL queries stored in a
.sqlfile, see Non-interactive (Headless) KSQL Usage.
Configuration: Advanced KSQL users can configure the Kafka Streams and Kafka producer/consumer client settings used by KSQL. This is achieved by using prefixes for the respective configuration settings. See KSQL Configuration Parameter Reference as well as Configuring KSQL Server and Configuring KSQL CLI for details.