Debezium Server

Overview

Debezium Server is a standalone change data capture (CDC) application. It reads a database’s change stream — the write-ahead log for PostgreSQL, the binlog for MySQL — turns every row-level insert, update and delete into an event, and delivers it to a messaging system, with no Kafka Connect cluster involved. This template runs one Debezium Server connector: one source database and one sink. It deploys neither the source nor the sink — both must already exist and be reachable from the workload. Every credential the connector uses comes from a dictionary secret you create before installing, so no password passes through Helm or lands in the release.

This template deploys into an existing GVC that you already have. It does not create or manage a GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-debezium`	Debezium Server (1 replica, health port `8080`). Stateful while offsets or schema history use `file` storage, stateless otherwise	—
Volume Set	`RELEASE_NAME-debezium-data`	Offset and schema-history files at `/debezium/data` on an `ext4` volume; a final snapshot is kept for 7 days when the volume is deleted	Created only when `source.offset.storage: file` (the default), or for MySQL and SQL Server when `source.schemaHistory.storage: file`
Secret	`RELEASE_NAME-debezium-config`	The generated `application.properties`; credentials appear in it only as environment-variable references	—
Secret	`RELEASE_NAME-debezium-credentials`	Non-sensitive connection details derived from your values — hostnames, usernames, URLs	—
Secret	`RELEASE_NAME-debezium-entrypoint`	PostgreSQL heartbeat startup script	`source.type: postgres` with `source.postgres.heartbeatIntervalMs` above `0`
Identity	`RELEASE_NAME-debezium-identity`	Workload identity; carries the cloud account link for the Kinesis or Pub/Sub sink	—
Policy	`RELEASE_NAME-debezium-policy`	Grants the identity `reveal` on your credentials secret and the template’s own secrets — nothing else	—

Prerequisites

Two things must be in place before you install: a source database configured for CDC, and the credentials secret.

Configure the source database for change data capture

A source left on default settings produces a connector that starts, connects and never emits a change, so do this first.PostgreSQL — enable logical replication in postgresql.conf and restart the server:

wal_level = logical
max_replication_slots = 4
max_wal_senders = 4

Create the publication named in source.postgres.publicationName and give the connector user replication rights:

CREATE PUBLICATION dbz_publication FOR ALL TABLES;
GRANT USAGE ON SCHEMA public TO debezium;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO debezium;
ALTER USER debezium REPLICATION;

Debezium creates the replication slot named in source.postgres.slotName on first connect.MySQL — enable row-based binary logging in my.cnf and restart the server:

server-id = 1
log_bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'debezium'@'%';

MongoDB, SQL Server and Oracle — follow the setup section of the matching upstream connector guide. This template has no extra steps for them.

Create the credentials secret

One dictionary secret holds every credential the connector needs. Secrets are org-level, so no GVC flag is involved, and secret names are org-wide — give each release its own. Include only the keys your configuration uses:

Key	Needed when
`sourcePassword`	Always — the source database password
`mongodbConnectionString`	`source.type: mongodb` with `source.mongodb.useConnectionString: true`
`offsetRedisPassword`	`source.offset.storage: redis` with `source.offset.redis.authEnabled: true`
`offsetJdbcPassword`	`source.offset.storage: jdbc`
`schemaHistoryRedisPassword`	MySQL or SQL Server, `source.schemaHistory.storage: redis` with `authEnabled: true`
`schemaHistoryJdbcPassword`	MySQL or SQL Server, `source.schemaHistory.storage: jdbc`
`kafkaSaslPassword`	`sink.type: kafka` with `sink.kafka.saslUsername` set
`sinkRedisPassword`	`sink.type: redis` with `sink.redis.authEnabled: true`
`natsPassword`	`sink.type: nats-jetstream` with `sink.nats.username` set
`httpPassword`	`sink.type: http` with `sink.http.authType: basic`
`httpBearerToken`	`sink.type: http` with `sink.http.authType: bearer`
`pulsarAuthToken`	`sink.type: pulsar` with `sink.pulsar.authEnabled: true`
`eventhubsConnectionString`	`sink.type: eventhubs`
`schemaRegistryPassword`	`format.schemaRegistry.url` and `format.schemaRegistry.username` both set

For the default PostgreSQL-to-Kafka shape that is a single key:

cpln secret create-dictionary --name SECRET_NAME \
  --entry sourcePassword='YOUR-DATABASE-PASSWORD'

Add one --entry per extra key, for example --entry kafkaSaslPassword='YOUR-SASL-PASSWORD' for a SASL-authenticated Kafka. Read the secret back with cpln secret reveal SECRET_NAME -o yaml.Set credentialsSecretName to this name.

Create the secret before installing, or the deployment wedges silently. The template refuses to render when credentialsSecretName is blank, but a name that points at a secret which does not exist — or that lacks a key your configuration references — installs successfully and then never starts. The container never runs, so cpln logs returns zero lines. The one place the reason appears is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-debezium --gvc GVC_NAME -o yaml

Use get-deployments — plain cpln workload get has no versions key. Creating the missing secret repairs the deployment on its own within several minutes, or run cpln workload force-redeployment RELEASE_NAME-debezium --gvc GVC_NAME to skip the wait.

The Kinesis and Pub/Sub sinks also need a Control Plane cloud account — see Sink.

Installation

Install from the marketplace registry with your secret, your source connection and your Kafka brokers. Replace DATABASE_HOST, DATABASE_NAME, DATABASE_USER and KAFKA_BOOTSTRAP_SERVERS with your own values:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/debezium-server \
  --version 1.2.0 --gvc GVC_NAME \
  --set credentialsSecretName=SECRET_NAME \
  --set source.database.hostname=DATABASE_HOST \
  --set source.database.name=DATABASE_NAME \
  --set source.database.user=DATABASE_USER \
  --set sink.kafka.bootstrapServers=KAFKA_BOOTSTRAP_SERVERS

For any other source or sink, put the settings from Configuration in a values file and pass it with -f. Or follow the instructions for your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Each block below is the shipped default for that part of values.yaml.

Image and Resources

image: quay.io/debezium/server:3.0

# REQUIRED PREREQUISITE SECRET — CREATE IT BEFORE YOU INSTALL.
# A `dictionary` secret holding every credential this connector needs. Which keys
# it must contain depends on your source and sink; the README lists them per
# combination. Credentials are not values because they are issued by systems you
# own — a value would put them in the Helm release.
credentialsSecretName: my-debezium-credentials

resources:
  cpu: 500m
  memory: 512Mi

The workload always runs exactly one replica — Debezium Server is a single connector process, and there is no replica knob.

Source Connection

source:
  # Database type: postgres, mysql, mongodb, sqlserver, oracle
  type: postgres

  # Database connection settings
  database:
    hostname: "db.example.com"  # Required: database hostname or IP
    port: 5432             # Default port varies by type (postgres:5432, mysql:3306, mongodb:27017, sqlserver:1433, oracle:1521)
    name: "mydb"           # Required: database name (or SID for Oracle)
    user: "dbuser"         # Required: database username
    # password comes from the `sourcePassword` key of your credentials secret

  # Server name used as prefix for topic names
  serverName: "dbserver1"

  # Tables to capture (comma-separated, e.g., "public.users,public.orders")
  # Leave empty to capture all tables
  tableIncludeList: ""

  # Tables to exclude (comma-separated)
  tableExcludeList: ""

source.database.port follows the source type when left empty; the shipped 5432 suits PostgreSQL, so change it for any other source. serverName becomes the prefix of every topic, stream or subject the connector writes to.

Connector-Specific Settings

Only the block that matches source.type is used.

source:
  # PostgreSQL-specific settings
  postgres:
    slotName: "debezium"                  # Replication slot name
    publicationName: "dbz_publication"    # Publication name
    pluginName: "pgoutput"                # Logical decoding plugin: pgoutput (default), decoderbufs
    slotDropOnStop: false                 # Keep replication slot on stop (required for HA/failover)
    heartbeatIntervalMs: 0               # Heartbeat interval in ms (0=disabled; set 5000 for HA)
    heartbeatActionQuery: ""              # SQL executed on heartbeat (e.g., "UPDATE debezium_heartbeat SET ts = now() WHERE id = 1")

  # MySQL-specific settings
  mysql:
    serverId: 85744                       # Unique server ID for MySQL replication
    includeSchemaChanges: true            # Include DDL events

  # MongoDB-specific settings
  mongodb:
    # Set true to connect with a full connection string instead of hostname/port.
    # The string itself is the `mongodbConnectionString` key of your credentials
    # secret, because it embeds credentials.
    useConnectionString: false
    replicaSet: ""                        # Replica set name

  # SQL Server-specific settings
  sqlserver:
    databaseNames: ""                     # Comma-separated database names to capture
    snapshotMode: "initial"               # Snapshot mode: initial, schema_only, initial_only

  # Oracle-specific settings
  oracle:
    pdbName: ""                           # Pluggable database name
    logMiningStrategy: "online_catalog"   # Log mining strategy: online_catalog, redo_log_catalog

For PostgreSQL with heartbeatIntervalMs above 0, a startup step runs before the server: it creates a debezium_heartbeat table (columns id and ts, seeded with row 1) and creates the replication slot if it does not exist yet. That table is what the commented heartbeatActionQuery example updates. If the step fails it logs a warning and Debezium Server starts anyway, so read the logs after enabling it.

Offset Storage

Offsets record how far through the change stream the connector has read, so a restart resumes instead of re-snapshotting the source.

source:
  # Offset storage configuration
  offset:
    # Storage type: file, redis, jdbc
    storage: file

    # Flush settings
    flushIntervalMs: 10000               # How often offsets flush to storage (ms)
    flushTimeoutMs: 60000                # Timeout for offset flush operations (ms)

    # File storage settings (requires volumeset)
    file:
      filename: "/debezium/data/offsets.dat"

    # Redis storage settings
    redis:
      address: ""                         # Redis address (e.g., redis.mygvc.cpln.local:6379)
      key: "debezium:offsets"             # Redis key for offsets
      authEnabled: false                  # true = read `offsetRedisPassword` from your credentials secret
      ssl: false                          # Enable SSL/TLS

    # JDBC storage settings
    jdbc:
      url: ""                             # JDBC URL (e.g., jdbc:postgresql://host:5432/dbname)
      user: ""                            # JDBC username
      # password comes from the `offsetJdbcPassword` key of your credentials secret
      tableName: "debezium_offsets"       # Table name for storing offsets

`storage`	Where offsets live	Workload
`file`	The `RELEASE_NAME-debezium-data` volume	Stateful, volume created
`redis`	A key in your existing Redis	Stateless, no volume
`jdbc`	A table in your existing relational database	Stateless, no volume

Schema History

Used only by MySQL and SQL Server, which must track DDL changes. The backends are the same three as offset storage.

source:
  # Schema history storage (required for MySQL and SQL Server)
  schemaHistory:
    # Storage type: file, redis, jdbc (only used for mysql/sqlserver)
    storage: file

    # File storage settings
    file:
      filename: "/debezium/data/schema-history.dat"

    # Redis storage settings
    redis:
      address: ""
      key: "debezium:schema-history"
      authEnabled: false                  # true = read `schemaHistoryRedisPassword` from your credentials secret
      ssl: false

    # JDBC storage settings
    jdbc:
      url: ""
      user: ""
      # password comes from the `schemaHistoryJdbcPassword` key of your credentials secret
      tableName: "debezium_schema_history"

Error Retries

source:
  # Error retry configuration
  errors:
    retryDelayInitialMs: 300             # Initial retry delay (ms)
    retryDelayMaxMs: 10000               # Max retry delay (ms)
    maxRetries: -1                       # Max retries (-1 = infinite)

Sink

Set sink.type and fill in only that sink’s block. Every sink writes one destination per captured table, named from its prefix and the table.

sink:
  # Sink type: kafka, redis, nats-jetstream, http, kinesis, pubsub, pulsar, eventhubs
  type: kafka

  # Kafka sink settings
  kafka:
    bootstrapServers: "kafka.my-gvc.cpln.local:9092"  # Required: Kafka bootstrap servers
    topic: ""                             # Topic prefix (events sent to {topic}.{table})
    securityProtocol: "PLAINTEXT"         # Security protocol: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL
    saslMechanism: ""                     # SASL mechanism: PLAIN, SCRAM-SHA-256, SCRAM-SHA-512
    saslUsername: ""                      # SASL username
    # saslPassword comes from the `kafkaSaslPassword` key of your credentials secret

  # Redis sink settings (Redis Streams)
  redis:
    address: ""                           # Required: Redis address (e.g., redis.mygvc.cpln.local:6379)
    authEnabled: false                    # true = read `sinkRedisPassword` from your credentials secret
    ssl: false                            # Enable SSL/TLS
    streamName: ""                        # Stream name prefix (events sent to {streamName}.{table})

  # NATS JetStream sink settings
  nats:
    url: ""                               # Required: NATS URL (e.g., nats://nats.mygvc.cpln.local:4222)
    subject: ""                           # Subject prefix (events sent to {subject}.{table})
    username: ""                          # NATS username
    # password comes from the `natsPassword` key of your credentials secret

  # HTTP sink settings (webhooks)
  http:
    url: ""                               # Required: HTTP endpoint URL
    headers: {}                           # Additional headers (key-value pairs)
    authType: ""                          # Auth type: none, basic, bearer
    username: ""                          # Basic auth username
    # password / bearerToken come from the `httpPassword` / `httpBearerToken`
    # keys of your credentials secret, per authType

  # AWS Kinesis sink settings (uses Universal Cloud Identity)
  kinesis:
    region: ""                            # Required: AWS region
    streamName: ""                        # Required: Kinesis stream name
    credentialsProvider: "default"        # Use "default" for Universal Cloud Identity
    # Cloud account for Universal Cloud Identity
    cloudAccount:
      enabled: false
      name: ""                            # AWS cloud account name in Control Plane

  # GCP Pub/Sub sink settings (uses Universal Cloud Identity)
  pubsub:
    projectId: ""                         # Required: GCP project ID
    topic: ""                             # Topic prefix (events sent to {topic}.{table})
    # Cloud account for Universal Cloud Identity
    cloudAccount:
      enabled: false
      name: ""                            # GCP cloud account name in Control Plane

  # Apache Pulsar sink settings
  pulsar:
    serviceUrl: ""                        # Required: Pulsar service URL
    topic: ""                             # Topic prefix
    authPluginClassName: ""               # Auth plugin class (e.g., org.apache.pulsar.client.impl.auth.AuthenticationToken)
    authEnabled: false                    # true = read `pulsarAuthToken` from your credentials secret

  # Azure Event Hubs sink settings
  eventhubs:
    # connectionString comes from the `eventhubsConnectionString` key of your credentials secret
    hubName: ""                           # Required: Event Hub name

`sink.type`	Required values	Credentials secret keys
`kafka`	`bootstrapServers`	`kafkaSaslPassword` when `saslUsername` is set
`redis`	`address`	`sinkRedisPassword` when `authEnabled: true`
`nats-jetstream`	`url`	`natsPassword` when `username` is set
`http`	`url`	`httpPassword` or `httpBearerToken`, per `authType`
`kinesis`	`region`, `streamName`	None — uses the cloud account
`pubsub`	`projectId`	None — uses the cloud account
`pulsar`	`serviceUrl`	`pulsarAuthToken` when `authEnabled: true`
`eventhubs`	`hubName`	`eventhubsConnectionString` (always)

Kafka with SASL needs both saslMechanism and saslUsername set, plus kafkaSaslPassword in the secret. The template always generates a PlainLoginModule JAAS configuration, which matches saslMechanism: PLAIN. Pulsar token auth needs both authPluginClassName (for example org.apache.pulsar.client.impl.auth.AuthenticationToken) and authEnabled: true, plus pulsarAuthToken in the secret — set all three together. Kinesis and Pub/Sub authenticate through a Control Plane cloud account instead of keys. Set cloudAccount.enabled: true and cloudAccount.name to your cloud account. The template links that cloud account to the workload identity — with the pubsub scope for GCP — but attaches no AWS IAM policy and no GCP role, so grant the identity access to your stream or topic yourself. Inspect the identity with:

cpln identity get RELEASE_NAME-debezium-identity --gvc GVC_NAME -o yaml

The cloud sinks have not been verified end to end on this version.

Serialization Format

format:
  key: json                               # Key format: json, avro, protobuf
  value: json                             # Value format: json, avro, protobuf

  # Schema registry settings (for avro/protobuf)
  schemaRegistry:
    url: ""                               # Schema registry URL
    username: ""                          # Schema registry username
    # password comes from the `schemaRegistryPassword` key of your credentials secret

The schema registry is used only when key or value is avro or protobuf and url is set. With a username, put the password in the secret as schemaRegistryPassword.

Storage

Used only when a volume is created (see Offset Storage).

volumeset:
  capacity: 10                            # Initial capacity in GiB (minimum 10)
  performanceClass: general-purpose-ssd   # Performance class: general-purpose-ssd, high-throughput-ssd

Firewall

firewall:
  internal:
    inboundAllowType: same-gvc            # Options: none, same-gvc, same-org, workload-list
    workloads: []                         # Workload list for inbound access (when type is workload-list)
  external:
    outboundAllowCIDR:
      - 0.0.0.0/0                         # Allow all outbound by default (required for database connectivity)

The workload has no public endpoint. firewall.internal controls who in Control Plane can reach port 8080; firewall.external.outboundAllowCIDR must allow the source database and the sink. A firewall change can take several minutes to take effect.

Connecting

Debezium Server exposes only health endpoints; change events go to your sink.

What	Address	Notes
Health, all checks	`http://RELEASE_NAME-debezium.GVC_NAME.cpln.local:8080/q/health`	Reachable per `firewall.internal.inboundAllowType`
Readiness	`/q/health/ready` on port `8080`	The workload readiness probe
Liveness	`/q/health/live` on port `8080`	The workload liveness probe
Change events	Your sink	One destination per table, prefixed by the sink prefix and `source.serverName`
Credentials	`cpln secret reveal SECRET_NAME -o yaml`	The keys you created. Never stored in the Helm release

