配置の設定を編集

項目一覧

Considerations

前提条件
手順

Cloud Manager は、 2024年8月30日でMongoDB 3.6と4.0のオートメーション、バックアップおよびモニタリングのサポートを終了します。 MongoDB の配置をアップグレードするか、Atlas に移行してください。

Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。: 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用するサービスアカウントを作成します。

MongoDB のバージョン、ストレージエンジン、ホストまたはシャードの数など、配置の構成とトポロジーを変更できます。最上位のシャーディングされたクラスターやレプリカセットから、シャーディングされたクラスター内のレプリカセットやレプリカセット内の個々のプロセスなど、配置のトポロジーのすべてのレベルで変更を加えることができます。スタンドアロンのプロセスを変更することもできます。

Considerations

クラスターまたはノードへの変更の適用

クラスター内の個々の MongoDB プロセスに構成の変更を加えた場合、クラスターへのその後の変更は子プロセスには適用されなくなります。

例

レプリカセットノードのジャーナリングをオフにし、その後レプリカセットのジャーナルコミット間隔を変更しても、変更はノードには適用されません。

MongoDB バージョン

Cloud Manager で使用できる MongoDB のバージョンを選択するには、「カスタム MongoDB ビルドの追加」を参照してください。

配置の MongoDB バージョンを変更する前に、考慮事項や互換性の問題について次のドキュメントを確認してください。
- MongoDB リリースノート
- ドライバーのドキュメント。
- MongoDB 互換性マトリクス
事前定義されたメンテナンスウィンドウ中にバージョンの変更を計画します。
本番環境を変更する前に、ステージング環境で MongoDB のバージョンを変更します。ステージング環境は、本番環境をミラーリングする必要があります。これにより、本番環境の配置のダウンタイムにつながる可能性のある互換性の問題を回避できます。
レプリカセットとシャーディングされたクラスターの手動アップグレードを実行する場合は、 MongoDB リリースノートに従ってください。

注意

ダウングレードの制限事項

MongoDB 配置をダウングレードすることはできません。

バージョン 5.0 から 4.4.0 より前のバージョン
バージョン 4.4 から 4.2.6 より前のバージョン

MongoDB のバージョンに関するバックアップに関する考慮事項

バックアップに関する考慮事項の詳細については、「バックアップに関する考慮事項」を参照してください。

"featureCompatibilityVersion" : 4.2を使用して MongoDB 4.2 にアップグレードする場合、Cloud Manager は、バックアップに MongoDB Enterprise を使用するために MongoDB, Inc. が付与する特別なライセンスに同意するよう促すモーダルを表示します。

ストレージエンジン

重要

MongoDB は MongoDB 4.2 700} で MMAPv 1ストレージエンジンのサポートを削除しました。配置の構成を編集してストレージエンジンをWiredTiger ストレージエンジンに変更すると、Cloud Manager は MongoDB プロセスを再起動します。

MongoDB 3.0以降へのまたはアップグレードを実行し、MongoDB storage engine を変更すると、Cloud Manager はシャットダウンし、MongoDB プロセスを再起動します。マルチメンバーのレプリカセットの場合、Cloud Manager は各メンバーのローリングの最初の同期を実行します。

Cloud Manager は、ホストに十分なディスク容量がある場合、あるストレージエンジンから別のストレージエンジンへの移行中にバックアップディレクトリを作成します。ディスク容量が十分でないと、バックアップは作成されません。 Cloud Manager は、移行が完了するとバックアップディレクトリを削除しません。以前のバックアップディレクトリは保持または削除できます。バックアップディレクトリはmongodのデータディレクトリにあります。

例

データディレクトリが/data/processの場合、バックアップは/data/process.bak.UNIQUENAMEになります。は、UNIQUENAME stringが生成するランダムなCloud Manager です。

スタンドアロンインスタンスまたはレプリカセットのストレージエンジンを変更する前に、オートメーションに MongoDBデータディレクトリの親ディレクトリへの書込み (write) アクセス権を付与する必要があります。エージェントは、ストレージエンジンを更新するときに、親ディレクトリ内のデータの一時的なバックアップを作成します。スタンドアロンインスタンスでのストレージエンジンの変更には、 /mongodumpと/mongorestoreを完全に実行するために十分なディスク領域が必要です。このディスク領域は、ストレージエンジンの構成変更後にインスタンスに復元されます。 Cloud Manager はバックアップディレクトリを削除しません。

