Confluent Cloud の Cluster Linking ドキュメントをお探しですか? このページは Confluent Platform における Cluster Linking の説明です。Confluent Cloud のドキュメントをお探しの場合は、Confluent Cloud の「Cluster Linking」をご覧ください。

重要

この機能はプレビュー機能として利用できます。プレビュー機能とは、開発者から早い段階でフィードバックを受けるために提供している Confluent Platform のコンポーネントのことです。この機能は、評価用、本稼働環境以外でのテスト用、あるいは Confluent にフィードバックを提供するために使用できます。

ミラートピック¶

ミラートピックは、Cluster Linking を使用したデータ移動の基本要素です。読み取り専用で、クラスターリンクによって作成され、所有されます。

以下のセクションでは、ミラートピックというコンセプトの概要と、ミラートピックの作成、構成、実際の機能について、Confluent Platform と Confluent Cloud のどちらにも該当する内容を説明します。

概要¶

クラスターリンクは、ミラートピックを送信元トピックと接続します。送信元トピックに対して生成されるメッセージはすべて、クラスターリンク経由でミラートピックにミラーリングされます。

ミラートピックの構成の多くは、送信元トピックと同期されます。ACL やコンシューマーグループオフセットをクラスターリンクで有効にしている場合は、これらを送信元トピックと同期することもできます。

ミラートピックは、Cluster Linking の promote および failover コマンドを使用して通常のトピックに変換できます。

下図は、ミラートピックと送信元トピックとの関係、ACL やコンシューマーオフセットの同期など、ミラートピックの仕組みを示しています。

../../_images/cluster-link-mirror-topics-example.ja.png

ミラートピックの基礎¶

特徴¶

ミラートピックには以下のような固有の特徴があります。

ミラートピックは、クラスターリンクによって作成され、所有されます。
メッセージを送信元トピックから受け取ります。メッセージは、バイト単位の、オフセットが保持された、送信元トピックの非同期コピーです。
ミラートピックは読み取り専用です。他のトピックと同様に消費できますが、ミラートピックに対する生成はできません。プロデューサーがミラートピックに対してメッセージを生成しようとすると、失敗します。ミラートピックにメッセージを送り込む唯一の方法は、ミラートピックの送信元トピックに対してメッセージを生成することです。
ミラートピックの構成の多くが、送信元トピックからコピーされ、同期されます。このページの最後にリストが用意されています。

ミラートピックの作成¶

The general syntax used to create a mirror topic is:

kafka-mirrors --create --mirror-topic <topic-name> \
--link <link-name> \
--bootstrap-server <host:port>

For examples of how to create mirror topics, see Create the cluster link and mirror topic (step 2, "Initialize the mirror topic") in the basic tutorial and Creating a mirror topic in the Commands documentation

ミラートピックを作成する際には、（普通の）クラスターとクラスターリンクを指定する必要があります。

このクラスターリンクには、このクラスターが送信先クラスターとして指定されている必要があります。ミラートピックは必ずクラスターリンクの送信先クラスターに作成します。

作成する際に、ミラートピックには送信元トピックと同じ名前を指定する必要があります。具体的には次のとおりです。

クラスターリンクのソースクラスター上に同じ名前のトピックが存在していることが必要です。これがミラートピックの送信元トピックとなります。ミラートピックには、トピック名の保持という命名規則が強制されます。クラスターのグローバルメッシュの場合は、トピック名にクラスターの所在地を反映させることがベストプラクティスです。

たとえば、clicks データの生成先クラスターが米国と欧州にある場合、トピック名を clicks.us や clicks.eu とすることが考えられます。こうしておくと、トピックをいずれかのクラスターにミラーリングする場合に、ミラートピック名にデータの出どころが反映されます。clicks データのフルセットを取得する場合、コンシューマーは clicks.* というパターンから消費できます。
同じ名前のトピックが送信先クラスター上に既存ではないことが必要です。ミラートピックは、それを送信元トピックのバイト単位でのコピーにできるよう、必ずまったく新しいトピックとして作成されます。
送信元トピックを読み込むために、クラスターリンクのセキュリティ認証情報が ACL で認可されていることが必要です。

