ApsaraDB for MongoDB:概要

制限事項

• シャードクラスタインスタンスのアーキテクチャまたはストレージエンジンは変更できません。 たとえば、シャードクラスタインスタンスをレプリカセットインスタンスに変更することはできません。

• シャードクラスタインスタンスのノードに対する操作には、次の制限があります。

  操作	制限事項
  シャードノードの追加	新しいシャードノードの仕様は、シャードクラスタインスタンスのすべてのシャードノードの中で最も高い仕様以上である必要があります。 たとえば、シャードクラスターインスタンスの構成が最も高いシャードノードのストレージ容量が10 GBの場合、新しいシャードのストレージ容量は10 GB以上である必要があります。
  シャードノードの仕様を変更する	指定する新しいストレージ容量は、シャードノードの既存のストレージ容量以上である必要があります。 指定する新しい読み取り専用ノードの数は、シャードノード間の読み取り専用ノードの最大数以上である必要があります。 ダウングレードするサブスクリプションシャードクラスターインスタンスの読み取り専用ノードの数を増やすことはできません。
  ConfigServerノードの仕様を変更する	指定した新しいストレージ容量は、インスタンス内のConfigServerノードの既存のストレージ容量以上です。 ローカルディスクを使用するシャードクラスタインスタンスのConfigServerノードの設定は変更できません。
  複数のmongos、shard、およびConfigServerノードの設定をバッチで変更する	ノードの構成を変更するときは、特定のmongos、shard、およびConfigServerノードの制限に注意してください。 説明 ローカルディスクを使用するシャードクラスタインスタンスのConfigServerノードの設定は変更できません。 シャードノード内の読み取り専用ノードの数を変更するには、シャードノードの構成を変更する必要があります。
  mongosノードのリリース	mongosノードは、少なくとも3つのmongosノードを持つシャードクラスターインスタンスから削除できます。 説明 シャードクラスタインスタンスには、少なくとも2つのmongosノードを保持する必要があります。
  シャードノードのリリース	シャードノードは、少なくとも3つのシャードノードを持つクラスターインスタンスから削除できます。 説明 シャードクラスタインスタンスには、少なくとも2つのシャードノードを保持する必要があります。 シャードノードをリリースする前に、ApsaraDB for MongoDBバランサーが有効になっていることを確認してください。 詳細については、「ApsaraDB For MongoDB balancerの管理」をご参照ください。 ノードのリリースにかかる実際の時間には、シャードノードのデータ量、バランシングウィンドウ、ジャンボチャンクなどの要因が影響します。 説明 ウィンドウとジャンボチャンクのバランスの詳細については、「balancing windows」および「jumbo chunks」をご参照ください。 残りのシャードノードに十分なストレージスペースがあることを確認します。 シャードノードが解放されると、シャードノードのデータは残りのシャードノードに移行されます。 残りのシャードノードのストレージスペースがいっぱいになると、インスタンスは自動的にロックされ、データの損失を防ぎます。 シャードノードのデータが残りのシャードノードに移行されたときに重複キーエラーが報告された場合は、同じ一意のインデックスフィールド値を持つレコードが存在するかどうかを確認します。 例えば、異なるシャードノードは、異なるシャードキーを有するが同じ主キーを有する2つの文書を格納することができる。 説明 孤立したドキュメントがデータベースに存在する場合、重複キーエラーが返されます。 シャードノードをリリースする前に、孤立したドキュメントを削除することを推奨します。 詳細については、「ApsaraDB For MongoDBインスタンス間の一方向データ同期の設定 (シャードクラスターアーキテクチャ) 」トピックの「準備」セクションをご参照ください。

課金ルール

詳細については、「設定変更料金」をご参照ください。

使用上の注意

• 構成変更中に、1つまたは2つの切断が発生する可能性があります。 各切断は約30秒続きます。 構成の変更によってワークロードが中断されないようにするには、ビジネスへの影響が最小限になるように一度に構成を変更することをお勧めします。

  重要

  インスタンスのストレージ容量のみを変更すると、ホストに十分なストレージリソースがあるかどうかに基づいて、対応する操作が実行されます。

  • ホストに十分なストレージリソースがある場合、システムはホスト間の移行やフェイルオーバーを必要とせずに、ホスト上のストレージ容量をスケールアップします。 スケールアッププロセス中に切断は発生しません。 スケールアップタスクはすぐに実行されて完了します。 メンテナンス期間を待つ必要はありません。

  • ホストに十分なストレージリソースがない場合は、ホスト間の移行とフェイルオーバーが必要です。 切断は、スケールアッププロセス中に発生し得る。 スケールアップタスクは、指定されたメンテナンス期間中に実行されます。

• 構成変更を実行するのに必要な時間は、ネットワーク条件、タスクキューのステータス、データサイズなどの要因によって異なります。 オフピーク時にシャードクラスターインスタンスの設定を変更し、アプリケーションがインスタンスに自動的に再接続できることを確認することを推奨します。

• シャードクラスターインスタンスのマイナーバージョンの有効期限が切れるか、維持されなくなった場合、ApsaraDB for MongoDBは、設定変更中にインスタンスのマイナーバージョンを最新バージョンに自動的に更新します。 これにより、シャードクラスターインスタンスのパフォーマンスと安定性が向上します。

構成変更の概要