ApsaraDB for MongoDB:MongoDB の後続バージョンへのアップグレード理由

移行中の孤立ドキュメントによるデータの不整合

• 影響を受けるバージョン：MongoDB 4.2 以降を実行するシャードクラスターインスタンス

• 修正済みバージョン：MongoDB 4.4 以降

チャンクがソースシャードから送信先シャードへ移行した後、ソースシャードはチャンクを一時的に保持したまま削除します。移行が中断されると、孤立ドキュメントが残存します。孤立ドキュメントは、mongos ノードでのリクエストには影響しません。これは、ConfigServer ノードのルーティングデータによってリクエストが検証されるためです。ただし、孤立ドキュメントが蓄積すると、その後の移行中にデータの不整合が発生します。

MongoDB 4.4 では、自己回復型のチャンク移行および孤立ドキュメントの自動クリーンアップ機能が導入されました。ノードが移行途中で障害を起こした場合でも、MongoDB は処理を自動的に再開します。そのため、cleanupOrphaned コマンドを手動で実行する必要はありません。バックグラウンドのクリーンアップスレッドが有効であることを確認する場合にのみ、このコマンドを実行してください。

詳細については、「cleanupOrphaned」をご参照ください。

compact コマンドによる読み取り／書き込みのブロック

• 影響を受けるバージョン：MongoDB 4.2 以前を実行するすべてのアーキテクチャ

• 修正済みバージョン：MongoDB 4.4 以降

MongoDB 4.2 以前で compact コマンドを実行してディスクの断片化を解消すると、その実行中はすべての読み取りおよび書き込み操作がブロックされます。この操作は中断できないため、復旧の唯一の手段はインスタンスの再起動となり、業務継続性に影響を与えます。

MongoDB 4.4 では、compact コマンドのロック動作が最適化され、CRUD 操作はブロックされなくなりました。一部の DDL 操作 — createIndex および dropIndex — のみが一時的に影響を受けます。compact の実行は、メンテナンスウィンドウ外でスケジュールしてください。

詳細については、「インスタンスのディスクのデフラグメント」および「ブロッキング コンパクト」をご参照ください。

compact コマンドによるノードの RECOVERING 状態への移行

• 影響を受けるバージョン：メジャーバージョンが MongoDB 4.2 以前であり、マイナーバージョンが 4.2.18 より前のすべてのアーキテクチャ

• 修正済みバージョン：MongoDB 4.4 以降

該当バージョンでは、compact コマンドを実行すると、mongos ノードが RECOVERING 状態に移行します。ノードがこの状態を長期間維持すると、ApsaraDB for MongoDB のアクティベーションコンポーネントがノードを異常と判断し、再構築をトリガーします。これにより、予期しないダウンタイムが発生します。

MongoDB 4.2.18 以降では、compact 実行後に mongos ノードが RECOVERING 状態に移行しなくなるため、ノードの利用不能および予期しない再構築フローが防止されます。

詳細については、「インスタンスのディスクをデフラグする」および「compact RECOVERING」をご参照ください。

非表示ノードにおける物理バックアップによる過剰なディスク領域消費

• 影響を受けるバージョン：MongoDB 4.2 以前を実行し、ローカルディスクを使用するすべてのアーキテクチャ

• 修正済みバージョン：MongoDB 5.0 以降（クラウドディスク）

ローカルディスクインスタンスにおける物理バックアップ機構では、バックアップのアップロード中にディスクファイルサイズが継続的に増加します。大規模な累積ファイルは大量のディスク領域を消費し、ノード障害やスイッチオーバー時に誤ったディスク使用率アラートを引き起こします。

クラウドディスクインスタンスでは、物理バックアップとディスクスナップショットを組み合わせることで、WiredTiger（WT）バックアップチェックポイントの維持に必要な時間が短縮され、非表示ノードにおけるディスク領域の肥大化が解消されます。2 TB を超えるデータを持つレプリカセットインスタンスでは、ローカルディスクの物理バックアップに伴う長時間のバックアップ、高い失敗率、および O&M 操作の競合を回避するために、スナップショットバックアップをご利用ください。