ミラートピックを作成するには、以下の条件がすべて満たされている必要があります。

同じ名前のトピックが送信先クラスター（ミラートピックの作成先となるクラスター）に存在しないことが必要です。ミラートピックは必ず新規トピックとして作成されます。つまり、既存の読み取りおよび書き込み可能トピックをミラートピックに変換することはできません。
指定されたクラスターリンクが、0 や 2 つ以上ではなく 1 つだけであることが必要です。
- リンクの link.mode が DESTINATION であることが必要です。
- リンクの dest.cluster.id がミラートピックのクラスターであることが必要です。
- リンクの bootstrap.servers がミラートピッククラスターのブートストラップサーバーであることが必要です。
リンクが "Active" ステートであることが必要です。
送信先クラスターのブローカーがソースクラスターのブローカーに到達して、適切な送信元トピックの存在を確認できることが必要です。
- ソースクラスター上のトピックがミラートピックと同じで名前あることが必要です。
- リンクに格納されるセキュリティ認証情報が、送信元トピックに対して ACL READ および DESCRIBE_CONFIGS で認可されていることが必要です。
- 送信先クラスターがクラスターリンクに対して構成されたプロパティを使用してもソースクラスターに到達できない場合、ミラートピックは作成できません。
ミラートピックを作成するユーザーは、送信先クラスターに以下の ACL を持っていることが必要です。
- クラスターの ALTER
- トピックの CREATE
- トピックの ALTER

セキュリティの構成の詳細については「Cluster Linking セキュリティ」を参照してください。

この図に示す例では、クラスターリンクとミラートピックが前出のプロパティを一部活かして構成されています。

../../_images/cluster-link-example.ja.png

送信元トピックのトピックデータ、ACL、コンシューマーオフセットを同期しているミラートピック¶

ミラートピックを削除します。¶

A cluster link is able to automatically create mirror topics on the destination cluster for any topics that exist on the source cluster. This is called “auto-creating” mirror topics. This saves time and effort, because you do not have to create mirror topics by hand. This functionality can be scoped down to a specific set of topics by matching on the topics’ names.

ミラートピックを削除します。¶

To enable this functionality, you must set two properties on the cluster link. You can set these properties when a cluster link is created, or update an existing cluster link with these properties. These properties are:

auto.create.mirror.topics.enable

Whether or not to auto-create mirror topics based on topics on the source cluster. When set to "true", mirror topics will be auto-created. Setting this option to "false" disables mirror topic creation and clears any existing filters.

Type: boolean
Default: false

auto.create.mirror.topics.filters

A JSON object with one property, topicFilters, that contains an array of filters to apply to indicate which topics should be mirrored. Filters are described below.
This list must have at least one filter.
Ordering of the filters in this array does not matter.

Type: array
Default: empty

Syntax

{ “topicFilters”: [ <each filter to apply> ] }

ミラートピックを削除します。¶

You can select exactly which source topics to automatically mirror through a list of filters. There is no limit to the number of filters you can add on a cluster link

Each filter is a JSON object with the following fields:

name

Text that will be matched against the name of the topic. Set name to the wildcard, *, to apply to all topics.

compression.type

Either LITERAL or PREFIXED

If name is set to “foo”, then setting patternType to LITERAL will only match a topic named "foo”.
Setting patternType to PREFIXED will match any topic names that begin with “foo”, for example, “foo”, “football”, and “foo.fighters”.

filterType

Either INCLUDE or EXCLUDE

If filterType is set to INCLUDE, any topic names on the source cluster that match this filter will be created as mirror topics.
If filterType is set to EXCLUDE , any matching topic names will not be created as mirror topics. In other words, prevents auto mirror topic creation for the specified topic names. EXCLUDE filters override any overlapping INCLUDE filters. For example, if you have an INCLUDE filter for the prefix “foo” but have an EXCLUDE filter for the prefix “foo.bar,” then a topic on the source cluster named “foo.fighters” would be mirrored automatically, but a topic named “foo.bar.fighters” would not be mirrored automatically.

Example Filters¶

ミラートピック¶

