最終更新日 2022年12月13日(火)

この記事では、ストリーミングデータコネクター​運用のベストプラクティスに関連したいくつかの注意事項について説明します。この統合は Apache Kafka Connect および Debezium によってサポートされているため、設定オプションについての説明箇所ではこれらのコンポーネントについて言及します。

役に立つ記事

困ったときは​ (Debezium)

注意事項

作成

• Debezium は UTF-8 データベースでのみ動作します。別のエンコードを使用している場合は、PG2K を有効にする前に エンコードを UTF-8 に変更します。コネクターが作成された後に別のエンコードに変更した場合、コネクターはイベントの処理を中止します。
• 新しいコネクターが作成されると、コネクターは Postgres データベースに接続して、すべてのスキーマの一貫したスナップショットを読み取ります。このプロセスはコストの高い操作である可能性があり、ソースの Postgres データベースとターゲットの Kafka クラスターの両方で負荷を増加させる可能性があります。テーブルと列を適切に選択するように注意する必要があります。詳細はドキュメント​をご覧ください。

使用法

• CDC イベントの “before” データが入力されるのは、テーブルの中で REPLICA IDENTITY​ に含まれる部分だけです。つまり、ほとんどの場合、デフォルトでは主キーのみが “before” データに反映されます。詳細はドキュメント​をご覧ください。
• 主キーに変更を加えるときは、スキーマ情報に問題が生じないよう、慎重に調整する必要があります。詳細はドキュメント​をご覧ください。
• CDC イベントは最低 1 回​は配信されるよう設計されています。冗長な CDC イベントを適切に処理するように、Kafka コンシューマーをビルドおよび設定する必要があります。不具合が発生した場合は、さらに多くのイベントが表示されることがあります。重複したイベントについての詳細は、Debezium の FAQ​ にある「Why must consuming applications expect duplicate events?​」(消費側のアプリケーションで重複したイベントを予測する必要があるのはなぜですか?) を参照してください。
• UPDATE​ イベントの際、変更のない TOAST 値にはプレースホルダー __debezium_unavailable_value​ があります。この値を考慮に入れておかないと、実際の値であるかのようにプレースホルダーを使用してしまいます。詳細はドキュメント​をご覧ください。
• 大量のデータを含むデータベース行から Kafka メッセージを生成する場合、トピックの最大メッセージサイズ (デフォルト: 1 MB) を超えるメッセージは生成できません。これらの変更は (内部で) ログに記録されますが、イベントは生成されません (暗黙的に処理されます)。
• Kafka トピックは、1 つ以上のパーティションで作成されます。その結果、消費されるときに変更イベントは完全なグローバルな順序付けがされません​。特定の行の変更イベントは、完全に順序付けされています。順序付けについての詳細は、Debezium の FAQ​ にある「How are events for a database organized?​」(データベースのイベントはどのように構成されていますか?) を参照してください。

障害

• コネクターがレプリケーションを停止した場合、コネクターの進行状況を追跡するレプリケーションスロットは WAL (ログ先行書き込み) が削除されるのを防ぎます。Postgres データベースで WAL 用のディスク領域が不足した場合、データベースは完全に停止します。詳細はドキュメント​をご覧ください。
• さまざまな理由で障害が発生し、コネクターの停止に至る可能性があります。たとえば、ネットワークパーティション、AWS の問題、Kafka Connect または Debezium のバグ、Heroku のコントロールプレーンの問題などが考えられます。データベースのレプリケーションスロット​を監視し、これらの状況の有無を確認することは重要です。
• 特定の障害モードでは、データベースの安定運用を維持するためにレプリケーションスロットを削除します。条件がクリアされ、レプリケーションスロットが再び作成されると、コネクターは新しいレプリケーションスロットを作成し、そのリカバリポイントからイベントの発行を開始します。データベースが停止する前に Kafka にストリーミングされなかった変更イベントは失われます。

一時停止したコネクター

• コネクターを「一時停止」状態にしたまま数時間放置しないでください。一時停止したコネクターによって WAL が削除されず、それによってプライマリデータベースにリスクが生じる可能性があります。コネクターを長期間一時停止したままにするよりは、破棄することをお勧めします。
• コネクターが一時停止中に発生した変更イベントは、Kafka に送達されることが保証されません​。フェイルオーバーが発生した場合 (システム障害または定期的なメンテナンスによる)、コネクターの一時停止後の変更イベントは失われます。

破棄

• テーブルを削除すると、対応する Kafka トピックはツームストーン状態になりますが、破棄されるわけではありません。
• コネクターのプロビジョニングを解除しても、関連付けられた Kafka トピックのプロビジョニングは自動的に解除されません。このデータを削除したい場合は、CLI を使用して heroku kafka:topics:destroy <topic_name> --app <app_name>​ を実行して、これらのトピックを手動で削除する必要があります。詳細はドキュメント​をご覧ください。