debezium - Debezium は変更データキャプチャ (Change Data Capture; CDC) のための低遅延データストリーミングプラットフォームを提供するオープンソースプロジェクトです。

(Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ.)

Created at: 2016-01-23 04:17:05
Language: Java
License: NOASSERTION

ライセンス メイヴン・セントラル ユーザーチャット 開発者チャット Google グループ スタックオーバーフロー

著作権 Debezium 作者。Apache ライセンス、バージョン 2.0の下でライセンス供与されています。debezium-ddl-parser モジュール内の Antlr 文法は、MIT Licenseの下でライセンスされています。

英語 | 中国語| 日本語| 韓国語

デベジウム

Debezium は、変更データ キャプチャ (CDC) 用の低レイテンシ データ ストリーミング プラットフォームを提供するオープン ソース プロジェクトです。データベースを監視するように Debezium をセットアップおよび構成すると、アプリケーションは、データベースに対して行レベルの変更が行われるたびにイベントを消費します。コミットされた変更のみが表示されるため、アプリケーションはロールバックされるトランザクションや変更について心配する必要がありません。Debezium はすべての変更イベントの単一モデルを提供するため、アプリケーションは各種データベース管理システムの複雑さについて心配する必要がありません。さらに、Debezium は耐久性のある複製されたログにデータ変更の履歴を記録するため、アプリケーションはいつでも停止および再起動でき、実行されていない間に逃したすべてのイベントを消費できます。

データベースを監視し、データが変更されたときに通知を受けることは、常に複雑です。リレーショナル データベース トリガーは便利な場合がありますが、各データベースに固有であり、多くの場合、同じデータベース内の状態の更新に限定されます (外部プロセスとの通信ではありません)。一部のデータベースは、変更を監視するための API またはフレームワークを提供していますが、標準がないため、各データベースのアプローチは異なり、多くの知識と専門的なコードが必要です。データベースへの影響を最小限に抑えながら、すべての変更が同じ順序で表示および処理されるようにすることは、依然として非常に困難です。

Debezium は、この作業を行うモジュールを提供します。一部のモジュールは汎用的で、複数のデータベース管理システムで動作しますが、機能とパフォーマンスが少し制限されています。他のモジュールは、特定のデータベース管理システム用に調整されているため、多くの場合、はるかに機能が高く、システムの特定の機能を活用しています。

基本アーキテクチャ

Debezium は、Kafka と Kafka Connect を再利用することで、耐久性、信頼性、耐障害性を実現する変更データ キャプチャ (CDC) プラットフォームです。Kafka Connect 分散型でスケーラブルなフォールト トレラント サービスにデプロイされた各コネクタは、単一のアップストリーム データベース サーバーを監視し、すべての変更をキャプチャして、1 つ以上の Kafka トピック (通常はデータベース テーブルごとに 1 つのトピック) に記録します。Kafka は、これらすべてのデータ変更イベントがレプリケートされ、完全に順序付けられていることを保証し、多くのクライアントが上流システムにほとんど影響を与えずにこれらの同じデータ変更イベントを個別に使用できるようにします。さらに、クライアントはいつでも消費を停止でき、再起動すると中断したところから再開します。各クライアントは、すべてのデータ変更イベントを 1 回だけ配信するか、少なくとも 1 回配信するかを決定できます。

このレベルのフォールト トレランス、パフォーマンス、スケーラビリティ、および信頼性を必要としないアプリケーションは、代わりに Debezium の組み込みコネクタ エンジンを使用して、アプリケーション スペース内で直接コネクタを実行できます。彼らは依然として同じデータ変更イベントを必要としていますが、Kafka 内に保持するのではなく、コネクターがそれらをアプリケーションに直接送信することを好みます。

一般的な使用例

Debezium が非常に価値のあるシナリオは数多くありますが、ここでは、より一般的ないくつかのシナリオについて概説します。

キャッシュの無効化