コンフィギュレーションサーバー上のストレージエンジンは変更できません。ストレージエンジンと利用可能なオプションの詳細については、MongoDB マニュアルの「ストレージ」を参照してください。

修正されたプロパティ

配置が作成された後は、次の設定を変更することはできません。

database path
MongoDB プロセスが割り当てられているホスト名（ bind_ipまたはport ）

変更できる配置設定は次の通りです。

log path プロセスレベル
高度なオプション

配置トポロジー

子プロセスを含む配置のトポロジーのすべてのレベルで変更を行うことができます。

トポロジーまたはプロセスを変更するには、このチュートリアルまたはより具体的なチュートリアルのいずれかを使用します。

プロジェクトレベルの変更

配置に影響する一部の変更は、プロジェクトレベルで行われます。次の変更は、プロジェクト内のすべての MongoDB プロセスに影響します。これらの変更には、指定されたチュートリアルを使用します。

配置で TLSを有効にするには、「デプロイでTLS を有効にする」を参照してください。
配置の認証を有効にするには、「 Cloud Manager プロジェクトの認証の有効化」を参照してください。
配置用の MongoDB ユーザーとロールを追加または変更するには、「 MongoDB ユーザーの管理」を参照してください。

複数の変更

複数の変更を 1 つの配置に組み合わせることができます。

例

Review Changesボタンをクリックする前に、次のすべての変更を行うことができます。

MongoDB の最新の安定バージョンをカスタムビルドの追加に追加します。
配置の MongoDB プロセスに対してTLSを有効にします。
上記から MongoDB の最新の安定バージョンを実行する新しいシャーディングされたクラスターを追加します。

Review Changesをクリックすると、レビューにはすべての変更が 1 つの画面に表示され、配置前に確認できます。

強制再構成

レプリカセットとシャーディングされたクラスターのみ

MongoDB Agent は、 Force Reconfigureレプリケーション設定をYesに設定すると、レプリカセットに新しい構成を強制的に受け入れることができます。少数のノードが使用できる状態からレプリカセットを回復するには、再構成を強制します。

警告:レプリカセットの再構成を強制すると、コミットされた過半数の書込み (write) がロールバックされる可能性があります。

慎重に進む必要があります。この操作の潜在的な影響について質問がある場合は、 MongoDB サポートにお問い合わせください。

Tip

以下も参照してください。

MongoDB マニュアルの「使用できないノードを含むレプリカセットの再構成」。

シャードの削除

シャーディングされたクラスターのみ

シャードを削除すると、そのシャード内のシャーディングされていないデータベースはすべて、 movePrimaryコマンドを使用して残りのシャードに移動されます。

すべてのシャーディングされたコレクションは、シャード削除プロセス中もオンラインのままとなり、利用可能です。ただし、 movePrimary操作中にシャーディングされていないコレクションに送信される読み取りおよび書込み操作は、移行の失敗やデータの損失など、予期しない動作を引き起こす可能性があります。

シャードを削除する前に、シャーディングされていないコレクションを含むデータベースのプライマリシャードを移動することをお勧めします。

シャードの削除の詳細については、「既存のシャーディングされたクラスターからシャードを削除する」を参照してください。

複数のレプリカセットノードの削除

複数のレプリカセットメンバーを一度に削除または移行できますが、投票メンバーの過半数が残っている必要があります。さらに投票権のあるノードを削除する必要がある場合は、一度に 1 つずつ削除します。

例

例 1

4 ノードのレプリカセットがある。すべてのノードは投票権のあるノードです。削除できるノードは 1 つだけです。これにより、4 つの投票ノードのうち 3 つの過半数が保持されます。その後に残りの 3 ノードのレプリカセットから別のノードを削除できます。これにより、残りの投票ノードの過半数が保持されます。

例

例 2

