配置の設定を編集

項目一覧

Considerations

前提条件
手順

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

Considerations

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

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

例

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

MongoDB バージョン

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

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

注意

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

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

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

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

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

ストレージエンジン

重要

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

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

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

例

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

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

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

修正されたプロパティ

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

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

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

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

配置トポロジー

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

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

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

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

配置で TLSを有効にするには、「デプロイでTLS を有効にする」を参照してください。
配置の認証を有効にするには、「 MongoDB Ops 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 つの過半数が保持されます。

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

警告

MongoDB 5.0から6.0にアップグレードします

シャーディングされたクラスターを MongoDB 5.0から6.0にアップグレードする場合は、MongoDB マニュアルの「シャーディングされたクラスターを6.0にアップグレードする」ページの手順を使用して、各mongosのキャッシュされたルーティングテーブルを更新する必要があります。

すべての変更はクラスター全体で

レプリカセットまたはシャーディングされたクラスターの個々のノードには変更できず、セットまたはクラスター全体に対してのみ変更できます。

Kubernetes Operator による一部のMongoDB Ops Manager設定の上書き

Kubernetes Operator を使用して構成した一部の設定は、 MongoDB Ops Managerアプリケーションでは上書きできません。これらの設定のいずれかを変更すると、リソース仕様を適用するたびに Kubernetes Operator は設定を元に戻します。 Kubernetes Operator が管理しない設定は受け入れられます。

次の設定リストは Kubernetes 専用です。このリストは後で変更される可能性があります。

これらの設定は、[ Automation Configuration （オートメーション構成） ] ページで確認できます。

processes.args2_6.net.port
processes.args2_6.replication.replSetName
processes.args2_6.storage.dbPath
processes.args2_6.systemLog.path
processes.authSchemaVersion
processes.cluster （mongos プロセス）
processes.featureCompatibilityVersion
processes.hostname
processes.name
processes.version
replicaSets._id
replicaSets.members._id
replicaSets.members.host
replicaSets.members
replicaSets.version
sharding.clusterRole (config server)
sharding.configServerReplica
sharding.name
sharding.shards._id
sharding.shards.rs

例

Kubernetes Operator は 3 つのノードのレプリカセットを作成します。
storage.wiredTiger.engineConfig.cacheSizeGBを40に変更しました。
次に、レプリカセットを5メンバーにスケーリングします。
新しいノードのstorage.wiredTiger.engineConfig.cacheSizeGBは40である必要があります。

Kubernetes で使用できない変更

MongoDB Kubernetesリソースで設定が使用できない場合は、 MongoDB Ops Managerアプリケーションで変更を行う必要があります。

前提条件

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

スタンドアロンプロセスでストレージエンジンの変更を行う前に、バックアップを実行するために親ディレクトリに十分なディスク領域が必要です。変更を順次適用するスタンドアロンプロセスではなく、レプリカセットを使用することをお勧めします。

MongoDB Kubernetes オブジェクトを更新するには、 [ Kubernetes Operator のインストール ]ページの前提条件を満たし、手順を完了する必要があります。

手順

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

Deploymentプロジェクトのページに移動します。

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

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

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

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

設定	説明
Hostname	MongoDB Ops Manager が`mongod`を配置するホスト名。このホスト名は、ホスト名、 FQDN 、 IPv 4アドレス、またはIPv 6アドレスにすることができます。 MongoDB Ops Managerのオートメーションの下のホストにのみ配置できます。 MongoDB Ops Managerのオートメーションへのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。
Port	プロセスの `mongod`IANA ポート番号を指定します。この設定は、 `net.port`構成ファイルオプションに対応します。デフォルトは`27017`です。 `mongod`は指定されたポートへの排他的アクセス権を持つ必要があります。複数の`mongod`プロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。
Version	`mongod`プロセスの MongoDB サーバーのバージョンを選択します。 MongoDB Ops Manager には、配置で使用可能な MongoDB バージョンのみが一覧表示されます。このフィルタリングを無効にするには、 `automation.versions.download.baseUrl.allowOnlyAvailableBuilds`を参照してください。
Auth Schema Version	配置のユーザーデータを保存するには、ユーザーを保存するためのスキーマを選択します。 3.0より古いバージョンの MongoDB からアップグレードする場合、 MongoDB 3.0 + は、ユーザーデータに以前のバージョンとは異なるスキーマを使用します。互換性情報については、MongoDB 3.0リリースノートの「セキュリティの変更」を参照してください。
Feature Compatibility Version	配置の機能の互換性バージョンを選択します。配置で MongoDB バージョン3.4以降を実行している場合、MongoDB Ops 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をクリックし、構成オプションを選択します。
MongoDB Ops Manager は、選択したオプションに許容値を設定するためのコンテキストを区別する入力を表示します。
選択したオプションとそれに対応する値をプロセスに追加するには、 Addをクリックします。

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

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

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

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

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

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

