common_state_backends_section.html

<table class="configuration table table-bordered">
    <thead>
        <tr>
            <th class="text-left" style="width: 20%">Key</th>
            <th class="text-left" style="width: 15%">Default</th>
            <th class="text-left" style="width: 10%">Type</th>
            <th class="text-left" style="width: 55%">Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><h5>state.backend.type</h5></td>
            <td style="word-wrap: break-word;">"hashmap"</td>
            <td>String</td>
            <td>The state backend to be used to store state.<br />The implementation can be specified either via their shortcut  name, or via the class name of a <code class="highlighter-rouge">StateBackendFactory</code>. If a factory is specified it is instantiated via its zero argument constructor and its <code class="highlighter-rouge">StateBackendFactory#createFromConfig(ReadableConfig, ClassLoader)</code> method is called.<br />Recognized shortcut names are 'hashmap' and 'rocksdb'.</td>
        </tr>
        <tr>
            <td><h5>state.checkpoint-storage</h5></td>
            <td style="word-wrap: break-word;">(none)</td>
            <td>String</td>
            <td>The checkpoint storage implementation to be used to checkpoint state.<br />The implementation can be specified either via their shortcut  name, or via the class name of a <code class="highlighter-rouge">CheckpointStorageFactory</code>. If a factory is specified it is instantiated via its zero argument constructor and its <code class="highlighter-rouge">CheckpointStorageFactory#createFromConfig(ReadableConfig, ClassLoader)</code>  method is called.<br />Recognized shortcut names are 'jobmanager' and 'filesystem'.<br />'state.checkpoint-storage' and 'state.checkpoints.dir' are usually combined to configure the checkpoint location. By default,  the checkpoint meta data and actual program state will be stored in the JobManager's memory directly. When 'state.checkpoint-storage' is set to 'jobmanager', if 'state.checkpoints.dir' is configured, the meta data of checkpoints will be persisted to the path specified by 'state.checkpoints.dir'. Otherwise, the meta data will be stored in the JobManager's memory. When 'state.checkpoint-storage' is set to 'filesystem', a valid path must be configured to 'state.checkpoints.dir', and the checkpoint meta data and actual program state will both be persisted to the path.</td>
        </tr>
        <tr>
            <td><h5>state.checkpoints.dir</h5></td>
            <td style="word-wrap: break-word;">(none)</td>
            <td>String</td>
            <td>The default directory used for storing the data files and meta data of checkpoints in a Flink supported filesystem. The storage path must be accessible from all participating processes/nodes(i.e. all TaskManagers and JobManagers). If the 'state.checkpoint-storage' is set to 'jobmanager', only the meta data of checkpoints will be stored in this directory.</td>
        </tr>
        <tr>
            <td><h5>state.savepoints.dir</h5></td>
            <td style="word-wrap: break-word;">(none)</td>
            <td>String</td>
            <td>The default directory for savepoints. Used by the state backends that write savepoints to file systems (HashMapStateBackend, EmbeddedRocksDBStateBackend).</td>
        </tr>
        <tr>
            <td><h5>execution.state-recovery.from-local</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>This option configures local recovery for the state backend, which indicates whether to recovery from local snapshot.By default, local recovery is deactivated. Local recovery currently only covers keyed state backends (including both the EmbeddedRocksDBStateBackend and the HashMapStateBackend)."</td>
        </tr>
        <tr>
            <td><h5>state.backend.incremental</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>Option whether the state backend should create incremental checkpoints, if possible. For an incremental checkpoint, only a diff from the previous checkpoint is stored, rather than the complete checkpoint state. Once enabled, the state size shown in web UI or fetched from rest API only represents the delta checkpoint size instead of full checkpoint size. Some state backends may not support incremental checkpoints and ignore this option.</td>
        </tr>
        <tr>
            <td><h5>state.checkpoint.cleaner.parallel-mode</h5></td>
            <td style="word-wrap: break-word;">true</td>
            <td>Boolean</td>
            <td>Option whether to discard a checkpoint's states in parallel using the ExecutorService passed into the cleaner</td>
        </tr>
        <tr>
            <td><h5>state.checkpoints.num-retained</h5></td>
            <td style="word-wrap: break-word;">1</td>
            <td>Integer</td>
            <td>The maximum number of completed checkpoints to retain.</td>
        </tr>
        <tr>
            <td><h5>taskmanager.state.local.root-dirs</h5></td>
            <td style="word-wrap: break-word;">(none)</td>
            <td>String</td>
            <td>The config parameter defining the root directories for storing file-based state for local recovery. Local recovery currently only covers keyed state backends. If not configured it will default to &lt;WORKING_DIR&gt;/localState. The &lt;WORKING_DIR&gt; can be configured via <code class="highlighter-rouge">process.taskmanager.working-dir</code></td>
        </tr>
    </tbody>
</table>