エントリのレコードが変更または削除されるとすぐに、キャッシュ内のエントリを自動的に無効にします。キャッシュが別のプロセス (Redis、Memcache、Infinispan など) で実行されている場合、単純なキャッシュ無効化ロジックを別のプロセスまたはサービスに配置して、メイン アプリケーションを簡素化できます。場合によっては、ロジックをもう少し洗練して、変更イベントで更新されたデータを使用して、影響を受けるキャッシュ エントリを更新することができます。

モノリシック アプリケーションの簡素化

多くのアプリケーションは、データベースを更新し、変更がコミットされた後に、検索インデックスの更新、キャッシュの更新、通知の送信、ビジネス ロジックの実行などの追加作業を行います。アプリケーションが複数のシステムに書き込みを行うため、これは「二重書き込み」と呼ばれることがよくあります。単一のトランザクションの外。アプリケーション ロジックが複雑で維持が難しいだけでなく、二重書き込みは、コミット後、他の更新の一部またはすべてが実行される前にアプリケーションがクラッシュした場合に、データを失ったり、さまざまなシステムの一貫性を失わせたりするリスクもあります。変更データ キャプチャを使用すると、データが元のデータベースにコミットされるときに、これらの他のアクティビティを個別のスレッドまたは個別のプロセス/サービスで実行できます。このアプローチは、障害に対してより寛容で、イベントを見逃さず、より適切に拡張できます。

データベースの共有

複数のアプリケーションが 1 つのデータベースを共有している場合、あるアプリケーションが別のアプリケーションによってコミットされた変更を認識するのは簡単なことではありません。1 つのアプローチはメッセージ バスを使用することですが、非トランザクション メッセージ バスには上記の「二重書き込み」の問題があります。ただし、これは Debezium では非常に簡単になります。各アプリケーションはデータベースを監視し、変更に対応できます。

データ統合

多くの場合、データは複数の場所に保存されます。特に、さまざまな目的で使用され、形式がわずかに異なる場合は特にそうです。複数のシステムの同期を維持することは困難な場合がありますが、単純な ETL タイプのソリューションは、Debezium と単純なイベント処理ロジックを使用して迅速に実装できます。

CQRS

Command Query Responsibility Separation (CQRS)アーキテクチャ パターンでは、更新用に 1 つのデータ モデルを使用し、読み取り用に 1 つ以上の他のデータ モデルを使用します。更新側で変更が記録されると、それらの変更が処理され、さまざまな読み取り表現を更新するために使用されます。その結果、CQRS アプリケーションは通常、特に信頼性の高い完全に順序付けされた処理を保証する必要がある場合、より複雑になります。Debezium と CDC は、これをより親しみやすくすることができます。書き込みは通常どおり記録されますが、Debezium は、読み取り専用ビューを非同期に更新するサービスによって消費される、永続的で完全に順序付けられたストリームでそれらの変更をキャプチャします。書き込み側のテーブルは、ドメイン指向のエンティティを表すことができます。または、CQRS がイベント ソーシングとペアになっている場合書き込み側のテーブルは、コマンドの追加専用のイベント ログです。

デベジウムの構築

Debezium コードベースを使用してローカルでビルドするには、次のソフトウェアが必要です。

お使いのプラットフォームでのインストール手順については、上記のリンクを参照してください。バージョンがインストールされ、実行されていることを確認できます。

$ git --version
$ javac -version
$ mvn -version
$ docker --version

なぜDocker?

多くのオープン ソース ソフトウェア プロジェクトは Git、Java、および Maven を使用していますが、Docker を必要とすることはあまり一般的ではありません。Debezium は、さまざまなデータベースやサービスなど、多数の外部システムと対話するように設計されており、統合テストでは、Debezium がこれを正しく行うことを確認しています。ただし、これらのソフトウェア システムがすべてローカルにインストールされているとは思わないでください。Debezium のビルド システムは Docker を使用して、必要なイメージを自動的にダウンロードまたは作成し、各システムのコンテナーを起動します。その後、統合テストでこれらのサービスを使用して、Debezium が期待どおりに動作することを確認できます。統合テストが完了すると、Debezium のビルドは開始したすべてのコンテナーを自動的に停止します。

