ApsaraDB for MongoDB:インスタンスを新しい MongoDB バージョンにアップグレードする必要がある理由

シャードクラスターインスタンスに孤立ドキュメントが存在するため、データ移行中にデータの不整合が発生する

• 影響を受けるバージョンとアーキテクチャ: MongoDB 4.2 以降を実行するシャードクラスターインスタンス。

• 説明: シャードクラスターインスタンス内の孤立ドキュメントをできるだけ早くクリーンアップしないと、データ移行中にデータの不整合が発生する可能性があります。

• 推奨バージョン: MongoDB 4.4 以降。

• 推奨理由:

  チャンクがソースシャードから新しいシャードに移行された後、ソースシャードのチャンクは削除されるまで一定期間保持されます。ほとんどの場合、孤立ドキュメントは移行の中断によって生成されます。孤立ドキュメントは mongos ノードへのリクエストには影響しません。これは、リクエストが ConfigServer ノードのルーティングデータによってチェックされるためです。

  MongoDB 4.4 以後は、自己回復チャンク移行と孤立ドキュメントの自動クリーンアップをサポートしています。ノードに障害が発生した場合、MongoDB は、中断された移行プロセスを自動的に回復します。孤立ドキュメントをクリーンアップするために cleanupOrphaned コマンドを実行する必要はありません。このコマンドを実行して、バックエンド スレッドがインスタンス内の孤立ドキュメントをクリーンアップしているかどうかを確認できます。

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

圧縮操作により、読み取りおよび書き込みリクエストがブロックされる

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

• 説明: ディスクを最適化する場合、以前のバージョンを実行しているインスタンスで圧縮操作を実行すると、読み取りおよび書き込みリクエストがブロックされます。この場合、操作を中断できないため、インスタンスを再起動するしかありません。これはビジネスに影響を与えます。

• 推奨バージョン: MongoDB 4.4 以降。

• 推奨理由:

  MongoDB 4.4 以降では、createIndex や dropIndex などの一部の DDL 操作を除き、読み取りおよび書き込み (CRUD) 操作がブロックされないように、compact コマンドのロック動作が最適化されています。指定されたメンテナンスウィンドウ外の期間に compact コマンドを実行できます。

  詳細については、「インスタンスのディスクを最適化してディスク使用率を向上させる」および「compact Blocking」をご参照ください。

  説明

  ディスクを最適化するには、ApsaraDB for MongoDB が提供するストレージ分析機能を使用することをお勧めします。この機能の詳細については、「ストレージ分析」をご参照ください。

圧縮操作により、ノードが RECOVERING 状態になる

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

• 説明: ディスクを最適化する場合、以前のバージョンを実行しているインスタンスで圧縮操作を実行すると、インスタンス内のノードが RECOVERING 状態になります。ノードがこの状態が長時間続くと、ApsaraDB for MongoDB のインスタンスアクティベーションコンポーネントによってノードが異常と見なされます。この場合、再構築操作がトリガーされます。

• 推奨バージョン: MongoDB 4.4 以降。

• 推奨理由:

  MongoDB 4.2.18 以降では、ノードで compact コマンドを実行した後、mongos ノードは RECOVERING 状態になりません。これにより、使用できない mongos ノードの存在と予期しない再構築タスクフローが防止されます。

  詳細については、「インスタンスのディスクを最適化してディスク使用率を向上させる」および「compact RECOVERING」をご参照ください。

  説明

  ディスクを最適化するには、ApsaraDB for MongoDB が提供するストレージ分析機能を使用することをお勧めします。この機能の詳細については、「ストレージ分析」をご参照ください。

非表示ノードの物理バックアップが大量のディスク容量を消費する

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

• 説明: 物理バックアップメカニズムにより、バックアップのアップロード中にディスクファイルのサイズが大きくなり続けます。大量のディスクファイルが蓄積されると、大量のディスク容量が消費されます。ノード障害またはスイッチオーバーが発生した場合、ディスク使用量に関連する誤ったアラートがトリガーされます。

• 推奨バージョン: MongoDB 5.0 以降 (クラウドディスク)。

• 推奨理由:

  クラウドディスクを使用するインスタンスのフルバックアップは、物理バックアップとディスクスナップショットを組み合わせたものです。フルバックアップは、WiredTiger (WT) でバックアップチェックポイントを維持するために必要な時間を短縮し、効率的な方法で非表示ノードのバックアップによるディスク容量の肥大化を解決します。

  クラウドディスクを使用するインスタンスが提供するスナップショットバックアップとスナップショットバックアップに基づくデータ復旧により、パフォーマンスが向上します。レプリカセットインスタンスのデータ量が 2 TB を超える場合は、スナップショットバックアップを使用してインスタンスのデータをバックアップすることをお勧めします。こうすることで、バックアップ中に発生しません。これらの問題には、ローカルディスクを使用するインスタンスに必要な長い物理バックアップ時間、高いバックアップ失敗率、その他の運用保守操作の実行の失敗などが含まれます。