4 ノードのレプリカセットがある。 3 つのノードは投票ノードであり、1 つのノードは非投票ノードです。投票権を持つノードと投票権のないノードを同時に削除できます。これにより、投票ノード 3 つのうち 2 つの過半数が保持されます。

投票について詳しくは、「レプリカセットの高可用性」と「レプリカセットの選挙」を参照してください。

前提条件

配置では、Cloud Manager と互換性のあるバージョンのオートメーションを実行している必要があります。配置で互換性のあるバージョンのエージェントを実行していない場合、Cloud Manager はエージェントを更新するよう促すバナーを表示します。

手順

編集する配置のタイプを選択します。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。

配置アイテムをリストする行で、Modify をクリックします。

スタンドアロン設定を変更します。

Standalone Settingsセクションには、次の構成設定が含まれています。

設定	説明
Hostname	Cloud Manager が`mongod`を配置するホスト名。このホスト名は、ホスト名、 FQDN 、 IPv 4アドレス、またはIPv 6アドレスにすることができます。 Cloud Manager のオートメーションの下のホストにのみ配置できます。 Cloud Manager のオートメーションへのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。
Port	プロセスの `mongod`IANA ポート番号を指定します。この設定は、 `net.port`構成ファイルオプションに対応します。デフォルトは`27017`です。 `mongod`は指定されたポートへの排他的アクセス権を持つ必要があります。複数の`mongod`プロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。
Version	`mongod`プロセスの MongoDB サーバーのバージョンを選択します。 Version `mongod`プロセスの MongoDB サーバーのバージョンを選択します。
Auth Schema Version	配置のユーザーデータを保存するには、ユーザーを保存するためのスキーマを選択します。 3.0より古いバージョンの MongoDB からアップグレードする場合、 MongoDB 3.0 + は、ユーザーデータに以前のバージョンとは異なるスキーマを使用します。互換性情報については、MongoDB 3.0リリースノートの「セキュリティの変更」を参照してください。
Feature Compatibility Version	配置の機能の互換性バージョンを選択します。配置で MongoDB バージョン3.4以降を実行している場合、Cloud Manager はこのフィールドを表示します。
Log File	ログファイル名と拡張子を含む、 `mongod`ログファイルへの完全パスを指定します。この設定は、 `systemLog.path`構成ファイルオプションに対応します。 `mongod`には、指定されたファイルへの読み取りと書込みの権限が必要です。たとえば、`/var/log/mongodb/mongo.log` `mongod`を指定すると、`/var/log/mongodb/` はとして`mongo.log` にログファイルを保存するように指示します。 `mongod`には独自のログファイルが必要です。複数の`mongod`プロセスを同じホストに配置する場合は、各`mongod`に独自のログファイルがあることを確認してください。

詳細構成オプションを変更します。

Advanced Configuration Optionsセクションでは、配置内の各 MongoDB プロセスの MongoDBランタイムオプションを設定できます。

オプションを追加するには

[Add Option] をクリックします。
Select a Startup Optionをクリックし、構成オプションを選択します。
Cloud Manager は、選択したオプションに許容値を設定するためのコンテキストを区別する入力を表示します。
選択したオプションとそれに対応する値をプロセスに追加するには、 Addをクリックします。

使用可能なAdvanced Configuration Optionsの説明については、「 MongoDB デプロイの詳細オプション」を参照してください。

[Save] をクリックします。

Cloud Manager はDeploymentページにリダイレクトします。更新された構成を配置する前に、変更を確認する必要があります。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。

そうでない場合は、 Cancelをクリックすると、追加の変更を行うことができます。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。

配置アイテムをリストする行で、Modify をクリックします。

クラスター全体の設定を変更します。

Replica Set Configurationセクションには、次のクラスター全体の構成設定が含まれています。