To check health from your own machine, tunnel to the workload and query it:

cpln port-forward RELEASE_NAME-debezium 8080:8080 --gvc GVC_NAME

curl http://127.0.0.1:8080/q/health

To confirm events flow, read the connector log for snapshot and streaming progress or errors, then change a row in a captured table and look for the event in your sink:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-debezium"}' --limit 50 --since 10m

Operations

Backing Up

With file storage the offsets and schema history live on the RELEASE_NAME-debezium-data volume, which Control Plane snapshots; a final snapshot is kept for 7 days when the volume is deleted. Take one on demand before a risky change:

cpln volumeset snapshot create RELEASE_NAME-debezium-data --gvc GVC_NAME --snapshot-name NAME

cpln volumeset snapshot get RELEASE_NAME-debezium-data --gvc GVC_NAME

With redis or jdbc storage, back up that store instead. The captured data itself lives in the source database and the sink.

Restoring a Backup

Restoring offsets from a volume snapshot has not been verified on this template. If offsets are lost, the connector re-snapshots the source on its next start, then resumes streaming — correct, but expensive on large tables.

Upgrading from 1.1.x

Version 1.2.0 moves every credential out of values. The source password, the offset and schema-history store passwords, every sink credential and the schema-registry password are now keys in the credentials secret, and five switches replace settings that used to be inferred from a credential being set: source.mongodb.useConnectionString, and authEnabled on source.offset.redis, source.schemaHistory.redis, sink.redis and sink.pulsar.

