TTL インデックスを持つ MongoDB コレクションの同期または移行に関するベストプラクティス - Data Transmission Service

Data Transmission Service (DTS) を使用して Time-to-Live (TTL) インデックスを持つ MongoDB コレクションを同期または移行する際に、タスクの遅延やデータ不整合が発生することがあります。このガイドでは、このプロセス中に宛先インスタンス上の TTL インデックスの有効期限を一時的に変更する方法について説明します。この方法により、データ同期またはデータ移行の効率と一貫性を確保できます。

利用シーン

ビジネスの成長やアーキテクチャのアップグレードに伴い、MongoDB インスタンスを新しいインスタンスに移行する必要が生じることがあります。このインスタンスには、ユーザーセッション、ログ、一時的なキャッシュデータなど、TTL インデックスを多用するコレクションが含まれている場合があります。DTS を使用して、完全データ同期と増分データ同期を実行できます。主な目標は、データ損失がなく、サービスへの影響を最小限に抑えながら、スムーズで効率的な移行を保証することです。

しかし、TTL インデックスの自動削除メカニズムは、DTS のデータ同期メカニズムと競合する可能性があります。この競合は、タスクの遅延やデータ不整合を引き起こす可能性があります。これは、以下の理由によります：

増分書き込み中の DELETE 操作の欠落による効率低下：ソースインスタンスの TTL インデックスが期限切れのデータを削除すると、Oplog に DELETE レコードが生成されます。その後、DTS はこの DELETE 操作を同期します。宛先インスタンスの TTL インデックスがすでに同じデータを削除している場合、DTS からの DELETE 操作は削除対象のデータを見つけられません。その結果、MongoDB エンジンは予期しない数の影響を受ける行数を返し、例外処理プロセスがトリガーされ、移行効率が低下します。

期限切れデータの非同期削除によるデータ不整合：TTL インデックスはリアルタイムでデータを削除しません。宛先インスタンスでデータがすでに削除されているにもかかわらず、ソースインスタンスには期限切れのデータがまだ存在する可能性があります。これにより、データ不整合が発生します。

例：

MongoDB の Oplog または ChangeStream は、UPDATE 操作で更新されたフィールドのみを記録します。更新前後の完全なドキュメントは記録されません。したがって、UPDATE 操作が宛先でターゲットデータを見つけられない場合、DTS はその操作を無視します。

タイミング	ソースインスタンス	宛先インスタンス
1	サービスがデータを挿入
2		DTS が INSERT 操作を同期
3	データは期限切れだが、TTL インデックスによってまだ削除されていない
4	サービスがデータを更新 (例：TTL インデックスフィールドを更新して有効期限を変更)
5		TTL インデックスがデータを削除
6		DTS が UPDATE を同期するが、データが見つからないため操作は無視される

その結果、このドキュメントは宛先の MongoDB インスタンスから欠落します。

ベストプラクティス

宛先インスタンスの TTL インデックスによって引き起こされる問題を回避するために、DTS の同期または移行プロセス全体 (完全同期と増分同期の両方の段階を含む) で、その自動削除機能を一時的に無効にすることができます。サービスを新しいインスタンスに切り替えた後、元の TTL 設定に戻すことができます。

次の手順に従います：

同期または移行の準備：ソースデータベースでスクリプトを実行し、TTL インデックスを持つすべてのコレクションを特定し、その有効期限設定をバックアップします。

クリックしてサンプルスクリプトを表示

// スクリプト: すべての TTL インデックスに関する情報を見つけて出力します
const collections = db.getCollectionNames();
let ttlIndexes = [];
collections.forEach(collName => {
    const indexes = db.getCollection(collName).getIndexes();
    indexes.forEach(idx => {
        if (idx.hasOwnProperty('expireAfterSeconds')) {
            console.log(`Found TTL index -> Collection: ${collName}, Index name: ${idx.name}, Expires after: ${idx.expireAfterSeconds} seconds`);
            ttlIndexes.push({
                collection: collName,
                name: idx.name,
                expireAfterSeconds: idx.expireAfterSeconds
            });
        }
    });
});
// 後続のステップのために、次の JSON 出力をファイルに保存します。
printjson(ttlIndexes);

宛先の設定の確認と変更：
1. まず、宛先インスタンスに同期または移行対象のコレクションと TTL インデックスがすでに含まれているかどうかを確認します。
2. 含まれていない場合は、まずスキーマ移行を使用してコレクションを宛先に同期します。次に、ターゲットデータベースに接続し、有効期限をデータベースで許可されている最大値に変更します。これにより、同期または移行中の自動削除が防止されます。
3. 含まれている場合は、DTS タスクを開始する前にターゲットデータベースに接続します。特定された TTL インデックスの有効期限をデータベースで許可されている最大値に変更します。これにより、同期または移行中の自動削除が防止されます。
DTS タスクの実行と監視：完全および増分 DTS 同期タスクを設定して開始します。主要なメトリックを継続的に監視し、プロセスが安定して正常であることを確認します。宛先インスタンスの TTL インデックスは事実上無効になっているため、DTS はソースからのすべての挿入、更新、削除の各操作を競合なく同期できます。これにより、効率の低下やデータ不整合のリスクが防止されます。
1. DTS コンソールでデータ同期またはデータ移行タスクを作成して開始します。
2. プロセス中は、次のメトリックの監視に重点を置きます：
  - DTS タスクの遅延：DTS コンソールのタスク詳細ページを確認します。増分同期の遅延が低いままであることを確認します。
  - 宛先インスタンスのストレージ使用量：宛先の MongoDB インスタンスのストレージ使用量を確認します。宛先インスタンスのデータは期限切れにならないため、そのストレージ使用量は継続的に増加します。十分なストレージ容量を確保してください。
移行後の設定の復元：DTS の同期が完了し、サービストラフィックを新しいインスタンスに切り替えた後、ターゲットデータベースの TTL インデックスを復元します。移行前にバックアップした設定を使用して、元の有効期限に戻します。設定を復元すると、MongoDB のバックグラウンドスレッドが、移行プロセス中に蓄積された期限切れのドキュメントのクリーンアップを開始します。

注意事項：

増分同期または増分移行中、DTS はソースの TTL インデックスによって期限切れデータに対して実行される削除操作を同期します。
宛先の TTL インデックスの有効期限を延長した後、完全または増分の同期/移行中に遅延が発生した場合、宛先インスタンスにはソースですでに期限切れになったデータが保存されます。したがって、ソースインスタンスの書き込み量に基づいて、宛先の MongoDB インスタンスに十分なストレージ容量をプロビジョニングする必要があります。
同期するオブジェクトが、一時データやログのシナリオのように、有効期限の短い TTL インデックスを持つ場合、既存データは移行しないでください。極端な場合、完全移行によるデータが宛先でほぼ即座に期限切れになり、宛先コレクションが空になる可能性があります。代わりに、サービスにデュアルライト戦略を検討するか、増分移行のみを実行することを検討できます。