残留ルーティングデータによる同名データベース再作成時の障害

• 影響を受けるバージョン：MongoDB 4.4 以前を実行するシャードクラスターインスタンス

• 修正済みバージョン：MongoDB 5.0 以降

シャードクラスター内で dropDatabase を使用してデータベースを削除し、その後同名のデータベースを再作成すると、ConfigServer ノード内の残留ルーティングデータにより、読み取りおよび書き込み操作が失敗します。

MongoDB 4.2 以前では、dropDatabase を繰り返し実行した後、すべての mongos ノードで flushRouterConfig を実行してルーティングデータをフラッシュする必要があります。そうしないと、残留データがパフォーマンスを劣化させます。

MongoDB 5.0 では、dropDatabase のルーティングデータ処理が最適化され、ルーティングデータが自動的にクリアされるようになったため、この手動クリーンアップは不要になりました。

詳細については、「dropDatabase」および「flushRouterConfig」をご参照ください。

デフォルトの書き込み保証 {w:1} によるセカンダリノードでのデータ同期失敗

• 影響を受けるバージョン：MongoDB 5.0 より前のすべてのアーキテクチャ

• 修正済みバージョン：MongoDB 5.0 以降

デフォルトの書き込み保証 {w:1} を使用すると、プライマリノードへ高速に書き込まれたデータが、セカンダリノードへ完全に反映されない場合があり、結果としてセカンダリノードが RECOVERING 状態に移行します。これにより、インスタンスの可用性が低下し、読み書き分離ワークロードが破綻し、増分バックアップおよびポイントインタイムリカバリが実行できなくなります。

MongoDB 5.0 では、デフォルトの書き込み保証が {w:1} から {w:"majority"} へ変更されました。書き込みは、レプリカセットメンバーの過半数が確認した時点でクエリ可能になります。これにより、わずかなパフォーマンス低下を伴いながらもデータ信頼性が向上します。高スループットの書き込みワークロードで従来の動作を許容できる場合は、書き込み保証を {w:1} へ戻すことができます。

詳細については、「デフォルトの書き込み保証」および「setDefaultRWConcern」をご参照ください。

スケールアウトを支えるのに十分な速度でデータを再バランスできないバランサー

• 影響を受けるバージョン: すべてのアーキテクチャで、MongoDB 5.0 より前のバージョンを実行しているもの

• 修正済みバージョン：MongoDB 5.0 以降

バランサーは、スケールアウトイベント中にデータを再バランスするのに十分な速度でチャンクを移行できません。その結果、データがシャード間で不均等に分散されたままとなり、パフォーマンスが劣化します。

MongoDB 5.0 では、chunkMigrationConcurrency および balancerMigrationsThrottlingMs パラメーターが追加され、ワークロードに応じてバランサーの移行同時実行数およびスループットを調整できるようになりました。

詳細については、「chunkMigrationConcurrency」および「balancerMigrationsThrottlingMs」をご参照ください。

チャンク数に基づくバランス調整によるシャードクラスター内の負荷不均衡

• 影響を受けるバージョン：メジャーバージョンが MongoDB 5.0 以下かつマイナーバージョンが 6.0.3 より前のすべてのアーキテクチャ

• 修正済みバージョン：MongoDB 6.0 以降

バランサーは、データ量ではなくチャンク数に基づいてデータを分散します。ジャンボチャンクや空のチャンクが存在する場合、あるいは一部のデータに対してトラフィックが集中する場合、チャンク数は均等に見えるものの、シャード間で負荷が不均等になります。

MongoDB 6.0.3 では、バランサーがチャンク数ではなく、シャード間のデータ量の差に基づいてデータを分散するように変更されました。これにより、ジャンボチャンク、空のチャンク、ホットデータパターンに起因する負荷不均衡が解消されます。

詳細については、「MongoDB 6.0.3 におけるバランサーの変更点」をご参照ください。

その他のカーネル問題

以下は、ApsaraDB for MongoDB チームが特定した、以前の MongoDB バージョンにおけるその他のカーネル問題の一覧です。