Create the credentials secret with a key for every credential your release uses (see Prerequisites).
Remove every removed credential from your values file, set credentialsSecretName, and set the new switches that apply.
Upgrade with the full values file:

cpln helm upgrade RELEASE_NAME oci://ghcr.io/controlplane-com/templates/debezium-server \
  --version 1.2.0 --gvc GVC_NAME \
  -f values.yaml \
  --set credentialsSecretName=SECRET_NAME

The values file must use the chart’s nesting, exactly as the blocks in Configuration show. A flat dotted key is accepted without error and silently changes nothing. An upgrade that still carries a removed credential is refused before anything is changed, with an error such as:

debezium-server: source.database.password was REMOVED — every credential is now a key in the `dictionary` secret named by credentialsSecretName. Delete it from your values; see Prerequisites in the README for the key names.

Scaling and Availability

The connector is a single replica and cannot be scaled out. For PostgreSQL behind a failover-capable cluster, keep source.postgres.slotDropOnStop: false and set source.postgres.heartbeatIntervalMs (for example 5000); the heartbeat also keeps the slot advancing on a low-traffic source.

Rotating Credentials

Apply the whole secret with the new value — cpln secret update cannot change values — then force a redeployment, because a running replica keeps the old value:

kind: secret
name: SECRET_NAME
type: dictionary
data:
  sourcePassword: NEW-PASSWORD

