ミラートピック¶

Looking for Confluent Cloud Cluster Linking docs? You are currently viewing Confluent Platform documentation. If you are looking for Confluent Cloud docs, check out Cluster Linking on Confluent Cloud.

重要

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

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

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

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

概要¶

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

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

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

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

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

ミラートピックの基礎¶

特徴¶

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

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

ミラートピックの作成¶

Command syntax¶

ミラートピックの作成に使用される一般的な構文は次のとおりです。

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

You can create a specific mirror topic using the Confluent Cloud Console, the Confluent Cloud REST API, the Confluent CLI, the Confluent Platform AdminClient API, or Confluent for Kubernetes. Alternatively, you can configure your cluster link to automatically create mirror topics that match certain prefixes.

To learn more, see confluent kafka mirror create in the Confluent CLI command reference.

Creating a mirror topic with the AdminClient API¶

You can use the AdminClient API to create mirror topics on Confluent Platform. To learn more, see ConfluentAdmin API reference.

フィルターの例¶

ミラートピックの作成方法の例としては、基本チュートリアルの「クラスターリンクとミラートピックの作成（ステップ 2「ミラートピックを初期化します」）およびコマンド資料の「ミラートピックの作成」を参照してください。

For examples of how to create mirror topics on Confluent Cloud, see the following sections:

Create source and mirror topics in the Quick Start for Cluster Linking on Confluent Cloud
Mirror a topic in the Confluent Cloud Cluster Linking tutorial
examples in the Confluent CLI command reference

Requirements¶

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

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

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

たとえば、clicks データの生成先クラスターが米国と欧州にある場合、トピック名を clicks.us や clicks.eu とすることが考えられます。こうしておくと、トピックをいずれかのクラスターにミラーリングする場合に、ミラートピック名にデータの出どころが反映されます。clicks データのフルセットを取得する場合、コンシューマーは clicks.* というパターンから消費できます。

If prefixing is enabled on the cluster link, you must specify both the source topic and mirror topic name when you create the mirror topic. (See Additional requirements when prefixing is enabled.)

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

同じ名前のトピックが送信先クラスター（ミラートピックの作成先となるクラスター）に存在しないことが必要です。ミラートピックは必ず新規トピックとして作成されます。つまり、既存の読み取りおよび書き込み可能トピックをミラートピックに変換することはできません。
指定されたクラスターリンクが、0 や 2 つ以上ではなく 1 つだけであることが必要です。
- リンクの link.mode が DESTINATION であることが必要です。
- リンクの dest.cluster.id がミラートピックのクラスターであることが必要です。
- リンクの bootstrap.servers がミラートピッククラスターのブートストラップサーバーであることが必要です。
リンクが "Active" ステートであることが必要です。
送信先クラスターのブローカーがソースクラスターのブローカーに到達して、適切な送信元トピックの存在を確認できることが必要です。
- A topic on the source cluster with the same name as the mirror topic, excluding the cluster link's prefix (if a prefix is configured on the cluster link). (See also, Additional requirements when prefixing is enabled and Prefixing Mirror Topics and Consumer Group Names.)
- リンクに格納されるセキュリティ認証情報が、送信元トピックに対して ACL READ および DESCRIBE_CONFIGS で認可されていることが必要です。
- 送信先クラスターがクラスターリンクに対して構成されたプロパティを使用してもソースクラスターに到達できない場合、ミラートピックは作成できません。
ミラートピックを作成するユーザーは、送信先クラスターに以下の ACL を持っていることが必要です。
- クラスターの ALTER
- トピックの CREATE
- トピックの ALTER

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

Additional requirements when prefixing is enabled¶

When a cluster link has a prefix set, the specified prefix will be added to the beginning of mirror topic names. For example; if you set the prefix to west, the source topic orders will be mirrored as west.orders.

If the cluster link is configured for prefixing mirror topic names, then to create a mirror topic you must pass both the mirror topic name and the source topic name (instead of just the source topic name).

To learn more about prefixing, see Prefixing Mirror Topics and Consumer Group Names.

Cluster Linking ¶