This filter will create mirror topics for all current and future source cluster topics:

{ "topicFilters": [ {"name": "*",  "patternType": "LITERAL",  "filterType": "INCLUDE"} ] }

Mirror all topics that begin with a given string¶

This filter will mirror all topics except those that begin with "foo":

{ "topicFilters": [ {"name": "foo",  "patternType": "PREFIXED",  "filterType": "INCLUDE"} ] }

Mirror all topics except those that begin with “secret”¶

This filter will mirror all topics except those that begin with "secret":

{ "topicFilters": [ {"name": "*",  "patternType": "LITERAL",  "filterType": "INCLUDE"},   \
{"name": "secret",  "patternType": "PREFIXED",  "filterType": "EXCLUDE"} ] }

Mirror named topics if they exist on the source cluster¶

This filter will mirror three topics, “liz”, “jack”, and “kenneth”, if they exist on the source cluster:

{ "topicFilters": [ {"name": "liz",  "patternType": "LITERAL",  "filterType": "INCLUDE"},   \
{"name": "jack",  "patternType": "LITERAL",  "filterType": "INCLUDE"},    \
{"name": "kenneth",  "patternType": "LITERAL",  "filterType": "INCLUDE"}  ] }

How a mirror topic is auto-created¶

For a given topic on a cluster link’s source cluster (the “source topic”), a new mirror topic will be auto-created by the cluster link if all of these conditions are true:

auto.create.mirror.topics.enable is set to true
auto.create.mirror.topics.filters has filters which INCLUDE the source topic name
送信元トピックを読み込むために、クラスターリンクのセキュリティ認証情報が ACL で認可されていることが必要です。
ミラートピックを作成するユーザーは、送信先クラスターに以下の ACL を持っていることが必要です。
If prefixing is enabled on the cluster link, then the source topic cannot be a mirror topic. You cannot “chain” mirror topics when both auto.create.mirror.topics.enable and prefixing are enabled.

If any of the above conditions are false, then a mirror topic will not be auto-created for the given source topic.

Deleting topics that were auto-created¶

You cannot delete a mirror topic that matches the auto-create mirror topics filters. If you deleted such a topic, and there was a topic of the same name on the source cluster, the mirror topic would be automatically re-created and sync all of its history. This would render the delete operation futile.

In order to delete a mirror topic while auto-create mirror topics is enabled, ensure that the mirror topic does not overlap with the auto-create filters. An easy way to remove a given topic from the filters is to add an EXCLUDE filter for that topic name.

Given a source topic called cool-topic, if you delete the source topic first, and then want to subsequently delete the associated mirror topic (cool-topic on the destination), wait until it becomes a FAILED mirror topic (which may take up to five minutes), after which point you can delete it. Both FAILED and STOPPED mirror topics can be deleted.

Alternatively, you can add cool-topic to the EXCLUDE filters, even though no such source topic exists, and this will effectively delete the topic.

See also, ミラートピックの削除.

ミラーリングラグ¶

ミラーリングは "非同期" の処理です。したがって、送信元トピックとミラートピックの間には "ミラーリングラグ" がよく生じます。送信元トピックでの最新のメッセージが、ミラートピックにまだミラーリングされていないことがあるため、ミラートピックが送信元トピックからわずかに遅れていることがよくあります。

同じことは、トピック構成、コンシューマーグループオフセット、ACL の同期についても言えます。これらの処理はすべて非同期であるため、変更はまず送信元トピックで発生し、その後間もなくミラートピックで発生します。

コンシューマーグループオフセットの同期¶

コンシューマーグループオフセットを同期するようクラスターリンクを構成できます。ミラーリングするコンシューマーグループを選択するには、コンシューマーグループ名と一致するパターンを JSON ファイルで渡す必要があります。これら 2 つのプロパティが設定されると、クラスターリンクは、リンクがミラーリングしているすべてのミラートピックについて、一致するコンシューマーグループすべてのコンシューマーグループオフセットを同期します。これにより、ミラートピックは送信元トピックと同期されたコンシューマーグループオフセットを持つことができます。

注釈