cpln apply -f rotate.yaml
cpln secret reveal SECRET_NAME -o yaml
cpln workload force-redeployment RELEASE_NAME-debezium --gvc GVC_NAME

Include every key the secret already holds in rotate.yaml; the apply replaces the whole secret.

Removing a Connector

helm uninstall does not touch the source database. On PostgreSQL the replication slot stays behind, and PostgreSQL retains WAL for an inactive slot indefinitely until the disk fills. Drop it once the connector is gone:

SELECT pg_drop_replication_slot('debezium');

Use the name from source.postgres.slotName.

Troubleshooting

Workload never starts and logs are empty

Cause: the credentials secret, or a key your configuration references, does not exist. Fix: read status.versions[].message with cpln workload get-deployments RELEASE_NAME-debezium --gvc GVC_NAME -o yaml, create the secret or add the key, and wait or force a redeployment.

Connector is healthy but no events arrive

Cause: the source is not configured for CDC — PostgreSQL without wal_level = logical or the publication, MySQL without row-based binlog — or the table is outside tableIncludeList. Fix: complete the source steps in Prerequisites, then check the connector log for snapshot and streaming messages.

Source disk fills with WAL

Cause: a replication slot is not advancing — the connector was removed and its slot left behind, or a quiet source never moves the slot forward. Fix: drop abandoned slots (see Removing a Connector) and set source.postgres.heartbeatIntervalMs on a low-traffic source.

