Skip to main content
Version: 3.1

Deploy a SQL draft to production

This document explains how to deploy a SQL draft. The FlinkSQL code of a SQL deployment must be created or updated via deploying corresponding SQL draft.

Background Information​

Unlike a Jar or Python deployment, deploying a SQL draft is the only way to create a SQL deployment.

Procedure​

  1. In the left navigation, click the Namespace selector and select the namespace that you want to open.

  2. Click SQL editor and choose the Drafts tab.

  3. Double click to open the SQL draft and click Deploy in the toolbar.

  4. Enter some comments for this deploy version. Under advanced options, you can choose to deploy to a session cluster rather than a per-job deployment target and skip the validation while deploying. After which, click Confirm.

After clicking on Confirm, your SQL deployment will appear at the top of the deployment list on the Deployments page, after which you can start the deployment process. Additionally, a new SQL draft version will be generated, and you can check it out by clicking the Versions button on the right-side tabs in the SQL editor.

Troubleshooting​

BufferOverflowException with STATEMENT SET​

A STATEMENT SET block with many INSERT INTO statements can cause the deployment to get stuck without reaching the Running state, even after the Flink job starts. The Events tab shows a "job successfully started" event, but the deployment stays in a transitional state. Appmanager logs contain a BufferOverflowException.

Each INSERT INTO statement adds to the size of the deployment resource. When that resource exceeds the appmanager's internal in-memory persistence buffer (32 KB by default), the buffer overflows and the deployment cannot transition to Running.

To resolve this, increase the buffer size by setting appmanager-persistence-inmemory.max-resource-size-bytes in your values.yaml:

vvp:
  appmanager:
    persistence:
      appmanager-persistence-inmemory.max-resource-size-bytes: 131072

The default value is 32768 (32 KB). Set a higher value if your SQL deployment exceeds this limit.

note

If you cannot change the platform configuration, you can reduce the number of INSERT INTO statements in the STATEMENT SET block as a temporary workaround. Statements that share common sub-plans, such as queries that scan the same source table, benefit from being kept in the same STATEMENT SET because the optimizer reuses shared intermediate results.

On this page