Debezium には、Java で書かれていないモジュールもいくつかあるため、対象のオペレーティング システムで必要になる必要があります。Docker を使用すると、ターゲット オペレーティング システムと必要なすべての開発ツールを含むイメージを使用してビルドを行うことができます。

Docker を使用すると、いくつかの利点があります。

  1. 各外部サービスの特定のバージョンをローカル マシンにインストール、構成、および実行する必要はなく、ローカル ネットワーク上でそれらにアクセスする必要もありません。そうしたとしても、Debezium のビルドはそれらを使用しません。
  2. 外部サービスの複数のバージョンをテストできます。各モジュールは必要なコンテナーを開始できるため、異なるモジュールは異なるバージョンのサービスを簡単に使用できます。
  3. 誰もが完全なビルドをローカルで実行できます。必要なすべてのサービスがセットアップされた環境でビルドを実行するリモートの継続的インテグレーション サーバーに依存する必要はありません。
  4. すべてのビルドは一貫しています。複数の開発者がそれぞれ同じコードベースをビルドすると、同じまたは同等の JDK、Maven、および Docker バージョンを使用している限り、まったく同じ結果が表示されます。これは、コンテナが同じオペレーティング システムで同じバージョンのサービスを実行するためです。さらに、すべてのテストはコンテナーで実行されているシステムに接続するように設計されているため、ローカル環境に固有の接続プロパティやカスタム構成をいじる必要はありません。
  5. サービスがデータを変更してローカルに保存する場合でも、サービスをクリーンアップする必要はありません。Dockerイメージはキャッシュされるため、それらを再利用してコンテナを起動すると、高速で一貫性が保たれます。ただし、Dockerコンテナーは再利用されることはありません。コンテナーは常に元の初期状態で開始され、シャットダウンされると破棄されます。統合テストはコンテナーに依存しているため、クリーンアップは自動的に処理されます。

Docker 環境を構成する

Docker Maven プラグインは、次の環境変数をチェックして docker ホストを解決します。

export DOCKER_HOST=tcp://10.1.2.2:2376
export DOCKER_CERT_PATH=/path/to/cdk/.vagrant/machines/default/virtualbox/.docker
export DOCKER_TLS_VERIFY=1

Docker Machine などを使用している場合、これらは自動的に設定できます。

コードの構築

まず、Git リポジトリを複製してコードを取得します。

$ git clone https://github.com/debezium/debezium.git
$ cd debezium

次に、Maven を使用してコードをビルドします。

$ mvn clean verify

ビルドが開始され、さまざまな DBMS に対して複数の Docker コンテナーが使用されます。Docker が実行されていない、または構成されていない場合は、難解なエラーが発生する可能性があることに注意してください。この場合は、Docker が実行されていることを常に確認してください。たとえば、 を使用

docker ps
して、実行中のコンテナーを一覧表示します。

ビルドのために Docker をローカルで実行していませんか?

次のコマンドを使用して、統合テストと docker-builds をスキップできます。

$ mvn clean verify -DskipITs

テストや CheckStyle などを実行せずに、成果物だけをビルドします。

「クイック」ビルド プロファイルを使用して、重要でないすべてのプラグイン (テスト、統合テスト、CheckStyle、フォーマッター、API 互換性チェックなど) をスキップできます。

$ mvn clean verify -Dquick

これにより、QA 関連の Maven プラグインを実行せずに、出力アーティファクトのみを生成する最速の方法が提供されます。これは、Kafka Connect での手動テストなど、コネクタ JAR やアーカイブをできるだけ早く作成するのに便利です。

wal2json または pgoutput 論理デコード プラグインを使用した Postgres コネクタのテストの実行