Install or upgrade fails with credentialsSecretName is required

Cause: credentialsSecretName is blank. Fix: set it to the name of your credentials secret.

Upgrade fails with was REMOVED

Cause: your values still carry a credential that 1.2.0 moved into the secret. Fix: follow Upgrading from 1.1.x.

Connector re-snapshots the whole source

Cause: the offsets were lost — the volume was deleted with file storage, or the Redis key or JDBC table was cleared. Fix: keep the volume or store between reinstalls; see Restoring a Backup.

Important Notes

Configure the source for CDC before installing; otherwise the connector runs healthy and emits nothing.
Deleting the volume (or clearing the Redis key or JDBC table) loses the offsets and forces a full re-snapshot.
Drop the PostgreSQL replication slot when you remove a connector, or retained WAL will fill the source disk.
One release runs one connector; capture several sources with several releases, each with its own source.postgres.slotName and credentials secret.
After rotating a credential in the secret, force a redeployment — a running replica keeps the old value.

External References

Debezium Server documentation
Debezium connectors
Debezium PostgreSQL connector
Debezium MySQL connector
CDC Pipeline template — PostgreSQL Highly Available, Kafka and Debezium Server in one install

Template Catalog

Templates

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Image and Resources

Source Connection

Connector-Specific Settings

Offset Storage

Schema History

Error Retries

Sink

Serialization Format

Storage

Firewall

Connecting

Operations

Backing Up

Restoring a Backup

Upgrading from 1.1.x

Scaling and Availability

Rotating Credentials

Removing a Connector

Troubleshooting

Important Notes

External References

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​Image and Resources

​Source Connection

​Connector-Specific Settings

​Offset Storage

​Schema History

​Error Retries

​Sink

​Serialization Format

​Storage

​Firewall

​Connecting

​Operations

​Backing Up

​Restoring a Backup

​Upgrading from 1.1.x

​Scaling and Availability

​Rotating Credentials

​Removing a Connector

​Troubleshooting

​Important Notes

​External References

Overview

What Gets Created

Prerequisites

Installation

Configuration

Image and Resources

Source Connection

Connector-Specific Settings

Offset Storage

Schema History

Error Retries

Sink

Serialization Format

Storage

Firewall

Connecting

Operations

Backing Up

Restoring a Backup

Upgrading from 1.1.x

Scaling and Availability

Rotating Credentials

Removing a Connector

Troubleshooting

Important Notes

External References