特定のコンシューマーグループ名についてコンシューマーグループオフセットの同期が有効の場合は、その名前のコンシューマーグループが送信元トピックからの消費を行っているかどうかによらず、送信先クラスター上にある同じコンシューマーグループ名のミラートピックからは消費しないでください。消費しているミラートピックのコンシューマーグループ名が、クラスターリンクで有効になっているコンシューマーグループ名フィルターと一致する場合、動作は保証されません。

フェイルオーバー発生時にコンシューマーオフセットが固定されることがある理由

ミラートピックでフェイルオーバーが呼び出されたときに、クラスターリンクでコンシューマーオフセットの同期が有効になっている場合は、そのトピックのコンシューマーオフセットが "固定される" 可能性があります。つまり、クラスターリンクが同期したトピックのコンシューマーオフセットが、ミラートピックの最後のオフセット（"ログ終了オフセット"）よりも大きくなることは許容されません。これらのコンシューマーオフセットのいずれかが最後のオフセット（ログ終了オフセット）よりも大きいか離れている場合は、それらのコンシューマーオフセットはログ終了オフセットにリセットされます。

例で考えてみます。1 つのパーティションを持つ送信元トピックがオフセット 100 までのメッセージを保持し、クラスターリンクを介してミラーリングされています。クラスターリンクでミラーリングラグが発生していたので、送信元トピックで災害が発生したときにミラーリングできていたのはオフセット 90 までのメッセージのみでした。この時点で、ミラートピックに対してフェイルオーバーを呼び出します。コンシューマーグループ A は送信元クラスターのオフセット 80 に位置していました。このため、それは送信先クラスターのオフセット 80 に残されます。そのオフセットはミラートピックにミラーリングされていたからです。しかし、コンシューマーグループ B はオフセット 95 に位置していたため、ミラートピックにミラーリングされていませんでした。コンシューマーグループ B がミラートピックのオフセット 95 で消費を開始した場合、トピックに生成されていたオフセット 90 ～ 94 のすべてのメッセージは失われます。この問題を回避するために、クラスターリンクはコンシューマーグループ B のオフセットを 90 に "固定" します。これはミラートピックで最も高いオフセットです。

詳細については、Confluent Cloud ドキュメントの「クラスターリンクの動作の構成」および Confluent Platform ドキュメントのクラスターリンクの「構成オプション」で、consumer.offset.group.filters を参照してください。

ミラートピックから通常のトピックへの変換¶

生成先にできる通常のトピックにミラートピックを変換する場合は、ミラートピックに対して failover または promote コマンドを呼び出します。

Confluent Platform では、kafka-mirrors --promote または kafka-mirrors --failover を呼び出します。

Confluent Cloud では、confluent kafka mirror promote <topic-name> または confluent kafka mirror failover <topic-name> を呼び出します。

どちらのコマンドも送信先クラスター（ミラートピックのクラスター）に対して実行し、その際にクラスターリンクの名前を渡す必要があります。

移行にはよく promote オプションを使用します。このオプションを指定すると、送信元トピックとミラートピックとの間にミラーリングラグ、構成同期ラグ、コンシューマーオフセットラグがないことが確認されます。確認されると、ミラートピックはフルトピックに変換され、このトピックが送信元トピックとまったく同じであることが保証されます。

注釈

この確認を実施するためには、送信先クラスターのブローカーがソースクラスターのブローカーに到達できる必要があります。そのため、ソースクラスターがオンラインであることが必要です。

ソースクラスターが災害（クラウドリージョンでの停電など）に見舞われ、運用を送信元トピックからミラートピックへ移行する場合には、failover オプションがよく使用されます。このコマンドは、ミラーリングラグやソースクラスターの到達可能性によらず、成功します。

promote および failover はどちらも元に戻せないコマンドです。このトピックをミラートピックに戻す方法はありません。このクラスター上でプロモートまたはフェイルオーバーさせたものと同じ名前のミラートピックが必要な場合は、変換済みのトピックを削除し、同じ名前の新しいミラートピックを作成する必要があります。

ミラートピックを変更して別のクラスターリンクを使用することや、リンクそのものに変更を加えることはできません。別のリンクにミラートピックを作り直してください。