設定	説明
Auth Schema Version	配置のユーザーデータを保存するには、ユーザーを保存するためのスキーマを選択します。 3.0より古いバージョンの MongoDB からアップグレードする場合、 MongoDB 3.0 + は、ユーザーデータに以前のバージョンとは異なるスキーマを使用します。互換性情報については、MongoDB 3.0リリースノートの「セキュリティの変更」を参照してください。
Feature Compatibility Version	配置の機能の互換性バージョンを選択します。配置で MongoDB バージョン3.4以降を実行している場合、Cloud Manager はこのフィールドを表示します。
Replica Set Settings	レプリカセットに関連付けられている各プロセスの表を表示します。各プロセスの MongoDB サーバーのバージョン、データディレクトリ、およびログパスを構成できます。
Process Name	`mongod`プロセスのホスト名とポート。このホスト名は、ホスト名、 FQDN 、 IPv 4アドレス、またはIPv 6アドレスにすることができます。 Cloud Manager は最初に、各プロセスをレプリカセット名の下にグループ化します。をクリックしますレプリカセット名の左側にあるをオンにすると、レプリカセット内のすべての`mongod`プロセスが表示されます。 Cloud Manager は、レプリカセット用に構成された設定を、関連するすべてのプロセスに適用します。
Version	`mongod`プロセスの MongoDB サーバーのバージョンを選択します。 Version `mongod`プロセスの MongoDB サーバーのバージョンを選択します。
Log File	ログファイル名と拡張子を含む、 `mongod`ログファイルへの完全パスを指定します。この設定は、 `systemLog.path`構成ファイルオプションに対応します。 `mongod`には、指定されたファイルへの読み取りと書込みの権限が必要です。たとえば、`/var/log/mongodb/mongo.log` `mongod`を指定すると、`/var/log/mongodb/` はとして`mongo.log` にログファイルを保存するように指示します。 `mongod`には独自のログファイルが必要です。複数の`mongod`プロセスを同じホストに配置する場合は、各`mongod`に独自のログファイルがあることを確認してください。

各レプリカセットノードを構成します。

Cloud Manager では、 Member ConfigurationセクションのMongoD Settings見出しの下に各レプリカセットノードが一覧表示されます。各レプリカセットノードには、次の構成可能なオプションがあります。

設定	説明
Member	メニューから次のいずれかのレプリカセットノードロールを選択します。 `Default` 選挙でプライマリおよび投票することができるレプリカセットのデータを保持するノード。アービタ選挙で投票できるレプリカセットの非データを保持するノード。 `arbiterOnly`レプリカ構成オプションに対応します。 hidden 選挙での投票ができるレプリカセットのデータを保持するノード。 `hidden`レプリカ構成オプションに対応します。遅延非表示選挙での投票ができるレプリカセットのデータを保持するノード。 `secondaryDelaySecs`と`hidden`のレプリカ構成オプションに対応します。
Hostname	メニューから、Cloud Manager Automation がレプリカセットノードを配置するホストを選択します。メニューには、Cloud Manager Automation の下のホストのみが一覧表示されます。 Cloud Manager Automation へのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。このホスト名は、ホスト名、 FQDN 、 IPv4アドレス、またはIPv6アドレスにすることができます。
Port	プロセスの `mongod`IANA ポート番号を指定します。この設定は、 `net.port`構成ファイルオプションに対応します。デフォルトは`27017`です。 `mongod`は指定されたポートへの排他的アクセス権を持つ必要があります。複数の`mongod`プロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。
Votes	選挙中にレプリカセットが持つ投票数を指定します。この設定は、 `votes` `mongod`レプリカセット構成オプションに対応します。
Priority	選挙中にノードの優先順位を指定します。優先順位が `0` のレプリカセットノードはプライマリになることができず、選挙をtriggerできません。この設定は、 `priority` `mongod`レプリカセット構成オプションに対応します。
Delay	このノードがプライマリノードより "遅れる" 秒数を指定します。この設定は、 `secondaryDelaySecs` `mongod`レプリカセット構成オプションに対応します。
Build Indexes	`truemongod`インデックスを構築するように指示するには、を指定します。この設定は、 `buildIndexes` `mongod`レプリカセット構成オプションに対応します。
Tags	レプリカセットに関連付けられたタグを指定します。この設定は、 `tags` `mongod`レプリカセット構成オプションに対応します。レプリカセットタグに関する詳細なドキュメントについては、「レプリカセットタグ」を参照してください。
Add a Mongod	追加の`mongod`プロセスをレプリカセットノードとして追加します。新しい`mongod`プロセスを追加すると、 Replica Set Configurationセクションのプロセスのリストもアップデートされます。新しいプロセスのVersion 、 Data Directory 、 Log Fileを構成する必要があります。