Deploymentプロジェクトのページに移動します。

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

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

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

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

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

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

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

設定	説明
Member	メニューから次のいずれかのレプリカセットノードロールを選択します。 `Default` 選挙でプライマリおよび投票することができるレプリカセットのデータを保持するノード。アービタ選挙で投票できるレプリカセットの非データを保持するノード。 `arbiterOnly`レプリカ構成オプションに対応します。 hidden 選挙での投票ができるレプリカセットのデータを保持するノード。 `hidden`レプリカ構成オプションに対応します。遅延非表示選挙での投票ができるレプリカセットのデータを保持するノード。 `secondaryDelaySecs`と`hidden`のレプリカ構成オプションに対応します。
Hostname	MongoDB Ops Manager Automation がレプリカセットノードを配置するホストをメニューから選択します。メニューには、 MongoDB Ops Manager Automation の下のホストのみが一覧表示されます。 MongoDB Ops 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 マニュアルの「使用できないノードを含むレプリカセットの再構成」を参照してください。

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

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

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

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

MongoDB Ops Managerは、クラスター内の各プロセスを論理的にグループ化して一覧表示します。論理グループの左側にある灰色の矢印をクリックすると、そのサブグループとプロセスが表示されます。必要に応じて、各プロセスの詳細オプションを個別に変更できます。

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

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

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

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

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

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

レプリカセットを強制的に再構成しようとすると、 MongoDB Ops Managerに次のメッセージが表示されます。

クリックして拡大します

Confirm & Deployをクリックする前に、レプリカセットを強制的に再構成することのリスクを理解していることを確認してください。

Tip

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

MongoDB マニュアルで、使用できないメンバーを含むレプリカセットを再構成する...

Deploymentプロジェクトのページに移動します。

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

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

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

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

設定	説明
Shard Name Prefix	クラスター内の各シャードのプレフィックスを指定します。 MongoDB Ops Manager は`<prefix_n>`形式を使用してクラスター内の各シャードに名前を付けます。 `n`は0インデックス付きの単調に増加する整数です。
Auth Schema Version	配置のユーザーデータを保存するには、ユーザーを保存するためのスキーマを選択します。 3.0より古いバージョンの MongoDB からアップグレードする場合、 MongoDB 3.0 + は、ユーザーデータに以前のバージョンとは異なるスキーマを使用します。互換性情報については、MongoDB 3.0リリースノートの「セキュリティの変更」を参照してください。
Feature Compatibility Version	配置の機能の互換性バージョンを選択します。配置で MongoDB バージョン3.4以降を実行している場合、MongoDB Ops Manager はこのフィールドを表示します。
Process Name	シャーディングされたクラスターに関連付けられている`mongod`または`mongos`のホスト名とポート。このホスト名は、ホスト名、 FQDN 、 IPv 4アドレス、またはIPv 6アドレスにすることができます。 MongoDB Ops Managerは、親レプリカセット名の下に`mongod`プロセスをグループ化し、mongoses の下には`mongos`プロセスをグループ化します。次に、 MongoDB Ops Managerはすべてのクラスターコンポーネントをクラスター名の下にグループ化します。をクリックしますグループの左側にあるでは、そのサブグループまたはプロセスが一覧表示されます。グループで利用可能な設定のいずれかを変更すると、そのグループのサブグループとプロセス内の対応する値が変更されます。 MongoDB 3.0 またはそれ以前のバージョンを実行しているクラスターの場合、 MongoDB Ops Managerはコンフィギュレーションサーバー`mongod`プロセスを configServers の下にグループ化します。
Version	`mongod`または`mongos`プロセスの MongoDB サーバーのバージョンを選択します。 MongoDB Ops Manager には、配置で使用可能な MongoDB バージョンのみが一覧表示されます。このフィルタリングを無効にするには、 `automation.versions.download.baseUrl.allowOnlyAvailableBuilds`を参照してください。
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をクリックしてシャード構成オプションを開きます。 MongoDB Ops Managerには、クラスター内の各シャードと、そのシャードに関連付けられているmongodプロセスが一覧表示されます。各シャードプロセスには、次のオプションがあります。次のオプションはグレー表示されているオプションは変更できません。