To establish bidirectional linking between two clusters, you must use two cluster links. You cannot establish bi-directional linking with a single cluster link. For an example of bidirectional linking, see the Hybrid tutorial (on either Confluent Cloud or Confluent Platform), which sets up bidirectional linking between on-premises and cloud clusters.

Bidirectional linking is supported for different topics. For a specific topic, only unidirectional linking is supported.

Cherry pick which topics to mirror¶

To cherry pick topics to be mirrored, you can use any of the following methods:

ミラートピック自動作成のフィルター
manually mirror individual topics with confluent mirror command as shown in the tutorials (quick start for Confluent Cloud, tutorial for Confluent Platform)
use the Confluent Cloud Cluster Linking (v3) REST API (see "Create a mirror topic").

Support for compacted topics¶

Cluster Linking supports compacted topics. A compacted topic is mirrored as such from source to destination. To learn more, see the FAQs for Confluent Cloud and Confluent Platform.

Diagram of a cluster link¶

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

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

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

ミラートピックの自動作成¶

クラスターリンクは、送信元クラスターに存在しているすべてのトピックについて、送信先クラスター上にミラートピックを自動的に作成できます。これを、ミラートピックの「自動作成」と呼びます。これにより時間と労力が省かれます。ユーザーがミラートピックを手動で作成する必要がないからです。この機能では、トピック名を照合することによって、特定のトピックセットに範囲を絞り込むことができます。

ミラートピックの自動作成の有効化¶

この機能を有効にするには、クラスターリンクに 2 つのプロパティを設定する必要があります。これらのプロパティは、クラスターリンクを作成するとき、またはこれらのプロパティを使用して既存のクラスターリンクを更新するときに設定できます。設定するプロパティは次のものです。

auto.create.mirror.topics.enable

送信元クラスターのトピックを基にミラートピックを自動作成するかどうかを指定します。「true」に設定した場合、ミラートピックは自動作成されます。このオプションを「false」に設定すると、ミラートピック作成が無効になり、既存のフィルターがある場合はクリアされます。

型: boolean
デフォルト: false

auto.create.mirror.topics.filters

1 つのプロパティ topicFilters を持つ JSON オブジェクト。適用されるフィルターの配列が含まれており、どのトピックをミラーリングするかを示します。フィルターについては以下で説明します。
このリストには少なくとも 1 つのフィルターが含まれる必要があります。
この配列のフィルターの順序は関係ありません。

型: array
デフォルト: 空

構文

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

ミラートピック自動作成のフィルター¶

In Confluent Cloud, auto-creating mirror topics automatically filters out Confluent internal topics and the topic that holds schemas (default name _schemas).

In Confluent Platform, internal topics may be filtered out in upcoming releases, but in current releases, they are not. All other filtering options described below are available in both Confluent Cloud and current releases of Confluent Platform.

Other topics can be excluded using filters. For example, if a different topic name is used for Schema Registry storage, instead of _schemas, it can be excluded by using filters. Further detail on how to filter topics for auto-create mirror topics is provided below.

フィルターのリストを使って、ミラートピックを自動作成する送信元トピックを正確に選択できます。クラスターリンクで追加できるフィルターの数に制限はありません。

各フィルターは次のフィールドを持つ JSON オブジェクトです。

name

トピック名の照合に使用されるテキスト。name をワイルドカード * に設定すると、すべてのトピックに適用されます。

patternType

LITERAL または PREFIXED

name を “foo” に設定し、patternType を LITERAL に設定すると、"foo” という名前のトピックだけが一致します。
patternType を PREFIXED に設定すると、“foo” で始まるすべてのトピックが一致します。たとえば、“foo”、“football”、“foo.fighters” などです。

filterType

INCLUDE または EXCLUDE のいずれか