レプリケーション設定を構成します。

Replication Settingsセクションには、レプリカセットの次の構成オプションがあります。

設定	説明
Protocol Version	レプリカセットで使用されるレプリケーションプロトコルのバージョンを選択します。この設定は、 `protocolVersion`レプリカセット構成オプションに対応します。詳細については、「レプリカセットのプロトコルバージョン」を参照してください。
Chaining Allowed	セカンダリメンバーが他のセカンダリメンバーから複製できるようにするには、 `true`を指定します。この設定は、 `chainingAllowed`レプリカセット構成オプションに対応します。
Write Concern Majority Journal Default	`{w:"majority"}`書込み保証 (write concern) でジャーナルオプションが明示的に指定されていない場合の書込み保証 (write concern)`j` の動作を決定します。この設定は、 `writeConcernMajorityJournalDefault`レプリカセット構成オプションに対応します。
Heartbeat Timeout (secs)	レプリカセットがお互いのハートビートが成功するまで待つ秒数を指定します。この設定は、 `heartbeatTimeoutSecs`レプリカセット構成オプションに対応します。
Election Timeout (ms)	レプリカセットのプライマリが到達不能なときを検出するための時間制限をミリ秒単位で指定します。この設定は、 `electionTimeoutMillis`レプリカセット構成オプションに対応します。
CatchUp Timeout (ms)	新たに選出されたプライマリが、より新しい書込み (write) を行った可能性のある他のレプリカセットと同期するか、または追いつくまでの時間制限をミリ秒単位で指定します。この設定は、 `catchUpTimeoutMillis`レプリカセット構成オプションに対応します。
CatchUp Takeover Delay (ms)	ノードが現在のプライマリよりも進んでいると判断した後、キャッチアップ引き継ぎの開始を待つ時間をミリ秒単位で指定します。この設定は、 `catchUpTakeoverDelayMillis`レプリカセット構成オプションに対応します。
Last Error Defaults	レプリカセットのデフォルトの書込み保証 ( write concern ) を指定します。レプリカセットは、書込み (write) 操作またはgetLastErrorが他の書込み保証 (write concern) を指定していない場合にのみ、この書込み保証 (write concern) を使用します。このオプションが設定されていない場合、レプリカセットのデフォルトの書込み保証 (write concern) はプライマリからの確認のみを必要とします。このオプションはドキュメント形式（ `{"w":2}` ）で指定します。
Force Reconfigure	レプリカセットの再構成を強制することを指定します。 `Yes`に設定すると、MongoDB Agent は、ノードの大部分が利用できない場合でも、レプリカセットに新しい構成を強制的に受け入れます。警告:レプリカセットの再構成を強制すると、コミットされた過半数の書込み (write) がロールバックされる可能性があります。慎重に進む必要があります。この操作の潜在的な影響について質問がある場合は、 MongoDB サポートにお問い合わせください。詳細については、MongoDB Server マニュアルの「使用できないノードを含むレプリカセットの再構成」を参照してください。

詳細構成オプションを変更します。

[Save] をクリックします。

Cloud Manager は配置ページにリダイレクトします。更新された構成を配置する前に、変更を確認する必要があります。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。

そうでない場合は、 Cancelをクリックすると、追加の変更を行うことができます。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。

配置アイテムをリストする行で、Modify をクリックします。

クラスター全体の設定を構成します。

Cluster Configurationセクションには、次のクラスター全体の構成設定が含まれています。

