1. Home
2. Cloud
3. Cluster Linking

重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

ミラートピック

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

What are Mirror Topics?

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

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

概要

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

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

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

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

ミラートピックの基礎

特徴

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

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

ミラートピックの作成

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.

Examples

For examples of how to create mirror topics on Confluent Platform, 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.

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

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

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

Mirror topics enforce the convention of preserving topic names. The best practice for a global mesh of clusters is for a topic’s name to reflect the cluster where it originated.

たとえば、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

For more about configuring security, see Cluster Linking Security.

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.

Bidirectional 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:

• set filters
• 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

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

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

Auto-Create Mirror Topics

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

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

この機能を有効にするには、クラスターリンクに 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 スキーマレジストリ 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.

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.

各フィルターは次のフィールドを持つ 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" というトピックは自動的にミラーリングされません。

There is no limit to the number of filters you can add on a cluster link.

フィルターの例

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

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

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

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

This filter will mirror all topics that begin with "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.

• Option 1. Delete the source topic first - Given a source topic named cool-topic, if you delete the source topic and then want to subsequently delete the associated mirror topic (cool-topic on the destination), wait until the mirror topic becomes a FAILED mirror topic (which may take up to five minutes), after which point you can delete it. You can also call failover or promote on the mirror topic to transition it to the STOPPED state. Both FAILED and STOPPED mirror topics can be deleted.
• 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 Disabling auto-create mirror topics and ミラートピックの削除.

Disabling auto-create mirror topics

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 つのプロパティが設定されると、クラスターリンクは、リンクがミラーリングしているすべてのミラートピックについて、一致するコンシューマーグループすべてのコンシューマーグループオフセットを同期します。これにより、ミラートピックは送信元トピックと同期されたコンシューマーグループオフセットを持つことができます。

注釈

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

Why consumer offsets may be clamped in the event of failover, promote, or consumer group migration

When either failover or promote is called on a mirror topic or when a consumer group moves to the destination cluster and consumes its first message from a mirror topic, if consumer offset sync is enabled on the cluster link, then the consumer offsets for that topic may be “clamped”. That is, the consumer offsets for the topic that the cluster link synced will not be allowed to be larger than the last offsets on the mirror topic (the “log end offset”). If any of these consumer offsets are larger / further than the last offsets (Log End Offset), then those consumer offsets will be reset to the Log End Offset. (The use of failover and promote are covered in the next section on ミラートピックから通常のトピックへの変換.)

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

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

重要

• You can run mirror describe (confluent kafka mirror describe <mirror-topic-name> --link <link>) on a promoted or failed over mirror topic, if you don't delete the cluster link. If you delete the cluster link, you will lose the history and, therefore, mirror describe will not find data on promoted or failed over topics.
• 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.

トピックの移行の例

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

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

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

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>

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

重要

• When deleting a cluster link, first check that all mirror topics are in the STOPPED state. If any are in the PENDING_STOPPED state, deleting a cluster link can cause irrecoverable errors on those mirror topics due to a temporary limitation.
• 接続されているミラートピックのあるクラスターリンクは削除できません。ミラートピックを先に削除、フェイルオーバー、またはプロモートしておく必要があり、それが済むとクラスターリンクを削除できるようになります。

送信元トピックの削除

注意

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

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

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

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

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

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

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

• （オプション 1）プロデューサーが使用したものと同じ スキーマレジストリ を使用する
• (Option 2) using a スキーマレジストリ context that was synced through Schema Linking from the スキーマレジストリ that the producers used

注意

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 スキーマレジストリ. These fully-managed Confluent Cloud features require schemas to be in the default context of the Confluent Cloud スキーマレジストリ in their Environment.

ミラートピックとスキーマ

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

チェーン

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

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

ちなみに

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

チェーンの例

ファンアウト

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

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

ちなみに

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

ファンアウトの例

構成

以下のセクションでは、ソースからミラートピックへ同期される Cluster Linking 構成、オーバーライド、同期関連の概念について簡単に説明します。

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

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

• パーティションの数
• 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

同期されないミラートピック構成

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

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

• min.insync.replicas
• confluent.placement.constraints
• compression.type
• replication.factor （レプリケーション係数はミラートピックに同期されません。レプリケーション係数のデフォルトはすべてのトピックで 3 であり、これは構成できません。）

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

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

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

おすすめの関連情報

• Confluent Cloud でのクラスターリンク（概要とチュートリアルへのリンク）
• Confluent Platform の「Cluster Linking」