filterType を INCLUDE に設定すると、送信元クラスターのこのフィルターに一致するすべてのトピック名がミラートピックとして作成されます。
filterType を EXCLUDE に設定すると、トピック名が一致するすべてのトピックがミラートピックとして作成されません。言い換えれば、特定のトピック名のミラートピックを作成しないようにできます。EXCLUDE フィルターは、重複する INCLUDE フィルターがあった場合、これをオーバーライドします。たとえば、プレフィックス “foo” に対して INCLUDE フィルターを指定したが、プレフィックス “foo.bar” に対して EXCLUDE フィルターを設定した場合、送信元クラスター上の名前が “foo.fighters” というトピックは自動的にミラーリングされますが、名前が “foo.bar.fighters” というトピックは自動的にミラーリングされません。

フィルターのリストを使って、ミラートピックを自動作成する送信元トピックを正確に選択できます。クラスターリンクで追加できるフィルターの数に制限はありません。

フィルターの例¶

すべてのトピックをミラーリング¶

このフィルターは現在および未来のすべての送信元クラスタートピックのミラートピックを作成します。

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

指定した文字列で始まるすべてのトピックをミラーリング¶

このフィルターは、"foo" で始まるトピックを除いたすべてのトピックをミラーリングします。

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

"secret" で始まるトピックを除くすべてのトピックをミラーリング¶

このフィルターは、"secret" で始まるトピックを除いたすべてのトピックをミラーリングします。

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

送信元クラスター上に存在する名前付きトピックをミラーリング¶

このフィルターは、“liz”、“jack”、および “kenneth” の 3 つのトピックが送信元クラスターに存在していた場合、それらをミラーリングします。

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

ミラートピックが自動作成される方法¶

クラスターリンクの送信元クラスター上の特定のトピック（“送信元トピック”）の場合、以下の条件がすべてあてはまれば、新規ミラートピックがクラスターリンクによって自動生成されます。

auto.create.mirror.topics.enable が true に設定されている
auto.create.mirror.topics.filters に、送信元トピック名を含める INCLUDE フィルターが設定されている
クラスターリンクのセキュリティ認証情報に対して、送信元トピックの読み取りが（送信元クラスター ACL によって）許可されている。
同じ名前の既存のトピックが送信先クラスター上にない。
プレフィックス使用がクラスターリンクで有効な場合、送信元クラスターはミラートピックになることができません。auto.create.mirror.topics.enable とプレフィックス使用がどちらも有効な場合、ミラートピックを「階層化」することはできません。

上記条件のいずれかが false の場合、指定された送信元トピックに対してミラートピックは自動作成されません。

自動作成されたトピックの削除¶

ミラートピック自動作成フィルターに一致するミラートピックは削除できません。そのようなトピックを削除し、送信元クラスターに同じ名前のトピックがあった場合、ミラートピックは自動的に再作成され、そのすべての履歴が同期されます。その結果、削除操作が無駄なものになってしまいます。

To delete a mirror topic while auto-create mirror topics is enabled, you have three options: delete the source topic first, exclude the topic’s name from the auto-create mirror topics filters, or disable auto-create mirror topics.

cool-topic という送信元トピックがあり、送信元トピックをまず削除し、関連付けられたミラートピック（送信先の cool-topic）をそれから続けて削除する場合は、それが FAILED ミラートピックになるまで待ちます（最大 5 分かかる可能性があります）。その後で、トピックを削除することができます。FAILED と STOPPED の両方のミラートピックを削除できます。
Option 2. Exclude the topic name from the auto-create mirror topics filters - This strategy will prevent the mirror topic from overlapping 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. You can add cool-topic to the EXCLUDE filters, even if no such source topic exists. After editing the auto-create mirror topic filters, you can delete the mirror topic.
Option 3: Disable auto-create mirror topics on the cluster link - After the setting has been disabled, the mirror topic can be deleted. If needed, auto-create mirror topics can be immediately re-enabled on the cluster link. To learn more, see ミラートピックの自動作成の有効化 and ミラートピックの削除.

ミラートピックの自動作成の有効化¶

To disable auto-create mirror topics entirely, set this property on the cluster link:

auto.create.mirror.topics.enable=false

Here’s an example of how to set that property with the CLI:

echo "auto.create.mirror.topics.enable=false" > tmp.txt

confluent kafka link update <link-name> --config-file tmp.txt

rm tmp.txt