削除されたデータベースと同じ名前のデータベースを再作成すると、シャードクラスターインスタンスにルーティングデータが存在する

• 影響を受けるバージョンとアーキテクチャ: MongoDB 4.4 以前を実行するシャードクラスターインスタンス。

• 説明: シャードクラスターインスタンスで dropDatabase コマンドを実行し、削除されたデータベースと同じ名前のデータベースを再作成すると、インスタンスの ConfigServer ノードにルーティングデータが存在するため、インスタンスの読み取りおよび書き込み操作を期待どおりに実行できません。

• 推奨バージョン: MongoDB 5.0 以降。

• 推奨理由:

  MongoDB 5.0 以降では、dropDatabase コマンドのルーティングデータ処理が最適化されています。このため、MongoDB 5.0 以降を実行しているシャードクラスターインスタンスには、ルーティングデータは存在しません。MongoDB 4.2 以前では、dropDatabase コマンドを繰り返し実行する必要があります。また、すべての Mongos ノードで flushRouterConfig コマンドを実行して、ルーティングデータをリフレッシュする必要があります。そうしないと、残留ルーティングデータによってデータベースのパフォーマンスが低下します。

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

{w:1} のデフォルトの writeConcern 設定により、プライマリノードとセカンダリノード間のデータ同期が異常になる

• 影響を受けるバージョンとアーキテクチャ: MongoDB 5.0 より前のバージョンを実行するすべてのアーキテクチャのインスタンス。

• 説明: データがインスタンスのプライマリノードにすばやく書き込まれると、インスタンス内のセカンダリノードはデータの一部のみを受信し、RECOVERING 状態になる可能性があります。これはインスタンスの可用性を低下させます。セカンダリノードは予期されるデータを読み取ることができず、読み取り/書き込み分離を必要とするビジネスに影響を与えます。この場合、増分バックアップを期待どおりに実行できません。また、データを以前の時点に復元できません。

• 推奨バージョン: MongoDB 5.0 以降。

• 推奨理由:

  MongoDB 5.0 以降、writeConcern のデフォルト値は {w:1} から {w:"majority"} に変更されました。これは、書き込まれるデータが、レプリカセットインスタンスのほとんどのノードによって確認された後にのみクエリできることを示します。 これにより、わずかなパフォーマンスの低下はありますが、データの信頼性が向上します。 また、セカンダリノードで受信したデータの一部と、プライマリノードでトリガーされたフロー制御が原因で、スロークエリの応答や ROLLBACK 状態のプライマリノードによって発生するデータ損失も解決されます。

  書き込みパフォーマンスの高いシナリオでは、writeConcern を {w:1} に設定できます。

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

バランサーはデータを低速で均等に分散し、スケーリングパフォーマンスが低く、ピーク時にスケールアウトアクティビティを実行できない

• 影響を受けるバージョンとアーキテクチャ: MongoDB 5.0 より前のバージョンを実行するすべてのアーキテクチャのインスタンス。

• 説明: バランサーはデータを高速に移行できません。その結果、スケールアウトアクティビティを必要とするシナリオでは、データを高速で均等に分散できません。これはデータベースのパフォーマンスを低下させます。

• 推奨バージョン: MongoDB 5.0 以降。

• 推奨理由:

  MongoDB 5.0 以降、バランサーの移行の同時実行性とパフォーマンスを調整するために、chunkMigrationConcurrency パラメーターと balancerMigrationsThrottlingMs パラメーターが追加されました。

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

  説明

  インスタンスが MongoDB 5.0 を実行していて、2 つのパラメータをサポートしていない場合は、インスタンスのマイナーバージョンを更新します。詳細については、「インスタンスのマイナーバージョンを更新する」をご参照ください。

データの不均衡により、シャードクラスターインスタンスの負荷が不均等に分散される

• 影響を受けるバージョンとアーキテクチャ: メジャーバージョンが MongoDB 5.0 以前、マイナーバージョンが MongoDB 6.0.3 より前のすべてのアーキテクチャのインスタンス。

• 説明: バランサーは、シャード間のチャンク数に基づいてデータが均等に分散されているかどうかをチェックします。ジャンボチャンクと空のチャンクが存在し、データの一部に頻繁にアクセスする場合、シャード間でデータと負荷の不均衡が発生します。

• 推奨バージョン: MongoDB 6.0 以降。

• 推奨理由:

  MongoDB 6.0.3 以降では、バランサーは、シャード間のチャンク数の差ではなく、シャード間のデータ量の差に基づいてデータを均等に分散します。これは、以前のバージョンでジャンボチャンクと空のチャンクが存在し、頻繁にアクセスされるデータが原因で発生するデータと負荷の不均衡を解決します。

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

その他のカーネルの問題