設定	説明
Shard Name Prefix	クラスター内の各シャードのプレフィックスを指定します。 Cloud Manager は`<prefix_n>`形式を使用してクラスター内の各シャードに名前を付けます。 `n`は0インデックス付きの単調に増加する整数です。
Auth Schema Version	配置のユーザーデータを保存するには、ユーザーを保存するためのスキーマを選択します。 3.0より古いバージョンの MongoDB からアップグレードする場合、 MongoDB 3.0 + は、ユーザーデータに以前のバージョンとは異なるスキーマを使用します。互換性情報については、MongoDB 3.0リリースノートの「セキュリティの変更」を参照してください。
Feature Compatibility Version	配置の機能の互換性バージョンを選択します。配置で MongoDB バージョン3.4以降を実行している場合、Cloud Manager はこのフィールドを表示します。
Process Name	シャーディングされたクラスターに関連付けられている`mongod`または`mongos`のホスト名とポート。このホスト名は、ホスト名、 FQDN 、 IPv 4アドレス、またはIPv 6アドレスにすることができます。 Cloud Manager は、親レプリカセット名の下に`mongod`プロセスをグループ化し、 mongosesの下には`mongos`プロセスをグループ化します。次に、Cloud Manager はすべてのクラスターコンポーネントをクラスター名の下にグループ化します。をクリックしますグループの左側にあるでは、そのサブグループまたはプロセスが一覧表示されます。グループで利用可能な設定のいずれかを変更すると、そのグループのサブグループとプロセス内の対応する値が変更されます。 MongoDB 3.0またはそれ以前を実行しているクラスターの場合、Cloud Manager はコンフィギュレーションサーバー`mongod`プロセスをconfigServersの下にグループ化します。
Version	`mongod`または`mongos`プロセスの MongoDB サーバーのバージョンを選択します。 Version `mongod`または`mongos`プロセスの MongoDB サーバーのバージョンを選択します。
Log File	ログファイル名と拡張子を含む、 `mongod`または`mongos`ログファイルへの完全パスを指定します。この設定は、 `systemLog.path`構成ファイルオプションに対応します。 `mongod`または`mongos`には、指定されたファイルへの読み取りと書込みの権限が必要です。 `/var/log/mongodb/mongo.logmongodmongos`たとえば、`/var/log/mongodb/` を指定すると、またははとして`mongo.log` にログファイルを保存するように指示します。 `mongod`または`mongos`には独自のログファイルが必要です。複数の`mongod`または`mongos`プロセスを同じホストに配置する場合は、各`mongod`または`mongos`に独自のログファイルがあることを確認してください。

クラスター内の各シャードを構成します。