Postgres コネクタは、DB サーバーからコネクタに変更をストリーミングするための 3 つの論理デコード プラグイン (decoderbufs (デフォルト)、wal2json、および pgoutput) をサポートしています。wal2json を使用して PG コネクタの統合テストを実行するには、「wal2json-decoder」ビルド プロファイルを有効にします。

$ mvn clean install -pl :debezium-connector-postgres -Pwal2json-decoder

pgoutput を使用して PG コネクタの統合テストを実行するには、「pgoutput-decoder」および「postgres-10」ビルド プロファイルを有効にします。

$ mvn clean install -pl :debezium-connector-postgres -Ppgoutput-decoder,postgres-10

wal2json プラグインを使用すると、現在いくつかのテストがパスしません。で定義されている型への参照を

io.debezium.connector.postgresql.DecoderDifferences
探して、これらのテストを見つけます。

特定の Apicurio バージョンで Postgres コネクタのテストを実行する

特定のバージョンの Apicurio で wal2json または pgoutput 論理デコード プラグインを使用して PG コネクタのテストを実行するには、テスト プロパティを次のように渡します。

$ mvn clean install -pl debezium-connector-postgres -Pwal2json-decoder 
      -Ddebezium.test.apicurio.version=1.3.1.Final

プロパティがない場合、Apicurio の安定版が取得されます。

Amazon RDS などの外部データベースに対して Postgres コネクタのテストを実行する

非 RDSクラスターに対してテストする場合は、このテストでは、 のデータベースにログインする権限

<your user>
だけでなく、権限を持つスーパーユーザーである必要があることに注意してください。また、一部のテストに合格するには、ターゲット サーバーでパッケージを使用できる必要があります。
replication
all
pg_hba.conf
postgis

$ mvn clean install -pl debezium-connector-postgres -Pwal2json-decoder \
     -Ddocker.skip.build=true -Ddocker.skip.run=true -Dpostgres.host=<your PG host> \
     -Dpostgres.user=<your user> -Dpostgres.password=<your password> \
     -Ddebezium.test.records.waittime=10

必要に応じてタイムアウト値を調整します。

テスト対象の RDS でデータベースを設定する方法の詳細については、Amazon RDS での PostgreSQL を参照してください。

Oracle XStream を使用した Oracle コネクタのテストの実行

$ mvn clean install -pl debezium-connector-oracle -Poracle-xstream,oracle-tests -Dinstantclient.dir=<path-to-instantclient>

非 CDB データベースを使用した Oracle コネクタのテストの実行

$ mvn clean install -pl debezium-connector-oracle -Poracle-tests -Dinstantclient.dir=<path-to-instantclient> -Ddatabase.pdb.name=

IDE から oplog をキャプチャして MongoDB のテストを実行する

Maven を使用せずにテストを実行する場合は、実行時に正しいパラメーターを渡すようにしてください。で正しいパラメーターを探し、

.github/workflows/mongodb-oplog-workflow.yml
それらを JVM 実行パラメーターに追加し、プレフィックス を付けます
debezium.test
。実行はライフサイクル実行の外で行われるため、MongoDB コネクタ ディレクトリから手動で MongoDB コンテナを開始する必要があります。

$ mvn docker:start -B -am -Passembly -Dcheckstyle.skip=true -Dformat.skip=true -Drevapi.skip -Dcapture.mode=oplog -Dversion.mongo.server=3.6 -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dcapture.mode=oplog -Dmongo.server=3.6

行の関連部分は次のようになります。

java -ea -Ddebezium.test.capture.mode=oplog -Ddebezium.test.version.mongo.server=3.6 -Djava.awt.headless=true -Dconnector.mongodb.members.auto.discover=false -Dconnector.mongodb.name=mongo1 -DskipLongRunningTests=true [...]

貢献する

Debezium コミュニティは、問題の報告、ドキュメンテーションの支援、バグ修正、テストの追加、新機能の実装のためのコード変更の貢献など、あらゆる方法で支援したい人を歓迎します。詳細については、このドキュメントを参照してください。

すべての Debezium 貢献者に心から感謝します!