Prefixing Mirror Topics and Consumer Group Names¶

Cluster links can be configured with a prefix (cluster.link.prefix) that is applied to the names of the mirror topics and, optionally, the names of the consumer groups that are managed by the cluster link at the destination cluster. This enables topics and consumer groups from different source clusters that have the same name to be synced to the destination without name clashes. It also enables all mirror topics from a cluster link to be categorized and managed under one prefix on the destination.

For example, consider two links, link-1 and link-2. link-1 is linking data from cluster s1 to destination and link-2 is linking data from s2 to destination, and furthermore s1 and s2 both contain a topic “clicks”. Without prefixing, it would be impossible for both links to sync data for their own “clicks” topic as they would have the same name on the destination cluster. With prefixing, each link can have its own unique prefix that is applied to the topic name as its mirrored. link-1 could have prefix usa_ and link-2 could have prefix eu_. Finally, at the destination cluster there would be two topics, usa_clicks and eu_clicks.

If the link is configured with a prefix, when a mirror topic is created (for example, with confluent kafka mirror create) then the mirror topic name must begin with the prefix (otherwise, the operation will fail). If auto-create mirror topics is used, the topics created on the destination will automatically be named with the prefix.

The prefix can optionally be applied to the consumer groups that are created on the destination cluster because of consumer group offset syncing. When offsets are synced, consumer groups are created on the destination; with this feature it’s possible to prefix the consumer group name on the destination. This enables consumer group offsets to be synced even when two (or more) consumer groups from two (or more) different source clusters have the same name. For example, if link-1 had consumer group g1 and link-2 had consumer group g1, then prefixing would result in two consumer groups at the destination: usa_g1 and eu_g1. By default, consumer group names are not prefixed with the prefix; consumer.group.prefix.enable must be set to true in the cluster link config to enable this.

Here’s an example configuration file for Confluent Enterprise, containing just elements relevant to prefixing:

bootstrap.servers=localhost:9092
cluster.link.prefix=usa_
consumer.offset.sync.enable=true
auto.create.mirror.topics.enable=true
auto.create.mirror.topics.filters={"topicFilters":[{"name": "*","patternType": "LITERAL","filterType": "INCLUDE"}]}
consumer.group.prefix.enable=false
acl.sync.enable=false

Here, a prefix of usa_ has been configured and consumer.group.prefix.enable has been set to false (which is the default, but shown here for context). All mirror topic names on the destination will start with the prefix; consumer group names will remain the same as they are on the source. Also note, acl.sync.enable is set to false which is required because auto.create.mirror.topics.enable is set to true and prefixing is enabled; see limitations below.

On Confluent Cloud, these configurations are specified on the command line or the Confluent Cloud console.

Limitations on Prefixing¶

The prefix cannot be changed after the cluster link is created.

ACL syncing and prefixing cannot be enabled at the same time. Note, ACLs can always be synced on a separate link; just create a new link and configure it to sync ACLs.

Prefixing cannot be combined with chaining and auto-create mirror topics at the same time. When auto-mirroring and prefixing is configured, a link cannot mirror a topic that is itself a mirror topic at the source cluster. For example, consider the same links above, link-1 and link-2. If a new link-3 was created, auto-mirroring would not be able to mirror data from usa_clicks or eu_clicks or any mirror topic on the destination (even if it didn’t have a prefix) because they are mirror topics. This is done as a safeguard to prevent auto-mirroring from creating an infinite number of topics due to cyclical cluster link connections.

ちなみに

Prefixed chained mirror topics can still be created by hand, for example via confluent kafka mirror create.

ミラーリングラグ¶

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

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

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

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

注釈

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

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

ミラートピックで failover または promote が呼び出されたときに、クラスターリンクでコンシューマーオフセットの同期が有効になっている場合は、そのトピックのコンシューマーオフセットが "固定される" 可能性があります。つまり、クラスターリンクが同期したトピックのコンシューマーオフセットが、ミラートピックの最後のオフセット（"ログ終了オフセット"）よりも大きくなることは許容されません。これらのコンシューマーオフセットのいずれかが最後のオフセット（ログ終了オフセット）よりも大きいか離れている場合は、それらのコンシューマーオフセットはログ終了オフセットにリセットされます。（failover と promote の使用法については、次のセクションの「ミラートピックから通常のトピックへの変換」で取り上げます。）

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

