debezium経験と踏み込み

debeziumのメンテナンスと半年の使用.管理されていた単一のdebeziumクラスタには、10個程度のdebeizumタスクがある.あるライブラリのdebeziumで購読されたテーブルの数は数十個ほどあり、多くの経験が得られ、多くの穴を踏んだ.以下に、さまざまな問題と良い実践をリストします.
ふみだめdebezium坑が多い!!最大の穴はkafka connectのrebalanceです.新しいdebezium connectorがクラスタに送信されるたびに、クラスタのrebalanceがトリガーされる.クラスタ内部のconnectorタスクが再起動し始め、表面的にはタスクの再割り当てが見られ、debeziumインスタンスごとにタスクに均一に割り当てることができ、確かに優雅である.しかし、実際には、クラスタ内のすべてのconnectorの動作を再起動します.自身のdebeziumのいくつかの優雅でない特性のため、再起動はクラスタ内の複数のconnectorが停止する可能性がある.したがって、クラスタをトリガするrebalanceをできるだけ少なくする必要がある.しかし、この巨大な穴は実は避けられない.
他のいくつかの大きな穴:

debeziumのhistory topicは、複数のconnectorによって共用されてはならない.新しいconnectorがクラスタ内のconnectorで使用されているhistory topicを使用している場合、クラスタ内のhistory topicを使用しているconnectorは異常終了を放出します(これは0.5.xバージョンの場合、異常を放出しません!!).

は、connectorの各ライブラリに対応し、connectorはdebeziumのあるライブラリにアクセスする必要があるテーブルのみを購読する.ライブラリのホワイトリストとテーブルのホワイトリストを設定することで実現できます.(1つのタスクが複数のライブラリを購読し、複数のテーブルが非常に不正であり、その後の新規テーブルのコストが非常に大きい)

debezium connector再起動は、毎回成功するわけではありません.つまり、connector再起動は、タスクが停止する可能性があります.history topicは非常に大きい可能性があり、connectorが再起動するとhistory topicのすべてのデータが読み出され、history topicのデータ量が非常に大きい場合、connectorは所定の時間内に起動できない可能性があり、connectorは異常起動に失敗した.

ピット3このピットはrebalanceに遭遇すると、比較的深刻な問題が発生します.クラスタ内に複数のconnectorがあり、複数のconnectorのhistroy topicが大きい場合、rebalance以降、これらのconnectorは再起動に失敗する可能性が高い.

ピット1とrebalanceにも関係があります.debeziumクラスタ内のconnectorの数が多い場合、再起動するとhistory topicが共用される異常が発生する可能性がありますが、実際には共用していません!!

推奨

1つのdebezium内でできるだけ多くのconnectorを運転しないでください.同じ数のマシンの場合、マルチクラスタの効果は単一クラスタのマルチサーバよりずっと良いです!

は、重いconnectorを個別のクラスタに移す.例えば、私の会社では、ライブラリ内の数十のテーブルを購読する必要があります.これにより、タスクの再起動が非常に遅くなり、タスクを停止するのに時間がかかります.他のconnectorと一緒に配置すれば、よくありません.

は、debeziumをk8sに配備することを推奨し、クラスタの拡張、縮小が便利です.

は、各connectorをk8s podに対応させて、互いに影響を及ぼさないように、本物のリソースを分離することを試みることができる.もちろんこれは~.~を試したことがありません.

たぶんこれだけでしょう.