Atlas クラスターに対して次の追加設定を構成できます。
注意
このページは、Atlas InfiniteとAtlas Coreの両方に適用されます。
設定が特定のエディションにのみ適用される場合は、そのセクションにその旨が記載されています。
クラスターの MongoDB バージョンを選択
利用可能な MongoDB バージョン、リリースケーデンスオプション、およびクラスターのバージョンの選択方法について詳しくは、Atlas の MongoDB バージョンを参照してください。
クラスターのバックアップ オプションの構成
このセクションでは、Atlas クラスターのバックアップ構成オプションについて説明します。Atlas バックアップの詳細については、「クラスターのバックアップ」を参照してください。
Flex クラスターのバックアップオプション
Atlas は Flex クラスタのバックアップを自動的に有効化し、無効にすることはできません。詳細については、「Flex クラスターのバックアップ」をご覧ください。
M10+ 階層 バックアップ オプション
M10+ Atlas クラスターのクラウドバックアップを有効にするには、Turn on Cloud Backup トグルを On に設定します。有効にすると、Atlas は定期的にデータベースのスナップショットを取得し、プロジェクトのバックアップポリシーに従ってそれらを保持します。
To disable Cloud Backup for an M10+ Atlas cluster, set the Turn on Cloud Backup toggle to Off. This also disables Continuous Cloud Backup for the cluster. To retain any existing snapshots after Cloud Backup is disabled, set the Keep
existing snapshots after backups disabled? toggle to On before you apply your changes to the cluster. This option instructs Atlas to retain the existing snapshots and oplog for the cluster according to your cluster's backup policy.
注意
バックアップ コンプライアンス ポリシーが有効になっている場合は、クラウドバックアップを無効にすることはできません。バックアップ コンプライアンス ポリシーで Require Point in Time Restore to all clusters オプションが On に設定されている場合は、MongoDB サポートなしで継続的なクラウドバックアップを無効にできません。継続的なクラウドバックアップを無効にするには、バックアップ コンプライアンス ポリシーに指定されたセキュリティ担当者または法定代理人がサポートをリクエストし、検証プロセスを完了する必要があります。
Atlas は、M10+ クラスターに対して次のバックアップ オプションを提供します。
バックアップ オプション | 説明 |
|---|---|
Atlasはクラスター内のデータのインクリメンタル スナップショットを取得し、それらのスナップショットからデータを復元できるようにします。Atlas は、スナップショットの対象となるレプリカセット ノードと同じクラウドプロバイダー リージョンにスナップショットを格納します。 | |
After Atlas restores a snapshot, Atlas replays the oplog to restore a cluster from a particular point in time within a window specified in the backup policy. |
Atlas Infinite クラスターのバックアップオプション
Atlas Infinite クラスターには、24 時間の継続的なクラウドバックアップウィンドウが含まれています。そのウィンドウを超えてスナップショットを保持するには、Atlas がデフォルトで有効にする Additional Backup Retention 設定を使用します。追加のバックアップ保持には、バックアップポリシーとワークロードに基づいて追加コストが発生します。
Atlas Administration APIでは、backupEnabledフィールドはAtlas InfiniteクラスターのAdditional Backup Retentionを制御します。継続的なバックアップウィンドウは常に適用されるため、Atlasがクラスターをバックアップするかどうかは制御しません。
クラスターを作成した後、スナップショットの保持ポリシーを構成できます。学ぶには、詳細については「バックアップポリシーの管理」を参照してください。
終了保護
クラスターに対して Termination Protection を有効にするには、Termination Protection を Yes に切り替えます。
有効にすると、Atlas はユーザーによるクラスターの削除を防止します。終了保護が有効になっているクラスターを削除するには、まず終了保護を無効にする必要があります。デフォルトでは、Atlas はすべてのクラスターの終了保護を無効にします。
クラスターの終了の詳細については、「1 つの配置の終了」を参照してください。
シャーディングされたクラスターの配置
Tip
Atlas Core クラスターでは、オンラインアーカイブ を構成して、アクセス頻度の低いデータを Atlas クラスターから MongoDB マネージドの読み取り専用フェデレーティッドデータベースインスタンスに移動できます。これにより、コレクションをシャーディングしたり、クラスター階層をアップグレードしたりする必要がなくなります。Atlas Infinite クラスターでは、パブリックプレビューにおいて オンライン アーカイブ はサポートされていません。オンライン アーカイブ の詳細については、「Atlas での オンライン アーカイブ の管理」を参照してください。
To deploy your cluster as a sharded cluster, toggle Shard your cluster (M30 and up) to Yes.
重要
The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see Public Preview Availability.
Sharded clusters support horizontal scaling and consist of shards, config servers and mongos routers. To learn more, see About Config Servers Deployment. Config servers must remain readable for sharded read operations to continue to function.
If you enable Atlas-managed config servers, Atlas may colocate config server data with application data instead of using a dedicated config server. To learn more, see Atlas-Managed Config Servers for Sharded Clusters.
シャード配置について
Atlas deploys each shard as a three-node replica set, where each node deploys using the configured Cloud Provider & Region, Cluster Tier, and Additional Settings. Atlas deploys one mongod per shard node.
クロスリージョン クラスターの場合、シャードあたりのノード数は、設定されたすべてのリージョンにわたる選挙可能なノードと読み取り専用ノードの合計数に等しくなります。Atlas は、選択したリージョンにシャード ノードを分散します。
コンフィギュレーションサーバーの配置について
For dedicated config servers, Atlas deploys the config servers as a three-node replica set. The config servers run on M30 cluster tiers. In multi-region clusters, config servers are distributed across regions.
For cross-region clusters, Atlas distributes the config server replica set nodes to ensure optimal availability. For example, Atlas might deploy the config servers across three distinct availability zones and three distinct regions if supported by the selected cloud service provider and region configuration. Config servers must remain readable for sharded read operations to continue to function. To learn more, see Config Server Availability.
If you enable Atlas-managed config servers, Atlas may colocate config server data with application data instead of using a dedicated config server. To learn more, see Atlas-Managed Config Servers for Sharded Clusters.
mongos 配置について
Atlas deploys one mongos router for each node in each shard. For cross-region clusters, this allows clients using a MongoDB driver to connect to the geographically "nearest" mongos.
To calculate the number of mongos routers in a cluster, multiply the number of shards by the number of replica set nodes per shard.
シャーディングされたクラスターの配置をレプリカセットの配置に変換することはできません。
サーバー インスタンスの数がコストに与える影響の詳細については、「ノード数」を参照してください。
シャーディングされたクラスターの詳細については、MongoDB マニュアルの「シャーディング」を参照してください。
シャードの数を設定する
このフィールドは、配置がシャーディングされたクラスターである場合にのみ表示されます。
クラスターは、1 から 70 までのシャードを持つことができます。
レプリカセットをマルチシャーディングされたクラスターにスケール アップするには、まず単一のシャーディングされたクラスターにスケール アップし、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
レプリカセットクラスターを単一のシャーディングされたクラスターにスケール アップしたら、そのシャーディングされたクラスターで配置するシャードの数を設定できます。
If you are reducing the number of shards in your sharded cluster, Atlas removes shards in descending order based on the number in the "_id" field (see Sharded Cluster Configuration). For example, consider a sharded cluster with the following three shards:
"shard0""shard1""shard2"
シャードの数を 2 に設定すると、Atlas はクラスターから "shard2" を削除します。
IMPORTANT: When you remove a shard in 8.0, Atlas uses the moveCollection command to move any unsharded collections in that shard to a remaining shard. All unsharded collections remain online during this process.
すべてのシャーディングされたコレクションは、シャード削除プロセス中もオンラインのままとなり、利用可能です。削除されたシャードからシャーディングされたコレクションを空にするには、バランサーをオンにする必要があります。
Atlas moves any unsharded collections that can't be drained by
moveCollectioncommand by using the movePrimary command. To learn more about the limitations ofmoveCollection, see Restrictions.movePrimaryis an offline operation.シャード削除の詳細については、「 クラスターからシャードを削除する 」を参照してください。
レプリカセットをクラスターに変換する場合の考慮事項
クラスター階層が M30 以上の場合は、レプリカセットをクラスターに変換できます。
単数形のレプリカセットクラスターを複数シャードのシャーディングされたクラスターに変換するには、まず単一のシャード シャーシャーディングされたクラスターに変換し、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再起動しないと、Atlas によってシャード間でのデータ分散が開始された後、データの整合性が失われる可能性があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
DNS シードリスト接続文字列を使用している場合、アプリケーションはシャーディングされたクラスターの
mongosに自動的に接続されます。If you are using a standard connection string, you must update your connection string to reflect your new cluster topology.
Starting in MongoDB 8.3, DDL operations and applyOps can only be run on a mongos for all sharded clusters. These operations may be temporarily unavailable while transitioning from a replica set to a sharded cluster.
変換した後、コレクションを シャーディング し、シャード間でデータを分散するために適切なシャードキーを選択する必要があります。詳細については、「クラスターへのレプリカセットの変換」を参照してください。
注意
レプリカセットをシャーディングされたクラスターに変換すると、Atlas が管理するコンフィギュレーションサーバーが有効になっている場合でも、結果のクラスターは常に専用のコンフィギュレーションサーバーを使用します。変換後に埋め込みコンフィギュレーションサーバーが必要な場合は、MongoDB サポート にお問い合わせください。
インテリジェントなワークロードマネジメントを構成する
Intelligent ワークロード マネジメント(IWM)は、過負荷状態であっても Atlas クラスターの優れた応答性と予測可能性を維持する MongoDB Atlas マネージド型の可用性システムです。オーバーロードは、クラスターがリソースで処理できる量を超える操作を受信したときに発生します。
Intelligent Workload Management セクションは M10 以上のクラスターに表示されます。これには 2 つの設定が含まれており、その可用性はクラスター層とMongoDB のバージョンによって異なります。
Load Shedding:
mongodM30+インテリジェント ワークロード マネジメント(IWM)保護を制御し、プロセスが持続的に過負荷に該当する場合に、受信側の プロセスで受信データベース操作を拒否します。これはMongoDB.9 0以降を実行中 レプリカセットクラスターでのみ有効です。最良の結果を得るには、バックプレッシャー対応ドライバーを使用します。詳細については、「 ロード シェル 」を参照してください。Search Load Shedding:
mongotプロセスが持続的に過負荷に該当する場合に、受信8.0 8.39.0Offプロセスで受信MongoDB Search8.0 83OnおよびMongoDB9 0ベクトル検索クエリを拒否する IWM 保護を制御します。 MongoDB 、 、 、またはそれ以降を実行中クラスターで使用できます。デフォルトでは、Atlas が設定を管理し、 MongoDB の およびMongoDB. 以降の. と に解決されます。無料クラスターと Flex クラスターでは、 設定は表示されず、Atlas が常にそれを管理するため、上書きすることはできません。詳細については、「 検索とベクトル検索のクエリの負荷認証とクエリの拒否 」を参照してください。
操作を拒否しないその他の IWM 保護は、IWM 設定に関係なく、すべての適格なクラスターでアクティブのままになります。常時オンの IWM 保護の詳細については、「 常にオンの保護 」を参照してください。
Load Shedding 設定は、以下の値を受け入れます。
Atlas マネージド(デフォルト): Atlasは、クラスターのロードシェディングの有効な状態を制御します。設定の下にある Effective state: ラベルは、保護が現在クラスターでアクティブかどうかを示します。
有効: Atlasは、長期間の過負荷状態にある間、クラスターへの受信操作を拒否する場合があります。
無効: Atlasはクラスターへの受信操作を拒否できません。
注意
M10 クラスターおよび M20 クラスターでは、Load Shedding 設定が表示されますが、効果はありません。Load
Shedding を Enabled に設定した場合、Effective state: は Disabled のままです。
MongoDB SQL Interface の有効化
MongoDB SQL インターフェースを使用すると、フェデレーティッドデータベースインスタンスを必要とせずに、Tableau や Power BI などの BI ツールから ODBC および JDBC ドライバーを介してクラスターをクエリできます。SQL Interface は、MongoDB 6.0 以降を実行している M10 以上の専有クラスター上で有効化できます。
The toggle appears in the cluster configuration form only for eligible clusters. For the full list of requirements, and to compare the direct connection with a federated database instance, see the MongoDB SQL Interface overview.
You can also enable and disable the SQL Interface with the Atlas Administration API. To learn more, see the Server Setup page in the SQL Interface documentation.
BI Connector for Atlas 利用可能性
重要
The MongoDB Connector for Business Intelligence for Atlas and on-premises reached end of life (EOL) in September 2026 and is no longer supported. Use the MongoDB SQL Interface to connect to Atlas or Enterprise Advanced deployments. The SQL Interface provides a simpler, direct connection to your clusters without requiring a separate BI Connector instance, and it offers improved performance, a simplified setup, and enhanced features. To learn more, see MongoDB SQL Interface Overview.
クラスター構成フォームは、EOL に達したため Atlas 用 BI Connector を制限します:
クラスターで BI Connector for Atlas がまだ有効になっていない場合、Enable Business Intelligence Connector セクションは表示されず、有効にすることもできません。
Atlas用BI Connectorが既に有効になっている場合、セクションに非推奨の通知が表示され、Atlas用BI Connectorをオフにすることしかできません。一度無効にすると、再度有効にすることはできません。Review Changesページにも同じ通知が表示されます。
We recommend using the MongoDB SQL Interface (Atlas Dedicated) instead. To move an existing BI Connector for Atlas workload across, see the migration guide.
独自の暗号化キーの管理
注意
この機能は、M10 クラスター以上で使用できます。Free クラスターで利用可能な機能について学ぶには、「Atlas Free Cluster Limits」を、Flex クラスターについては「Atlas Flex Limitations」を参照してください。
Atlas encrypts all cluster storage and snapshot volumes, ensuring the security of all cluster data at rest (Encryption at Rest). Atlas Project Owners can configure an added layer of encryption on their data at rest using the MongoDB Encrypted Storage Engine and their Atlas-compatible Encryption at Rest provider.
Atlas は、次の保管時の暗号化のプロバイダーをサポートしています。
前提条件
Atlas クラスターでこの機能を有効にする前に、使用しているキー管理を使用して Atlas プロジェクトの保管時の暗号化を設定する必要があります。詳細については、「カスタマー キー 管理を使用した保管時の暗号化」を参照してください。
クラスターの保管時の暗号化のプロバイダーを別のプロバイダーに切り替えるには、まずクラスターの保管時の暗号化のプロバイダーを無効にし、その後に変更先の保管時の暗号化のプロバイダーで再度有効にする必要があります。詳細については、「カスタマー キー 管理を使用した保管時の暗号化」を参照してください。
手順
このクラスターの独自の暗号化のキーの管理を開始するには、Encryption using your Key Management (M10 and up) を Yes に切り替えてください。
キー管理を使用した Atlas Encryption at Rest は、M10+レプリカセットクラスターで利用できます。 Atlas Encryption at Rest は、 クラスターのバックアップ の暗号化 のみ をサポートします。
独自の暗号化のキーを管理すると、クラスターの 1 時間あたりの運用コストが上昇します。高度なセキュリティ機能に対する Atlas の課金の詳細については、「高度なセキュリティ」を参照してください。
重要
Atlas が Atlas プロジェクトのキー管理プロバイダーまたはクラスタの暗号化に使用される暗号化のキーにアクセスできない場合、そのクラスタはアクセスできなくなり、回復できなくなります。Atlas が使用する暗号化のキーやキー管理プロバイダーの認証情報を変更、削除、または無効化する前に、細心の注意を払ってください。
追加オプションの構成
You can configure the following mongod runtime options on M10+ paid tier clusters.
Considerations
クラスターのストレージサイズを変更すると、Atlas はレプリカセットとシャーディングされたクラスターの Oplog Size を動的に変更します。Atlas が oplog サイズを管理する方法の詳細については、「Oplog サイズの動作」を参照してください。ただし、Minimum TLS Protocol Version および Allow Server-Side JavaScript の設定では、シャードメンバーとコンフィギュレーションサーバーレプリカセットのローリング再起動が実行されます。Atlas がメンテナンス操作中に高可用性をサポートする方法の詳細については、「MongoDB Atlas が高可用性を実現する方法」を参照してください。
追加設定の表示と編集
これらの設定を表示および編集する方法は、次のとおりです。
MongoDB Atlas CLIを使用して1つのクラスターの詳細構成設定をアップデートするには、次のコマンドを実行します。
atlas clusters advancedSettings update <clusterName> [options]
To learn more about the command syntax and parameters, see the Atlas CLI documentation for atlas clusters advancedSettings update.
Atlas Infiniteクラスターでは、代わりにatlas api clusters updateClusterAdvancedConfigurationを使用してください。atlas clustersコマンドは、Atlas Infiniteのフィールドを含まない固定されたオプションセットを受け入れます。
これらの設定を Atlas UI で表示および編集するには、クラスター フォームのAdditional Settings の下にある More Configuration Options を開きます。
Atlas Core Amazon Web Servicesクラスターのリージョン間での最初の同期を高速化
注意
この機能はAtlas Infiniteには適用されません。Atlas Infiniteの機能と動作の詳細については、「MongoDB Atlas Infinite: 概要」を参照してください。
Atlas では、AWS リージョンに新しいノードを追加すると、クラウドベースの最初の同期を実行してソース ノードのスナップショットを作成し、AWS のネイティブなスナップショット機能を使用してそのスナップショットを新しいノードに復元します。
この設定を有効にすると、Atlas はAWS時間ベースのスナップショットを使用して、ソース ノードとは異なる AWS リージョンにある宛先 AWS ノードのクラウドベースの最初の同期を実行します。Atlas は、データの最新性を最大限に高めるために、セカンダリ ノードよりもプライマリ ノードからの復元するを優先します。時間ベースのスナップショット コピー操作では、500 MiB/s の最大コピー操作スループットが実現できます。Atlas は、スナップショットのサイズに基づいてコピー操作の完了時間を調整することで、常にスループットを最大化します。
Atlas supports cross-region Cloud-based initial sync for AWS and Google Cloud clusters only. For Azure clusters, Atlas performs a logical initial sync to add a node to a new region. You can add or replace nodes in your cluster when you edit the cluster configuration.
この設定は、少なくとも 1 つの AWS ノードを含むクラスターに対してのみ有効です。すべてのクラスターは、デフォルトでオプトアウトされています。AWS クラスターでオプトアウト状態のままの場合、Atlas は AWS のネイティブな非時間ベースのスナップショットコピー方式を使用して、リージョンをまたぐクラウドベースの最初の同期を実行します。非時間ベースのスナップショットコピーは、時間ベースのスナップショットコピーよりも大幅に時間がかかる可能性があります。
より高速な時間ベースのクロスリージョンの最初の同期を有効にすると、AWSからの追加コストが発生します。AWSスナップショットの料金請求の詳細については、 「 Amazon EBS 価格ページ 」を参照してください。
Azure クラスターのアダプティブ キャパシティー
注意
この機能はAtlas Infiniteには適用されません。Atlas Infiniteの機能と動作の詳細については、「MongoDB Atlas Infinite: 概要」を参照してください。
Atlas では、ノードが 1 つ以上ある Microsoft Azure 上のクラスターで、Adaptive Capacity がデフォルトで有効になります。適応型キャパシティーは、M30 以上のクラスターで有効になります。詳細を学ぶには、「 適応型キャパシティー」を参照してください。
個別のクラスターの適応型キャパシティーをオプトアウトするには、または再有効にするには、Atlas UI または Atlas Administration API を使用します。
クラスター エンドポイントにリクエストを送信します。
この設定を既存のクラスターで変更するには、1 つのクラスターを更新エンドポイントに PATCH リクエストを送信します。クラスターをプロビジョニングする際にこの設定を行うには、代わりに 1 つのクラスターを作成エンドポイントに POST リクエストを送信します。adaptiveCapacity フィールドは、Atlas Administration API バージョン 2024-08-05 以降で使用できます。
adaptiveCapacity フィールドを設定します。
リクエスト ボディでは、トップレベルの adaptiveCapacity フィールドを次のいずれかの値に設定します。
値 | 説明 |
|---|---|
| Atlas は、キャパシティーが不足している場合、使用可能なキャパシティーを持つ代替インスタンスタイプでクラスターをプロビジョニングできます。Atlas は、Microsoft Azure クラスターについて、この値をデフォルトで使用します。 |
| Atlas は、クラスターを元のインスタンスタイプに保持します。 |
更新リクエストで adaptiveCapacity フィールドを省略した場合、Atlas は現在の設定を変更しません。単一のクラウド上の Amazon Web Services または Google Cloud Platform クラスターに adaptiveCapacity を設定しても効果はありません。
最小 oplog window の設定
Modify the retention duration for oplog entries in the oplog of the cluster. By default, Atlas retains entries for 24 hours in Atlas Infinite and Atlas Core before the mongod removes them from the oplog.
This option corresponds to modifying the storage.oplogMinRetentionHours configuration file option for each mongod in the cluster.
最小 oplog window を設定するには、次の手順を行います。
ストレージのオートスケーリングが有効になっており、オプトアウトしていないことを確認します。Atlas ではデフォルトでオートスケーリングが有効になっています。
Set the minimum oplog window to the desired value. If you don't set this value, Atlas retains oplog entries for 24 hours in Atlas Infinite and Atlas Core before the
mongodremoves them from the oplog.
Oplog サイズの設定
注意
この機能はAtlas Infiniteには適用されません。Atlas Infiniteの機能と動作の詳細については、「MongoDB Atlas Infinite: 概要」を参照してください。
固定の oplog サイズを設定できるため、ライブ移行中や集中的なデータ読み込み時に役立ちます。
Set Oplog Size 構成設定は、クラスターのストレージ オートスケーリングをオプトアウトした場合にのみ設定できます。MongoDB のコマンド replSetResizeOplog を使用して、Atlas のクラスター上の oplog のサイズを変更することはできません。
ストレージのオートスケーリングが有効になっているクラスターでは、代わりに Minimum Oplog Window を設定できます。詳しくは、最小 Oplog Window の設定を参照してください。Atlas では、ストレージのオートスケーリングはデフォルトで有効になっています。
設定できる oplog の最小サイズは 990 メガバイトです。選択した oplog サイズによってクラスターのディスクの空きキャパシティーが 25% 未満になった場合、Atlas はエラーを返します。
現在の oplog サイズとレプリケーションラグ時間を確認するには
Connect to your cluster via
mongosh.Authenticate as a user with the
Atlas adminrole.Run the
rs.printReplicationInfo()method.
Atlas では、現在の oplog サイズとレプリケーションラグ時間を表示します。
固定 oplog サイズを設定するには、次の手順を行います。
ストレージのオートスケーリングをオプトアウトします。
Minimum Oplog Window を
0に設定します。必要な oplog のサイズを決定します。
Atlas UI で移行プロセス中のラグ時間を監視します。
If the lag time shown in the Atlas UI during migration approaches the replication lag time that you obtained using the
rs.printReplicationInfo()method, increase the oplog size.
入力ボックスに、任意のOplog Sizeを指定します(メガバイト単位)。 この設定では、ディスク上のサイズではなく、oplog の非圧縮サイズが構成されます。
シャーディングされたクラスターの配置の場合、このオプションによりクラスター内の各シャードの oplog サイズが変更されます。
This option corresponds to modifying the
replication.oplogSizeMBconfiguration file option for eachmongodin the cluster.警告
oplog のサイズを小さくするには、oplog からデータを削除する必要があります。Atlas は、oplog の削減の結果として削除された oplog エントリにアクセスしたり、復元したりすることはできません。oplog を削減する前に、このデータ損失の影響を考慮してください。
ディスク容量に関する考慮事項
使用可能なディスク容量を増やすために oplog のサイズを小さくしないでください。oplog サイズを縮小することで節約されるスペースは、oplog コレクション(local.oplog.rs)のみが再利用できます。他のコレクションには、oplog ストレージを削減することによるメリットはありません。
サーバーサイド JavaScript を許可する
JavaScript をサーバー側で実行する操作の実行を有効または無効にします。
If your cluster runs a MongoDB version less than 5.0, this option corresponds to modifying the
security.javascriptEnabledconfiguration file option for eachmongodin the cluster.If your cluster runs MongoDB version 5.0 or greater, this option corresponds to modifying the
security.javascriptEnabledconfiguration file option for eachmongodandmongosin the cluster.If your cluster runs MongoDB version 8.0, Allow Server-Side JavaScript is disabled by default to improve security and performance. This option corresponds to the
security.javascriptEnabledconfiguration file option for eachmongodandmongosin the cluster.
注意
In MongoDB version 7.0 and later, security.javascriptEnabled applies to mongos' as well.
冗長化および匿名化されたクエリ データのログを有効にする
編集され匿名化された $queryStats 出力を MongoDB ログに含めます。$queryStats 出力にはリテラル値またはフィールド値が含まれていません。この設定を有効にすると、クラスターのパフォーマンスに影響を与える可能性があります。
注意
クエリ データのロギングは、MongoDB 7.1 以降を実行する Atlas クラスターでのみ有効にできます。
TLS プロトコルの最小バージョンの設定
Set the minimum TLS version that the cluster accepts for incoming connections. This option corresponds to configuring the net.tls.disabledProtocols configuration file option for each mongod in the cluster.
重要: Atlas は、もはや TLS 1.0 または 1.1 をサポートしていません。すべてのクラスターは、TLS 1.0 または 1.1 での接続試行を拒否します。クラスターの最小 TLS バージョンを 1.2 以上に設定します。
カスタム暗号スイート構成の設定
From a list of cipher suites, select which will be used for your cluster's node-to-node and client-to-Atlas communications. The list of available ciphers depends on the cluster's minimum TLS version.
注意
カスタム TLS 1.2 暗号構成があり、TLS 1.3 にアップグレードする場合は、構成を更新して TLS 1.3 暗号を含める必要があります。
すべてのクエリにインデックスが必要
重要
The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see Public Preview Availability.
Enable or disable the execution of queries that require a collection scan to return results. This option corresponds to modifying the notablescan parameter via the setParameter command for each mongod in the cluster.
重要
If you're creating MongoDB Search indexes, you might need to disable this parameter. To learn more, see Considerations for MongoDB Search Indexes.
デフォルトの書込み保証 (write concern)
Atlas Infiniteクラスターでは、デフォルトの書込み保証 (write concern)を設定することはできません。Atlas Infiniteクラスターでの書込み保証 (write concern)の仕組みを学ぶには、「Atlas Infiniteクラスターでの書込み保証 (write concern)」を参照してください。
Set the default level of acknowledgment requested from MongoDB for write operations for this cluster.
The default write concern for clusters is majority.
トランザクションの有効期間を設定する
重要
The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see Public Preview Availability.
Set the maximum lifetime of multi-document transactions. This option corresponds to modifying the transactionLifetimeLimitSeconds parameter via the setParameter command for each mongod in the cluster.
重要
トランザクションの有効期間を 1 秒未満に設定することはできません。
クラスターのデフォルトのトランザクション有効期間は 60 秒です。
高速ディスク事前ウォーミングの有効化または無効化
注意
この機能はAtlas Infiniteには適用されません。Atlas Infiniteの機能と動作の詳細については、「MongoDB Atlas Infinite: 概要」を参照してください。
Atlas では、AWS および Azure でホストされているクラスターに対して、Fast Disk Pre-Warming 設定を提供しています。Atlas は、これらのクラスターではデフォルトで高速ディスクのプレウォーミングを可能にします。
Amazon Web Services または Azure クラスターの高速ディスクプレウォーミングを無効にするには、「Fast Disk Pre-Warming」設定の下の「Off」を選択します。再度有効にするには、Fast Pre-Warming (Default) を選択します。
Due to the design of the underlying cloud provider infrastructure, disk pre-warming occurs whenever Atlas performs a Cloud-based initial sync, such as when Atlas adds a new node to an existing region in your cluster. During a Cloud-based initial sync, Atlas temporarily hides the new node to prevent it from serving reads until it is ready.
高速ディスク事前ウォーミングは、バックグラウンド ディスク ウォーミングよりも高速です。高速ディスクのプレウォーミングが有効になっている場合、新しいノードはプレウォーミング中にプロビジョニングされた IOPS の大部分を消費します。そのため Atlas はプレウォーミングが完了するまでノードを非表示にします。高速ディスクの事前ウォームアップが無効になっている場合、Atlas はノードの準備が整い次第、ノードを再表示し、ディスクをバックグラウンドでウォームアップします。これにより、ノードがより早く表示されるようになります。
M40+ AWS クラスターで、NVMeストレージを使用しない場合、Atlas は、クラウドベースの最初の同期中の高速ディスクの事前温めをサポートするため、ハイパフォーマンスな AWS ストレージボリュームを一時的にプロビジョニングします。ディスクのプレウォーミングが完了した後、Atlas はボリュームをノードの元のストレージ設定に戻します。この変更では、AWS が各 EBS ボリュームに対して 24 時間の任意の期間内で許可している 4 つの EBS ボリューム変更のいずれか 1 つを使用します。EBS ボリューム変更制限について詳しくは、「Amazon Web Services でのストレージ容量または IOPS の変更」を参照してください。
より高性能な一時ストレージボリュームをプロビジョニングすると、Atlas の月額請求書におけるクラスターのストレージコストが一時的に増加する可能性があります。詳細については、「ストレージ キャパシティー」を参照してください。
次の推奨事項を検討してください。
一貫したクエリ レイテンシを求めるワークロードがある場合は、この設定を有効にします。
一貫したクエリ パフォーマンスによる最大限の可用性の保証を求めるワークロードがあり、新しく追加または交換されたノードをすぐにアクティブにして表示できるようにする必要がある場合は、事前ウォーミングプロセスが完了するまで、この設定を無効にし、事前ウォーミングを行うノードのタグを含むカスタム接続文字列を使用します。この接続文字列を使用すると、ノードでの読み取りが防止されますが、IOPS のほとんどが事前ウォーミング プロセスによって使用されます。
読み取り操作のデフォルトタイムアウトを設定する
For clusters running MongoDB version 8.0+, you can specify the default maximum timeout in milliseconds of all read operations for these clusters. This protects your database against unintentional long-running queries. This option corresponds to the cluster parameter defaultMaxTimeMS.
レプリカセット スケーリング モードの構成
注意
この機能はAtlas Infiniteには適用されません。Atlas Infiniteの機能と動作の詳細については、「MongoDB Atlas Infinite: 概要」を参照してください。
Modify the replica set scaling mode for your cluster. Atlas uses the scaling mode In Parallel By Workload Type by default. Atlas can also scale a replica set with the In Parallel By Node Type and Sequential modes.
次のリストでは、使用可能なスケーリング モードについて説明します。
In Parallel By Workload Type mode applies only to clusters with read-only operational nodes and analytics nodes. Atlas uses this scaling mode by default, unless you specify another scaling mode. In this mode, Atlas scales your analytics nodes in parallel with your operational nodes.
注意
If your cluster has only electable nodes, the scaling mode In Parallel By Workload Type doesn't affect cluster behavior.
Sequential モードは、定常状態のワークロードとレイテンシのセカンダリ読み取りを実行するアプリケーション用です。このモードでは 、Atlas はすべてのノードを順番にスケーリングします。
ログ リダクションを有効にする
Toggle this on to prevent logging of potentially sensitive information in field values. For more information, see Log Redaction.
ログリダクションを有効および無効にするには、ローリング再起動が必要です。
シャーディングされたクラスターの Atlas 管理設定サーバ
Enable or disable Atlas management of the config server type for a new sharded cluster. An Atlas-managed config server automatically switches the config server type based on criteria for optimal performance and cost savings. If you don't enable an Atlas-managed config server for a sharded cluster, Atlas always uses a dedicated config server for the cluster.
すべての 8.0 Atlas シャーディングされたクラスターで、Atlas が管理するコンフィギュレーションサーバーはデフォルトで On です。 Atlas 管理のコンフィギュレーションサーバーを無効にするには、トグルを Off に設定します。クラスターに 11 未満のシャードと埋め込みコンフィギュレーションサーバーがある場合、Atlas が管理するコンフィギュレーションサーバーをオフにすると、クラスターはすぐに専用コンフィギュレーションサーバーに移行されます。
注意
組み込み型コンフィギュレーションサーバーまたはコンフィギュレーションシャードは、グローバルクラスターではサポートされていません。
コンフィギュレーションサーバーのタイプ
Atlas は、Atlas が管理するコンフィギュレーションサーバーが有効になっている新しいシャーディングされたクラスターごとに、11 未満のクラスターには埋め込みコンフィギュレーションサーバーを配置し、10 を超えるシャードを持つクラスターには専用のコンフィギュレーションサーバーを配置します。
組み込みコンフィギュレーションサーバーは、アプリケーションデータをコンフィギュレーションシャード上の構成データと同じ場所に配置します。組み込みコンフィギュレーションサーバー クラスターは使用するリソースが少ないため、コストが低くなります。
専用コンフィギュレーションサーバーは、構成データ用に別の専用コンフィギュレーションサーバーのレプリカセットを使用します。アプリケーションデータは、専用コンフィギュレーションサーバーの構成データと同じ場所に配置されません。専用のコンフィギュレーションサーバー クラスターは、追加のレプリカセットを使用するため、コストが高くなります。
コンフィギュレーションサーバーの種類に関する詳細な考慮事項については、「コンフィギュレーションサーバーの考慮事項」を参照してください。
コンフィギュレーションサーバーの変更基準
Atlas 管理のコンフィギュレーションサーバーを有効にする場合、Atlas は初期クラスターのコンフィギュレーションサーバーのタイプを次のように決定します。
クラスター シャード数が 10 より大きい場合、Atlas は専用のコンフィギュレーションサーバーを使用します。
クラスター シャード数が 10 以下の場合、Atlas は埋め込みコンフィギュレーションサーバーを使用します。
Atlas 管理のコンフィギュレーションサーバーを有効にしてシャードを追加または削除すると、Atlas は自動的に同じ基準で、シャーディングされたクラスターのコンフィギュレーションサーバーの種類を再選択します。
既存のシャーディングされたクラスターを MongoDB 7.0 から 8.0 にアップグレードすると、Atlas は Atlas マネージドのコンフィギュレーションサーバーを有効にしますが、クラスターの既存のコンフィギュレーションサーバーの種類は変更されません。これらの基準は、シャード数の変更にのみ適用します。
コンフィギュレーションサーバーに関する考慮事項
MongoDB 8.0 より前のバージョンのすべてのクラスターは、専用のコンフィギュレーションサーバーを使用します。
次の機能のいずれかを使用する場合、Atlas はコンフィギュレーションサーバーのタイプを変更しません。
10これらの機能の使用により専用のコンフィギュレーションサーバーに移行できない、 を超えるシャードを持つクラスターがある場合は、 MongoDBサポート に連絡して構成サーバーのタイプを変更してください。
Atlas 管理のコンフィギュレーションサーバーを有効にする場合は、次の考慮事項が該当します。
MongoDB 8.0 以降を実行しているクラスターでは、レプリカセット ID にはレプリカセットに保存されているデータのタイプが反映されません。
レプリカセット ID に
shardが含まれるレプリカセットには、アプリケーションデータと構成データ、またはその両方が保存される場合があります(例:atlas-abc123-shard-0)。レプリカセット ID に
configが含まれるレプリカセットには、アプリケーションデータが保存される場合があります(例:atlas-abc123-config-0)。
バックアップ スナップショットに関する考慮事項
専用コンフィギュレーションサーバーのあるクラスターのスナップショットは、同じく専用コンフィギュレーションサーバーを使用するクラスターにのみ復元できます。
組み込みコンフィギュレーションサーバーのあるクラスターのスナップショットは、同じく組み込みコンフィギュレーションサーバーを使用するクラスターにのみ復元できます。