Kafkaメッセージを生成/消費するためのスキーマレジストリKafkaメッセージを使用しています。たとえば、2つのフィールドがあり、どちらも文字列型であり、次のような擬似スキーマです。
{"name": "test1", "type": "string"}
{"name": "test2", "type": "string"}
しかし、しばらく送信して消費した後、スキーマを変更して2番目のフィールドをlong型に変更する必要があります。その後、次の例外がスローされました。
Schema being registered is incompatible with an earlier schema; error code: 409
スキーマレジストリがスキーマのアップグレード/変更を進化させることができない場合、私は混乱しています。なぜスキーマレジストリを使用する必要があるのか、なぜAvroを使用するのかと言うのですか?
BACKWARD
互換モードでは、フィールドの名前を変更できません。回避策として、スキーマレジストリの互換性ルールを変更できます。
docs によると:
スキーマレジストリサーバーは、新しいスキーマがサブジェクトに登録されるときに特定の互換性ルールを適用できます。現在、以下の互換性ルールをサポートしています。
下位互換性(デフォルト):新しいスキーマは、以前のすべてのスキーマに書き込まれたデータを読み取るために使用できる場合、下位互換性があります。最新のスキーマを使用して常にすべてのバージョンのデータをクエリできるため、Hadoopなどのシステムにデータをロードする場合は、下位互換性が役立ちます。
前方互換性:以前のすべてのスキーマがこのスキーマに書き込まれたデータを読み取ることができる場合、新しいスキーマは前方互換性があります。上位互換性は、常に最新バージョンであるとは限らない特定のバージョンのデータのみを処理できるコンシューマアプリケーションに役立ちます。
完全な互換性:新しいスキーマは、下位互換性と上位互換性の両方に対応している場合、完全に互換性があります。
互換性なし:新しいスキーマは、有効なAvroであればどのスキーマでもかまいません。
compatibility
をNONE
に設定すると、うまくいくはずです。
# Update compatibility requirements globally
$ curl -X PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": "NONE"}' \
http://localhost:8081/config
そして応答は
{"compatibility":"NONE"}
https://docs.confluent.io/current/avro.html 「デフォルト」を追加する必要がある場合があります:null。
既存のものを削除して、更新されたものを登録することもできます。
このように単純にデフォルト値を追加できます。
{"name": "test3", "type": "string","default": null}