第4章 MongoDB の Debezium Connector

MongoDB のレプリケーションメカニズムは冗長性と高可用性を提供し、MongoDB を実稼働環境で実行するのに推奨される方法です。MongoDB コネクターは、レプリカセットまたはシャードクラスターの変更をキャプチャーします。

MongoDB レプリカセットは、すべて同じデータのコピーを持つサーバーセット から構成され、レプリケーションにより、クライアントがレプリカセットのプライマリードキュメントに対して加えたすべての変更が、別のレプリカセットのサーバー（セカンダリー）に 正しく 適用されるようにし ます。MongoDB レプリケーションは、プライマリーレコードを oplog （ または操作ログ）に記録することで機能します。次に、各秒はプライマリーの oplog を読み取り、すべての操作を独自のドキュメントに読み込みます。レプリカセットに新しいサーバーを追加すると、そのサーバーは最初にプライマリー上のすべてのデータベースおよびコレクションの スナップショット を実行して、プライマリーの oplog を読み取り、スナップショットの作成以降に追加された可能性のあるすべての変更を適用します。この新しいサーバーは、プライマリーの oplog の末尾に追い付くとセカンダリー（クエリーを処理する）になります。

MongoDB コネクターは同じレプリケーションメカニズムを使用しますが、実際にはレプリカセットのメンバーになっていません。ただし、MongoDB の秒数と同様に、コネクターはレプリカセットのプライマリー oplog を常に読み取ります。また、コネクターがレプリカセットを初めて表示すると、oplog を確認して最後に記録されたトランザクションを取得し、プライマリーのデータベースおよびコレクションのスナップショットを実行します。すべてのデータをコピーすると、コネクターは oplog から先に読み込んだ位置からの変更のストリーミングを開始します。MongoDB oplog の操作は べき等 であるので、操作が適用される回数に関係なく、同じ終了状態になります。

MongoDB コネクタープロセスが変更されると、イベントの発生先の oplog に定期的に位置が記録されます。MongoDB コネクターが停止すると、処理した最後の oplog の位置を記録し、再起動時にその位置からストリーミングを開始します。つまり、コネクターを停止、アップグレード、または維持し、後で再起動でき、単一イベントを損失することなく、そのまま停止した場所を特定できます。当然ながら、MongoDB の oplog は通常最大サイズに制限されます。つまり、コネクターは停止するべきではないか、またはコネクターを読み取る前に oplog の操作の一部がパージされる可能性があります。この場合、コネクターは不足している oplog 操作を検出し、スナップショットを実行してから変更をストリーミングします。

MongoDB コネクターは、レプリカセットのメンバーシップやリーダーの変更、シャードの追加または削除、および通信の失敗を引き起こす可能性のあるネットワークの問題に非常に耐性があります。コネクターは常にレプリカセットのプライマリーノードを使用して変更をストリーミングします。そのため、レプリカセットの選択が行われ、異なるノードがプライマリー状態になると、コネクターは即座にストリーミングを停止し、新しいプライマリーノードに接続し、新しいプライマリーノードを使用して変更をストリーミングを開始します。同様に、コネクターがレプリカセットのプライマリーとの通信に問題がある場合には、再接続を試みます（ネットワークまたはレプリカセットをオーバーコミットしないようにするために使用されるため）、最後に停止した場所から変更のストリーミングを継続します。これにより、コネクターはレプリカセットメンバーシップの変更に動的に調整し、通信の失敗を自動的に処理できます。