重要

クラスターリンクを削除していなければ、昇格されたミラートピックまたはフェイルオーバーされたミラートピックに対して mirror describe （confluent kafka mirror describe <mirror-topic-name> --link <link>）を実行できます。クラスターリンクを削除した場合は、履歴が失われるため、昇格されたトピックまたはフェイルオーバーされたトピック上のデータが mirror describe によって検出されません。
You cannot delete a cluster link that still has mirror topics on it (the delete operation will fail).
If you are using Confluent for Kubernetes (CFK), and you delete your cluster link resource, any mirror topics still attached to that cluster link will be forcibly converted to regular topics by use of the failover API. To learn more, see Modify a mirror topic in Cluster Linking using Confluent for Kubernetes.

../../_images/cluster-link-migrate.ja.png

トピックの移行の例¶

../../_images/cluster-link-failover.ja.png

トピックのフェイルオーバーの例¶

ミラートピックのステートと状態¶

ミラートピックの詳細を表示すると、以下のいずれかのステートが返されます。

ACTIVE

ミラーは正常に動作しており、メッセージは送信元トピックから送信先トピックへミラーリングされています。

PAUSED

ユーザーがこのミラートピックのミラーリングを一時停止しました。
このステートに達するためには、ユーザーがこの特定のトピックを一時停止するか、このトピックのクラスターリンクを一時停止する必要があります。

PENDING_STOPPED

ユーザーが promote コマンドを使用してこのミラートピックを停止しました。このトピックはまもなく STOPPED ステートになります。
ミラートピックを直ちに PENDING_STOPPED ステートから STOPPED ステートに強制移行させるには、そのミラートピックに対して failover コマンドを呼び出します。そうすることで、送信元クラスターと送信先クラスター間で実行されている同期があればすべてキャンセルされ、promote コマンドによって与えられる保証もすべて対象外となります。

STOPPED

このトピックのミラーリングが完全に停止しました。送信元トピックからこれ以上メッセージを受信しません。トピックは書き込み可能となり、このトピックに対して直接生成されたメッセージを受信できます。
このステートに達するためには、ユーザーがこのミラートピックに対して promote または failover を呼び出す必要があります。
STOPPED 状態のトピックはミラートピックではなくなっていますが、クラスターリンクが存在する限り、confluent kafka mirror list コマンドや confluent kafka mirror describe <destination-topic-name> --link <link> コマンドの出力には引き続き表示されます。送信元トピックから各パーティションについてフェッチされた最後のオフセット（Last Source Fetch Offset）と停止された時刻（Status Time）がトピックから返されるので、有効に活用してください。

SOURCE_UNAVAILABLE

ミラートピックが送信元トピックに到達できず、送信元トピックからのメッセージをミラーリングしていません。この状態は、ソースクラスターが停電に見舞われている場合や、送信先クラスターとソースクラスターとの間のネットワークが不安定の場合に発生することがあります。
問題が解消され、送信先クラスターがソースクラスターに到達できるようになると、ミラーリングは再開されます。

LINK_FAILED

エラーによってミラートピックのクラスターリンクが壊れ、データがミラーリングされていません。ユーザーは手動でリンクを構成し直す必要があります。

FAILED

ミラートピックのエラー状態は永続的です。今後データはミラーリングされません。これはクラスターリンクの ACL が送信元クラスターから削除された場合や、送信元トピックが削除された場合に発生します。どちらのケースも、failed ステータスが発生するのは、あくまで cluster.link.retry.timeout.ms に達した後です（デフォルトでは 5 分間、リンクが再試行されます）。
このミラーは failover コマンドで停止でき、停止されたトピックは通常のトピックになります。
このトピックのミラーリングを元に戻す必要がある場合は、古いミラートピックを削除してから、同じ名前で新しいミラートピックを作成する必要があります。

ミラートピックの削除¶

ミラートピックは安全に削除できます。ミラートピックを削除すると、そのトピックへのデータのミラーリングが完全に停止します。同じクラスター上に同じ名前の普通のトピックを新たに作成しても、そこへデータはミラーリングされません。