設定	説明
Member	メニューから次のいずれかのレプリカセットノードロールを選択します。 `Default` 選挙でプライマリおよび投票することができるレプリカセットのデータを保持するノード。アービタ選挙で投票できるレプリカセットの非データを保持するノード。 `arbiterOnly`レプリカ構成オプションに対応します。 hidden 選挙での投票ができるレプリカセットのデータを保持するノード。 `hidden`レプリカ構成オプションに対応します。遅延非表示選挙での投票ができるレプリカセットのデータを保持するノード。 `secondaryDelaySecs`と`hidden`のレプリカ構成オプションに対応します。
Hostname	MongoDB Ops Manager Automation がレプリカセットノードを配置するホストをメニューから選択します。メニューには、 MongoDB Ops Manager Automation の下のホストのみが一覧表示されます。 MongoDB Ops 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

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

ドロップダウンメニューで、 DedicatedとEmbeddedのいずれかの構成サーバータイプを選択します。 3を超えるシャードのクラスターはDedicatedタイプを使用する必要があります。

MongoDB Ops Managerでは、構成サーバーに選択したMongoDBのバージョンに応じて、構成サーバー設定に異なる見出しが表示されます。

MongoDB 3.2以降:

Member Configurationセクションから、 Config Server Replica Set Settingsをクリックして CSRS 構成オプションを開きます。各コンフィギュレーションサーバーのレプリカセットノードには、次のオプションがあります。

設定	説明
Member	メニューから次のいずれかのレプリカセットノードロールを選択します。 `Default` 選挙でプライマリおよび投票することができるレプリカセットのデータを保持するノード。アービタ選挙で投票できるレプリカセットの非データを保持するノード。 `arbiterOnly`レプリカ構成オプションに対応します。 hidden 選挙での投票ができるレプリカセットのデータを保持するノード。 `hidden`レプリカ構成オプションに対応します。遅延非表示選挙での投票ができるレプリカセットのデータを保持するノード。 `secondaryDelaySecs`と`hidden`のレプリカ構成オプションに対応します。
Hostname	MongoDB Ops Manager Automation がレプリカセットノードを配置するホストをメニューから選択します。メニューには、 MongoDB Ops Manager Automation の下のホストのみが一覧表示されます。 MongoDB Ops 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`プロセスを追加すると、 Cluster Configurationセクションのプロセスのリストもアップデートされます。新しいプロセスのVersion 、 Data Directory 、 Log Fileを構成する必要があります。

MongoDB 3.0またはそれ以前

Member ConfigurationセクションからConfig Server Settingsをクリックして、構成サーバーオプションを開きます。各構成サーバーには、次のオプションがあります。

設定

説明

Hostname

MongoDB Ops Manager Automation がレプリカセットノードを配置するホストをメニューから選択します。メニューには、 MongoDB Ops Manager Automation の下のホストのみが一覧表示されます。 MongoDB Ops Manager Automation へのサーバーの追加に関する詳細なドキュメントについては、「オートメーション用のサーバーのプロビジョニング」を参照してください。

このホスト名は、ホスト名、 FQDN 、 IPv4アドレス、またはIPv6アドレスにすることができます。

Port

プロセスの mongodIANA ポート番号を指定します。この設定は、 net.port構成ファイルオプションに対応します。デフォルトは27017です。

mongodは指定されたポートへの排他的アクセス権を持つ必要があります。複数のmongodプロセスを単一のホストに配置する場合は、プロセスごとに一意の未使用ポートを選択する必要があります。

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

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

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

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

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 マニュアルの「使用できないノードを含むレプリカセットの再構成」を参照してください。

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

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

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

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

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

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

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

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

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

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

Kubernetes リソース仕様ファイルを編集します。
追加または変更する必要がある設定を変更または追加します。
仕様ファイルを保存します。
次の Kubernetes コマンドを呼び出して、リソースを更新します。
```
kubectl apply -f <standalone-conf>.yaml
```

戻る

クラスターのメンテナンスに準備する

でのの管理BI ConnectorMongoDB Ops Manager

Considerations

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

例

MongoDB バージョン

警告

MongoDB 5.0から6.0にアップグレードします

注意

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

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

ストレージ エンジン

重要

例

修正されたプロパティ

配置トポロジー

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

複数の変更

例

強制再構成

Tip

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

シャードの削除

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

例

例 1

例

例 2

警告

MongoDB 5.0から6.0にアップグレードします

すべての変更はクラスター全体で

Kubernetes Operator による一部のMongoDB Ops Manager設定の上書き

例

Kubernetes で使用できない変更

前提条件

手順

Deploymentプロジェクトの ページに移動します。

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

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

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

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

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

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

Deploymentプロジェクトの ページに移動します。

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

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

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

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

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

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

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

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

Tip

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

Deploymentプロジェクトの ページに移動します。

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

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

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

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

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

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

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

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

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

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

ストレージエンジン

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

Deploymentプロジェクトのページに移動します。

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

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

Deploymentプロジェクトのページに移動します。

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

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

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

Deploymentプロジェクトのページに移動します。

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

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

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