[ Member Configurationセクションから、 Shard Settingsをクリックしてシャード構成オプションを開きます。 Cloud Manager には、クラスター内の各シャードと、そのシャードに関連付けられているmongodプロセスが一覧表示されます。各シャードプロセスには、次のオプションがあります。次のオプションはグレー表示されているオプションは変更できません。

設定	説明
Member	メニューから次のいずれかのレプリカセットノードロールを選択します。 `Default` 選挙でプライマリおよび投票することができるレプリカセットのデータを保持するノード。アービタ選挙で投票できるレプリカセットの非データを保持するノード。 `arbiterOnly`レプリカ構成オプションに対応します。 hidden 選挙での投票ができるレプリカセットのデータを保持するノード。 `hidden`レプリカ構成オプションに対応します。遅延非表示選挙での投票ができるレプリカセットのデータを保持するノード。 `secondaryDelaySecs`と`hidden`のレプリカ構成オプションに対応します。
Hostname	メニューから、Cloud Manager Automation がレプリカセットノードを配置するホストを選択します。メニューには、Cloud Manager Automation の下のホストのみが一覧表示されます。 Cloud Manager Automation へのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。このホスト名は、ホスト名、 FQDN 、 IPv4アドレス、またはIPv6アドレスにすることができます。
Port	プロセスの `mongod`IANA ポート番号を指定します。この設定は、 `net.port`構成ファイルオプションに対応します。デフォルトは`27017`です。 `mongod`は指定されたポートへの排他的アクセス権を持つ必要があります。複数の`mongod`プロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。
Votes	選挙中にレプリカセットが持つ投票数を指定します。この設定は、 `votes` `mongod`レプリカセット構成オプションに対応します。
Priority	選挙中にノードの優先順位を指定します。優先順位が `0` のレプリカセットノードはプライマリになることができず、選挙をtriggerできません。この設定は、 `priority` `mongod`レプリカセット構成オプションに対応します。
Delay	このノードがプライマリノードより "遅れる" 秒数を指定します。この設定は、 `secondaryDelaySecs` `mongod`レプリカセット構成オプションに対応します。
Build Indexes	`truemongod`インデックスを構築するように指示するには、を指定します。この設定は、 `buildIndexes` `mongod`レプリカセット構成オプションに対応します。
Tags	レプリカセットに関連付けられたタグを指定します。この設定は、 `tags` `mongod`レプリカセット構成オプションに対応します。レプリカセットタグに関する詳細なドキュメントについては、「レプリカセットタグ」を参照してください。
Add a Mongod	追加の`mongod`プロセスをレプリカセットノードとして追加します。新しい`mongod`プロセスを追加すると、 Replica Set Configurationセクションのプロセスのリストもアップデートされます。新しいプロセスのVersion 、 Data Directory 、 Log Fileを構成する必要があります。

クラスターに追加のシャードを追加するには:

[Add a Shard] をクリックします。
Cluster Configurationセクションで、シャード内の各mongodに対して次のパラメータを設定します。
- Version
- Data Directory
- Log File

クラスター内の各構成サーバーを構成します。

クラスター内の各`mongos` を構成します。

Member Configurationセクションから、 Mongos Settingsをクリックしてmongos構成オプションを開きます。各mongosプロセスには次のオプションがあります。次のオプションはグレー表示されているオプションは変更できません。

設定	説明
Hostname	Cloud Manager Automation が`mongos`を配置するホストをメニューから選択します。メニューには、Cloud Manager Automation の下のホストのみが一覧表示されます。 Cloud Manager Automation へのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。このホスト名は、ホスト名、 FQDN 、 IPv4アドレス、またはIPv6アドレスにすることができます。
Port	プロセスの `mongos`IANA ポート番号を指定します。この設定は、 `net.port`構成ファイルオプションに対応します。デフォルトは`27017`です。 `mongos`は指定されたポートへの排他的アクセス権を持つ必要があります。複数の`mongos`プロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。
Add a Mongos	をクリックして、追加の`mongos`プロセスを追加します。

クラスター内の各レプリカセットを構成します。

詳細構成オプションを変更します。

[Save] をクリックします。

Cloud Manager は配置ページにリダイレクトします。更新された構成を配置する前に、変更を確認する必要があります。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。

そうでない場合は、 Cancelをクリックすると、追加の変更を行うことができます。

戻る

メンテナンスに準備する

BI Connector の管理

Considerations

クラスターまたはノードへの変更の適用

例

MongoDB バージョン

注意

ダウングレードの制限事項

MongoDB のバージョンに関するバックアップに関する考慮事項

ストレージ エンジン

重要

例

修正されたプロパティ

配置トポロジー

プロジェクトレベルの変更

複数の変更

例

強制再構成

Tip

以下も参照してください。

シャードの削除

複数のレプリカセット ノードの削除

例

例 1

例

例 2

前提条件

手順

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。

配置アイテムをリストする行で、Modify をクリックします。

スタンドアロン設定を変更します。

詳細構成オプションを変更します。

[Save] をクリックします。

Review & Deploy変更内容を確認するには、 をクリックします。

Confirm & Deploy変更を配置するには、 をクリックします。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。

配置アイテムをリストする行で、Modify をクリックします。

クラスター全体の設定を変更します。

各レプリカセット ノードを構成します。

レプリケーション設定を構成します。

詳細構成オプションを変更します。

[Save] をクリックします。

Review & Deploy変更内容を確認するには、 をクリックします。

Confirm & Deploy変更を配置するには、 をクリックします。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。

配置アイテムをリストする行で、Modify をクリックします。

クラスター全体の設定を構成します。

クラスター内の各シャードを構成します。

クラスター内の各構成サーバーを構成します。

クラスター内の各mongos を構成します。

クラスター内の各レプリカセットを構成します。

詳細構成オプションを変更します。

[Save] をクリックします。

Review & Deploy変更内容を確認するには、 をクリックします。

Confirm & Deploy変更を配置するには、 をクリックします。

ストレージエンジン

複数のレプリカセットノードの削除

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

各レプリカセットノードを構成します。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトのページにGoします。

クラスター内の各`mongos` を構成します。

Review & Deploy変更内容を確認するには、をクリックします。

Confirm & Deploy変更を配置するには、をクリックします。