To delete a mirror topic, use the same command you would use to delete a normal topic:

confluent kafka topic delete <topic-name>

To learn more, see Deleting topics that were auto-created.

注釈

接続されているミラートピックのあるクラスターリンクは削除できません。ミラートピックを先に削除、フェイルオーバー、またはプロモートしておく必要があります。その後、クラスターリンクを削除できます。

送信元トピックの削除¶

注意

ミラートピックによるミラーリング中の送信元トピックは削除しないでください。削除すると、ミラートピックで予測のつかない切り捨てが生じてデータが失われる可能性があります。送信元トピックを削除する前に、関連付けられているすべてのミラートピックへのミラーリングを必ず停止してください。

ミラートピックやクラスターリンクによるミラーリング中の送信元トピックを削除することは、可能ですが推奨されません。特に、送信元トピックが削除された後、数分以内に同じ名前でトピックが作成された場合、予測できない動作が生じる可能性があります。このシナリオでは、まだ送信元トピックからミラーリングを実行しているミラートピックで完全にデータが失われるおそれがあり、また、送信元クラスターまたは送信先クラスターでパフォーマンスの問題が発生する可能性もあります。

関連付けられているミラートピックへのミラーリングは、送信元トピックを削除する前にすべて停止する必要があります。ミラートピックに対するミラーリングは、次のいずれかの方法で停止できます。

ミラートピックを削除します。
promote または failover を呼び出して、ミラートピックを STOPPED ステートにします。
クラスターリンクの、ミラートピックを読み取るためのセキュリティアクセス許可を取り消します。これは、（1）送信元トピックの ALLOW ACL をクラスターリンクから削除する、（2）送信元トピックの DENY ACL を作成する、（3）クラスターリンクの API キーを削除する、という 3 とおりの方法で実行できます。

トピックの削除に関する Kafka の制限とトピック ID の価値について詳しくは、KIP-516 を参照してください。

How Schemas work with Mirror Topics¶

Cluster Linking preserves the schema ID stored in each message. Therefore, to consume from a mirror topic that is using schemas, the consumer clients must use a Schema Registry context with the same schema IDs as on the Schema Registry context used by the producers to the source topic. Consequently, consuming from a mirror topic that uses schemas should be done either by:

(Option 1) using the same Schema Registry as the producers used
(Option 2) using a Schema Registry context that was synced through Schema Linking from the Schema Registry that the producers used

ちなみに

Confluent Cloud Console only shows the default context for a topic schema. If Schema Linking was used to place the schemas for a mirror topic into a different context, then the Cloud Console will not show those schemas on that mirror topic.

multi-dc-deployments/cluster-linking/images/mirror-topics-and-schemas.png

ミラートピックのステートと状態¶

高度なミラートピックアーキテクチャ¶

チェーン¶

ミラートピックをそのまま送信元トピックにできます。ミラートピックを別のクラスターリンクでミラーリングして、クラスターリンクとミラートピックを "チェーン" のようにつなげられます。

例: クラスター 1 上のトピック A（送信元トピック） ---クラスターリンク---> クラスター 2 上のトピック A（ミラートピック兼送信元トピック） ---クラスターリンク---> クラスター 3 上のトピック A（ミラートピック）

ちなみに

トピックとクラスターリンクのこうしたチェーンは安全に作成でき、ミラートピックとクラスターリンクの循環依存関係ができる心配がありません。無限ループができる心配なしにミラートピックを作成できます。

チェーンの例¶

ファンアウト¶

送信元トピックは複数のミラートピックにミラーリングできます。この場合、ミラートピックが複数の異なるクラスター上に存在することが必要です。

例: クラスター 1 上のトピック A ---クラスターリンク---> クラスター 4 上のトピック A、およびクラスター 1 上のトピック A ---クラスターリンク---> クラスター 5 上のトピック A

ちなみに