To learn more, see consumer.offset.group.filters in the Confluent Cloud documentation under Configuring Cluster Link Behavior and in the Confluent Platform documentation under configuration options for cluster links.

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

生成先にできる通常のトピックにミラートピックを変換する場合は、ミラートピックに対して 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 によって検出されません。
ミラートピックがまだ存在しているクラスターリンクは削除できません（削除操作は失敗します）。
Confluent for Kubernetes （CFK）を使用している場合にクラスターリンクリソースを削除すると、そのクラスターリンクに関連付けられたままのミラートピックは、failover API を使用して強制的に通常のトピックに変換されます。

../../_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

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

注釈

Using a Confluent Platform 7.0.x source cluster with a source-initiated link to a KRaft destination cluster will generate a SOURCE_UNAVAILABLE error. Cluster Linking between a source cluster running Confluent Platform 7.0.x or earlier (non-KRaft) and a destination cluster running in KRaft mode is not supported. To solve for this, upgrade the source cluster to Confluent Platform 7.1.0 or later.

LINK_FAILED

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

FAILED

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

ミラートピックの削除¶

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

ミラートピックを削除するには、通常のトピックを削除するのに使用するコマンドと同じコマンドを使用します。

confluent kafka topic delete <topic-name>

詳細については、「自動作成されたトピックの削除」を参照してください。

注釈

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

送信元トピックの削除¶

注意

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

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

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

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

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

ミラートピックとスキーマとの連携方法¶

|cluster-linking|は、各メッセージのスキーマ ID を保存します。したがって、スキーマを使用しているミラートピックから消費するには、コンシューマークライアントが、送信元トピックに対してプロデューサーにより使用された |sr| コンテキストと同じスキーマ ID を持つ Schema Registry コンテキストを使用する必要があります。その結果、スキーマを使用するミラートピックからの消費は、以下のいずれかの方法で行われます。

（オプション 1）プロデューサーが使用したものと同じ Schema Registry を使用する
（オプション 2） Schema Linking により、プロデューサーが使用した Schema Registry から同期された Schema Registry コンテキストを使用する

注意

When using Schema Linking: To use a mirror topic that has a schema with Confluent Cloud Connect, ksqlDB, broker-side schema validation, or the topic viewer, make sure that Schema Linking puts the schema in the default context of the Confluent Cloud Schema Registry. These fully-managed Confluent Cloud features require schemas to be in the default context of the Confluent Cloud Schema Registry in their Environment.

../../_images/mirror-topics-and-schemas.ja.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 の値は同期されます。

ミラートピック¶

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

概要¶

特徴¶

ミラートピックの作成¶

Command syntax¶

Creating a mirror topic with the AdminClient API¶

フィルターの例¶

Requirements¶

Additional requirements when prefixing is enabled¶

Cluster Linking¶

Cherry pick which topics to mirror¶

Support for compacted topics¶

Diagram of a cluster link¶

ミラートピックの自動作成¶

ミラートピックの自動作成の有効化¶

ミラートピック自動作成のフィルター¶

フィルターの例¶

すべてのトピックをミラーリング¶

指定した文字列で始まるすべてのトピックをミラーリング¶

"secret" で始まるトピックを除くすべてのトピックをミラーリング¶

送信元クラスター上に存在する名前付きトピックをミラーリング¶

ミラートピックが自動作成される方法¶

自動作成されたトピックの削除¶

ミラートピックの自動作成の有効化¶

Prefixing Mirror Topics and Consumer Group Names¶

Limitations on Prefixing¶

ミラーリングラグ¶

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

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

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

ミラートピックの削除¶

送信元トピックの削除¶

ミラートピックとスキーマとの連携方法¶

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

チェーン¶

ファンアウト¶

構成¶

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

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

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

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

おすすめの関連情報¶

Cluster Linking ¶