Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Zeebe APIs for dual-region operations #4252

Merged
merged 5 commits into from
Sep 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions docs/self-managed/zeebe-deployment/operations/cluster-scaling.md
Original file line number Diff line number Diff line change
Expand Up @@ -369,6 +369,42 @@ curl --request POST 'http://localhost:9600/actuator/cluster/brokers?dryRun=true'
-d '["0", "1", "2", "3"]'
```

##### Replication Factor

The replication factor for all partitions can be changed with the `replicationFactor` request parameter. If not specified, the replication factor remains unchanged.

The new replicas will be assigned to the brokers based on the round robin partition distribution strategy.

```
curl --request POST 'http://localhost:9600/actuator/cluster/brokers?replicationFactor=4' \
-H 'Content-Type: application/json' \
-d '["0", "1", "2", "3"]'
```

##### Force remove brokers

:::caution
This is a dangerous operation and must be used with caution. When not used correctly, split-brain scenarios or unhealthy, unrecoverable clusters may result.
:::

Usually, changes can only be made to a cluster when all brokers are up. When some brokers are unreachable, you may want to remove them from the cluster. You can force remove a set of brokers by setting the request parameter `force` to `true`.

This operation is mainly useful for [dual-region setups](/self-managed//concepts/multi-region/dual-region.md), and additional information can be found in the [dual-region operational procedure](/self-managed/operational-guides/multi-region/dual-region-ops.md/). Any deviations from the described process can result in the cluster being unusable.

:::note
Do not send more than one force request at a time.
:::

The following request force removes all brokers that are _not_ provided in the request body:

```
curl --request POST 'http://localhost:9600/actuator/cluster/brokers?force=true' \
-H 'Content-Type: application/json' \
-d '["0", "1", "2"]'
```

This operation does not re-distribute the partitions that were in the removed brokers. As a result, the resulting cluster will have a reduced number of replicas for the affected partitions.

#### Response

The response is a JSON object. See detailed specs [here](https://github.com/camunda/camunda/blob/main/dist/src/main/resources/api/cluster/cluster-api.yaml):
Expand Down
67 changes: 67 additions & 0 deletions docs/self-managed/zeebe-deployment/operations/management-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ The following operations are currently available:

- [Rebalancing](/self-managed/zeebe-deployment/operations/rebalancing.md)
- [Pause and resume exporting](#exporting-api)
- [Enable and disable exporter](#exporters-api)

## Exporting API

Expand Down Expand Up @@ -61,3 +62,69 @@ When all partitions soft pause exporting, a successful response is received. If

</TabItem>
</Tabs>

## Exporters API

The Exporters API is used for [dual region deployment](/self-managed/operational-guides/multi-region/dual-region-ops.md/) operations, and allows for enabling and disabling configured exporters. By default, all configured exporters are enabled.

When **enabled**, records are exported to the exporter. The log is compacted only after the records are exported. When **disabled**, records are _not_ exported to the exporter, and the log will be compacted.

The OpenAPI spec for this API can be found [here](https://github.com/camunda/camunda/blob/main/dist/src/main/resources/api/cluster/exporter-api.yaml).

<Tabs groupId="exporters" defaultValue="enable" queryString values={[{label: 'Enable an exporter', value: 'enable' },{label: 'Disable an exporter', value: 'disable' }, {label: 'Monitor', value: 'monitor'}]} >

<TabItem value="enable">

When enabling an exporter, the exporter must be already configured in the cluster. To initialize an exporter's state, an existing exporter's ID can be provided in the optional `initializeFrom` field. Both exporters must be of the same type.

To enable a previously disabled exporter, send the following request to the gateway's management API:

```
POST actuator/exporters/{exporterId}/enable
{
initializeFrom: {anotherExporterId}
}
```

New records written after the exporter is enabled will be exported to this exporter.

</TabItem>

<TabItem value="disable">

To disable an exporter, send the following request to the gateway's management API:

```
POST actuator/exporters/{exporterId}/disable
```

After disabling the exporter, no records will be exported to this exporter. Other exporters continue exporting.

</TabItem>

<TabItem value="monitor">

Both enable and disable requests are processed asynchronously. To monitor the status of the exporters, send the following request to the gateway's management API:

```
GET actuator/exporters/
```

The response is a JSON object that lists all configured exporters with their status:

```json
[
{
"exporterId": "elasticsearch0",
"status": "ENABLED"
},
{
"exporterId": "elasticsearch1",
"status": "DISABLED"
}
]
```

</TabItem>

</Tabs>
Loading