クラスターリンクに対して failover または promote を使用する予定の場合は（ディザスターリカバリや移行のためなど）、ミラートピックのチェーンやファンアウトは自動では保持されません。たとえば、A --> B および A --> C とファンアウトする場合、A が使用できなくなって B に対してフェイルオーバーを呼び出した場合、B --> C のミラーリングを自動で行うことはできません。ユーザーがユースケースに合ったミラーリング関係を、まったく新しいトピックを使用して再構築する必要があります。

../../_images/cluster-link-fan-out.ja.png

ファンアウトの例¶

構成¶

以下のセクションでは、ソースからミラートピックへ同期される Cluster Linking 構成、オーバーライド、同期関連の概念について簡単に説明します。すべての構成リファレンスについては、「Cluster Linking の構成オプション」を参照してください。

Confluent Platform で同期されるミラートピック構成¶

送信元トピックからミラートピックへ必ず同期される構成を以下に示します。ミラートピックは、ミラートピックとしての条件を満たすために、必ず送信元トピックと同じ構成値を持ちます。

パーティションの数
max.message.bytes
cleanup.policy
retention.bytes
retention.ms
delete.retention.ms
min.compaction.lag.ms
max.compaction.lag.ms
message.timestamp.type
message.timestamp.difference.max.ms
compression.type

オーバーライド可能なミラートピック構成¶

以下の構成を Confluent Platform で構成可能です。つまり、これらのソースでの構成をミラートピックでオーバーライドできます。

segment.jitter.ms
segment.index.bytes
flush.messages
flush.ms
index.interval.bytes
min.cleanable.dirty.ratio
file.delete.delay.ms
preallocatemessage.format.version
confluent.segment.speculative.prefetch.enable

Confluent Platform で同期されないミラートピック構成¶

前出のリストに記載のない構成はすべて、Confluent Platform のミラートピックには同期されません。したがって、ミラートピックの構成が送信元トピックの構成と異なる場合があります。ユーザーがミラートピックの構成をオーバーライドしない場合は、クラスターのデフォルトが継承されます。

Confluent Platform のミラートピックと同期されない構成のうち、いくつか重要な例を以下に示します。

min.insync.replicas
confluent.placement.constraints
confluent.tier.enable
confluent.key.schema.validation
confluent.value.schema.validation
replication.factor

ちなみに

レプリケーション係数はミラートピックに同期されません。ミラートピックには、ブローカーに構成されている default.replication.factor が使用されます。明示的に設定されていない場合、デフォルトのレプリケーション係数である 1 になり、結果的に、ミラートピックでレプリケーション係数 1 が選択されます。このオプションについては、「Kafka ブローカーの構成」の「default.replication.factor」を参照してください。

ハイブリッドクラウド構成の同期¶

Confluent Platform と Confluent Cloud とでは、同期するミラートピック構成に関するポリシーに違いがあります。Confluent Platform と Confluent Cloud をクラスターリンクする場合は、送信先クラスターのポリシーが強制されます。

たとえば、Confluent Platform ソースクラスターから Confluent Cloud 送信先クラスターへクラスターリンクする場合、compression.type の値は同期されません。一方、Confluent Cloud ソースクラスターから Confluent Platform 送信先クラスターへクラスターリンクする場合、compression.type の値は同期されます。

ミラートピック¶

概要¶

特徴¶

ミラートピックの作成¶

ミラートピックを削除します。¶

ミラートピックを削除します。¶

ミラートピックを削除します。¶

Example Filters¶

ミラートピック¶

Mirror all topics that begin with a given string¶

Mirror all topics except those that begin with “secret”¶

Mirror named topics if they exist on the source cluster¶

How a mirror topic is auto-created¶

Deleting topics that were auto-created¶

ミラーリングラグ¶

コンシューマーグループオフセットの同期¶

ミラートピックから通常のトピックへの変換¶

ミラートピックのステートと状態¶

ミラートピックの削除¶

送信元トピックの削除¶

How Schemas work with Mirror Topics¶

高度なミラートピックアーキテクチャ¶

チェーン¶

ファンアウト¶

構成¶

Confluent Platform で同期されるミラートピック構成¶

オーバーライド可能なミラートピック構成¶

Confluent Platform で同期されないミラートピック構成¶

ハイブリッドクラウド構成の同期¶

おすすめの関連情報¶