Atlas クラスターに対して次の追加設定を構成できます。
注意
このページは、Atlas Infinite と Atlas Core の両方に適用されます。
設定が 1 つのエディションのみに適用される場合、そのセクションにはそのように表示されます。
クラスターの MongoDB バージョンを選択
利用可能な MongoDB バージョン、リリースケーデンスオプション、およびクラスターのバージョンの選択方法について詳しくは、Atlas の MongoDB バージョンを参照してください。
クラスターのバックアップ オプションの構成
このセクションでは、Atlas クラスターのバックアップ構成オプションについて説明します。Atlas バックアップの詳細については、「クラスターのバックアップ」を参照してください。
Flex クラスターのバックアップオプション
Atlas は Flex クラスタのバックアップを自動的に有効化し、無効にすることはできません。詳細については、「Flex クラスターのバックアップ」をご覧ください。
M10+ 階層 バックアップ オプション
M10+ Atlas クラスターのクラウドバックアップを有効にするには、Turn on Cloud Backup トグルを On に設定します。有効にすると、Atlas は定期的にデータベースのスナップショットを取得し、プロジェクトのバックアップポリシーに従ってそれらを保持します。
M10+ Atlas クラスターのクラウドバックアップを無効にするには、[Turn on Cloud Backup] トグルを [Off] に設定します。これにより、クラスターの継続的クラウドバックアップも無効になります。クラウドバックアップが無効になった後に、既存のスナップショットを保持するには、[Keep
existing snapshots after backups disabled?] トグルを [On] に設定します。このオプションは、クラスターのバックアップポリシーに従って、既存のスナップショットと oplog を保持するよう Atlas に指示します。
注意
バックアップ コンプライアンス ポリシーが有効になっている場合は、クラウドバックアップを無効にすることはできません。バックアップ コンプライアンス ポリシーで Require Point in Time Restore to all clusters オプションが On に設定されている場合は、MongoDB サポートなしで継続的なクラウドバックアップを無効にできません。継続的なクラウドバックアップを無効にするには、バックアップ コンプライアンス ポリシーに指定されたセキュリティ担当者または法定代理人がサポートをリクエストし、検証プロセスを完了する必要があります。
Atlas は、M10+ クラスターに対して次のバックアップ オプションを提供します。
バックアップ オプション | 説明 |
|---|---|
Atlasはクラスター内のデータのインクリメンタル スナップショットを取得し、それらのスナップショットからデータを復元できるようにします。Atlas は、スナップショットの対象となるレプリカセット ノードと同じクラウドプロバイダー リージョンにスナップショットを格納します。 | |
Atlas はスナップショットを復元した後、oplog を再生して、バックアップ ポリシーで指定された期間内の特定の時点からクラスターを復元します。 |
Atlas Infinite クラスターのバックアップ オプション
Atlas Infinite クラスターには、24 時間の継続的なクラウドバックアップウィンドウが含まれます。そのウィンドウを超えてスナップショットを保持するには、 Additional Backup Retention 設定を使用します。この設定は Atlas によりデフォルトで有効になります。追加のバックアップ保持には、バックアップポリシーとワークロードに基づく追加コストが発生します。
Atlas Administration APIでは、diskBackupEnabledフィールドがAtlas Infinite クラスター上の Additional Backup Retention を制御します。継続的なバックアップウィンドウは常に適用されるため、Atlas がクラスターをバックアップするかどうかは制御されません。
クラスターを作成したら、スナップショット保持ポリシーを構成できます。詳細については、「 バックアップ ポリシーの管理 」を参照してください。
終了保護
クラスターに対して Termination Protection を有効にするには、Termination Protection を Yes に切り替えます。
有効にすると、Atlas はユーザーによるクラスターの削除を防止します。終了保護が有効になっているクラスターを削除するには、まず終了保護を無効にする必要があります。デフォルトでは、Atlas はすべてのクラスターの終了保護を無効にします。
クラスターの終了の詳細については、「1 つの配置の終了」を参照してください。
シャーディングされたクラスターの配置
Tip
Atlas Core クラスターでは、コレクションをシャーディングたり、クラスター層をアップグレードしたりする代わりに、アクセス頻度の低いデータを Atlas クラスターからMongoDB が管理する読み取り専用フェデレーティッドデータベースインスタンスに移動するように Atlas Online アーカイブを構成できます。 Atlas Infinite クラスターでは、Atlas Online アーカイブ はpublic previewでサポートされていません 。 Atlas Online アーカイブの詳細については、「 Atlas Online Archive の管理 」を参照してください。
クラスターをシャーディングされたクラスターとして配置するには、Shard your cluster (M30 and up) を Yes に切り替えます。
重要
このページで説明されている機能は、public preview中に Atlas Infinite クラスターで現在サポートされていません。public previewでサポートされている機能については、「 パブリック プレビューの可用性 」を参照してください。
シャード化されたクラスターは、水平スケーリングをサポートし、シャード、構成サーバー、および mongos ルーターで構成されます。詳細については、「コンフィギュレーションサーバーの配置について」を参照してください。シャーディングされた読み取り操作が引き続き機能するために、コンフィギュレーションサーバーが読み取り可能な状態である必要があります。
Atlas 管理のコンフィギュレーションサーバーを有効にすると、Atlas は専用のコンフィギュレーションサーバーを使用する代わりに、コンフィギュレーションサーバーのデータをアプリケーションデータと同じ場所に設置する場合があります。詳細は、「シャーディングされたクラスターのための Atlas が管理するコンフィギュレーションサーバー」を参照してください。
シャード配置について
Atlas は各シャードを 3 ノードのレプリカセットとして配置します。各ノードは、構成された Cloud Provider & Region、Cluster Tier、および Additional Settings を使用して配置します。Atlas は、シャード ノードごとに 1 つの mongod を配置します。
クロスリージョン クラスターの場合、シャードあたりのノード数は、設定されたすべてのリージョンにわたる選挙可能なノードと読み取り専用ノードの合計数に等しくなります。Atlas は、選択したリージョンにシャード ノードを分散します。
コンフィギュレーションサーバーの配置について
専用コンフィギュレーションサーバーの場合、Atlas はコンフィギュレーションサーバーを 3 ノードのレプリカセットとして配置します。コンフィギュレーションサーバーは M30 のクラスター階層で動作します。マルチリージョンクラスターでは、コンフィギュレーションサーバーはリージョン全体に分散されます。
クロスリージョン クラスターの場合、Atlas は最適な可用性を確保するためにコンフィギュレーションサーバーのレプリカセット ノードを分散します。たとえば、Atlasは、選択したクラウド サービス プロバイダーとリージョン構成がサポートしていれば、3 つの異なるアベイラビリティーゾーンと 3 つの異なるリージョンにコンフィギュレーションサーバーを配置することができます。シャーディングされた読み取り操作が引き続き機能するために、コンフィギュレーションサーバーが読み取り可能な状態である必要があります。詳細については、「「コンフィギュレーションサーバーの可用性」を参照してください。
Atlas 管理のコンフィギュレーションサーバーを有効にすると、Atlas は専用のコンフィギュレーションサーバーを使用する代わりに、コンフィギュレーションサーバーのデータをアプリケーションデータと同じ場所に設置する場合があります。詳細は、「シャーディングされたクラスターのための Atlas が管理するコンフィギュレーションサーバー」を参照してください。
mongos 配置について
Atlas は、各シャード内の各ノードに対して 1 つのmongosルーターを配置します。クロス リージョン クラスターの場合、これにより、MongoDB ドライバーを使用するクライアントは、地理的に「最も近い」mongosに接続できます。
クラスター内のmongosルーターの数を計算するには、シャードの数にシャードあたりのレプリカセット ノードの数を掛けます。
シャーディングされたクラスターの配置をレプリカセットの配置に変換することはできません。
サーバー インスタンスの数がコストに与える影響の詳細については、「ノード数」を参照してください。
シャーディングされたクラスターの詳細については、MongoDB マニュアルの「シャーディング」を参照してください。
シャードの数を設定する
このフィールドは、配置がシャーディングされたクラスターである場合にのみ表示されます。
クラスターは、1 から 70 までのシャードを持つことができます。
レプリカセットをマルチシャーディングされたクラスターにスケール アップするには、まず単一のシャーディングされたクラスターにスケール アップし、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
レプリカセットクラスターを単一のシャーディングされたクラスターにスケール アップしたら、そのシャーディングされたクラスターで配置するシャードの数を設定できます。
シャーディングされたクラスター内のシャードの数を減らす場合、Atlas は "_id" フィールドの数に基づいてシャードを降順で削除します（「シャーディングされたクラスターの構成」を参照）。たとえば、次の 3 つのシャードを含むシャーディングされたクラスターを考えてみます。
"shard0""shard1""shard2"
シャードの数を 2 に設定すると、Atlas はクラスターから "shard2" を削除します。
重要: 8.0 でシャードを削除すると、Atlas は moveCollection コマンドを使用して、そのシャード内のシャーディングされていないコレクションを残りのシャードに移動します。このプロセス中、シャーディングされていないコレクションはすべてオンラインのままになります。
すべてのシャーディングされたコレクションは、シャード削除プロセス中もオンラインのままとなり、利用可能です。削除されたシャードからシャーディングされたコレクションを空にするには、バランサーをオンにする必要があります。
Atlas は、移動プライマリ コマンドを使用して、
moveCollectionコマンドでドレインできないシャーディングされていないコレクションを移動します。moveCollectionの制限の詳細については、制限を参照してください。movePrimaryは オフライン操作です。シャード削除の詳細については、 シャードクラスタからシャードを削除する を参照してください。
レプリカセットをクラスターに変換する場合の考慮事項
クラスター階層が M30 以上の場合は、レプリカセットをクラスターに変換できます。
単数形のレプリカセットクラスターを複数シャードのシャーディングされたクラスターに変換するには、まず単一のシャード シャーシャーディングされたクラスターに変換し、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再起動しないと、Atlas によってシャード間でのデータ分散が開始された後、データの整合性が失われる可能性があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
DNS シードリスト接続文字列を使用している場合、アプリケーションがシャーディングされたクラスターの
mongosに自動的に接続されます。標準の接続文字列を使用している場合は、新しいクラスター トポロジーを反映するように接続文字列を更新する必要があります。
MongoDB 8.3 以降、DDL 操作 と applyOps は、すべてのシャーディングされたクラスターの mongos でのみ実行できます。レプリカセットからシャーディングされたクラスターに移行している間は、これらの操作が一時的に利用できなくなることがあります。
変換した後、コレクションを シャーディング し、シャード間でデータを分散するために適切なシャードキーを選択する必要があります。詳細については、「クラスターへのレプリカセットの変換」を参照してください。
注意
レプリカセットをシャーディングされたクラスターに変換すると、Atlas が管理するコンフィギュレーションサーバーが有効になっている場合でも、結果のクラスターは常に専用のコンフィギュレーションサーバーを使用します。変換後に埋め込みコンフィギュレーションサーバーが必要な場合は、MongoDB サポート にお問い合わせください。
インテリジェントなワークロード管理の構成
インテリジェント ワークロード マネジメント（IWM）は、 MongoDB Atlasが管理する可用性システムであり、過負荷下でも Atlas クラスターの応答性と予測可能性を維持します。過負荷は、クラスターが処理できる以上の受信操作を受け取った場合に発生します。
セクションは Intelligent Workload ManagementM10以上のクラスターで使用できます。これにはLoad SheddingM30+ 設定が含まれています。この設定はMongoDB9.0 以降を実行中 レプリカセットクラスターでのみ有効です。ロード シード処理は、プロセスが持続的に過負荷に該当する場合に、受信側の プロセスで受信データベース操作を拒否する IWM（Integermongod Workload Management、インテリジェント ワークロード管理）保護を制御します。操作を拒否しないその他の 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 Interface を使用すると、フェデレーティッドデータベースインスタンスは必要なく、ODBC および JDBC ドライバーを介してTableauや Power BIなどのBIツールからクラスターにクエリを実行できます。 SQL InterfaceM10 は、 MongoDB 以降を実行中専有クラスター（6.0 以上）で有効にできます。
トグルは、適格なクラスターのクラスター構成フォームにのみ表示されます。要件の完全なリストと、フェデレーティッドデータベースインスタンスとの直接接続を比較するには、 MongoDB SQL Interface の概要 を参照してください。
Atlas Administration APIを使用してSQL Interface を有効および無効にすることもできます。詳細については、 SQLインターフェイスドキュメントの「 サーバー設定 」ページを参照してください。
BI Connector for Atlas アベイラビリティー
重要
Atlas およびオンプレミス用のMongoDB Connector for Business Intelligence は、9 月 のサポート終了（EOL）に達し、サポートされなくなりました。2026 MongoDB SQL Interface を使用して、Atlas または Enterprise Advanced 配置に接続します。 SQL Interface は、別のBI Connectorインスタンスを必要とせずに、クラスターへのより簡単で直接的な接続を提供し、パフォーマンスの向上、簡素化された設定、および機能の強化を提供します。詳細については、 「 MongoDB SQL Interface の概要 」を参照してください。
クラスター構成フォームは、次の EOL に達したため、 BI Connector for Atlas を制限します。
BI Connector for Atlas がクラスターでまだ有効になっていない場合、Enable Business Intelligence Connector セクションは表示されず、有効にすることはできません。
BI Connector for Atlas がすでに有効になっている場合は、 セクションに非推奨通知が表示され、 BI Connector for Atlas をオフにすることのみができます。無効にした後、有効にすることはできません。 Review Changes ページにも同じ通知が表示されます。
代わりにMongoDB SQL Interface（Atlas 専用）を使用することをお勧めします。既存のBI Connector for Atlasワークロードを全体に移動するには、移行ガイド を参照してください。
独自の暗号化キーの管理
注意
この機能はM10 以上のクラスターで使用できます。無料クラスターで使用できる機能の詳細については、「 Atlas 無料クラスターの制限 」を参照してください。Flex クラスターの場合は、「 Atlas Flex 制限 」を参照してください。
Atlas では、すべてのクラスター ストレージとスナップショット ボリュームを暗号化し、保管中のすべてのクラスター データのセキュリティを確保します（保管時の暗号化）。Atlas Project Ownersでは、MongoDB暗号化ストレージ エンジンおよび Atlas と互換性のある保管時の暗号化プロバイダーを使用して、保管中のデータに追加の暗号化レイヤーを構成できます。
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 が使用する暗号化のキーやキー管理プロバイダーの認証情報を変更、削除、または無効化する前に、細心の注意を払ってください。
追加オプションの構成
M10+有料階層クラスター上では、次のmongodランタイム オプションを構成できます。
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]
コマンドの構文とパラメータの詳細については、Atlas CLI ドキュメントの atlas clusters advancedSettings update を参照してください。
Atlas Infinite クラスターでは、代わりに atlas api clusters updateClusterAdvancedConfiguration を使用します。 atlas clusters コマンドは、Atlas Infinite フィールドを含まない固定オプションセットを受け入れます。
これらの設定を Atlas UI で表示および編集するには、クラスター フォームのAdditional Settings の下にある More Configuration Options を開きます。
Atlas Core AWSクラスターのクロスリージョン最初の同期の高速化
注意
この機能は Atlas Infinite には適用されません。 Atlas Infinite の機能と動作の詳細については、 「 MongoDB Atlas Infinite: 概要 」を参照してください。
Atlas では、AWS リージョンに新しいノードを追加すると、クラウドベースの最初の同期を実行してソース ノードのスナップショットを作成し、AWS のネイティブなスナップショット機能を使用してそのスナップショットを新しいノードに復元します。
この設定を有効にすると、Atlas はAWS時間ベースのスナップショット コピーを使用して、ソースノードとは異なるAWSリージョンにある宛先AWSノードのクラウドベースの最初の同期を実行します。 Atlas は、データの最新性を最大限に高めるために、セカンダリ500 ノードよりもプライマリノードからの復元を優先します。時間ベースのスナップショット コピー操作では、 MiB/s の最大コピー操作スループットが実現できます。 Atlas は、スナップショットのサイズに基づいてコピー操作の完了時間を調整することで、常にスループットを最大化します。
Atlas は、 AWSおよび Google Cloud クラスターのみのクロスリージョン クラウドベースの最初の同期をサポートしています。 Azureクラスターの場合、Atlas は論理的な最初の同期を実行して新しいリージョンにノードを追加します。クラスター構成を編集するときに、クラスター内のノードを追加または置換できます。
この設定は、少なくとも 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 を使用します。
Set the adaptiveCapacity field.
リクエスト ボディでは、トップレベルの adaptiveCapacity フィールドを次のいずれかの値に設定します。
値 | 説明 |
|---|---|
| Atlas は、キャパシティーが不足している場合、使用可能なキャパシティーを持つ代替インスタンスタイプでクラスターをプロビジョニングできます。Atlas は、Microsoft Azure クラスターについて、この値をデフォルトで使用します。 |
| Atlas は、クラスターを元のインスタンスタイプに保持します。 |
adaptiveCapacity更新リクエストで フィールドを省略すると、Atlas は現在の設定を変更しません。単一クラウドのAWSまたはadaptiveCapacity Google Cloud クラスターで を設定しても効果はありません。
最小 oplog window の設定
クラスターのoplog内にあるoplogエントリの保持期間を変更します。デフォルトでは 、Atlas24 が Atlas Infinite と Atlas Core でmongod 時間エントリを保持した後、 はoplogからそれらを削除します。
このオプションは、クラスター内の各mongodのstorage.oplogMinRetentionHours 構成ファイル オプションの変更に対応します。
最小 oplog window を設定するには、次の手順を行います。
ストレージのオートスケーリングが有効になっており、オプトアウトしていないことを確認します。Atlas ではデフォルトでオートスケーリングが有効になっています。
最小oplog ウィンドウ を任意の値に設定します。この値を設定しない場合、Atlas が24 Atlas Infinite と Atlas Core でoplogエントリを
mongod時間保持した後、 が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 サイズとレプリケーションラグ時間を確認するには
mongosh経由でクラスターに接続します。Atlas adminロールを持つユーザーとして認証します。rs.printReplicationInfo()メソッドを実行します。
Atlas では、現在の oplog サイズとレプリケーションラグ時間を表示します。
固定 oplog サイズを設定するには、次の手順を行います。
最小 Oplog Window を
0に設定します。必要な oplog のサイズを決定します。
Atlas UI で移行プロセス中のラグ時間を監視します。
移行中、Atlas UI に表示されるラグ時間が
rs.printReplicationInfo()メソッドを使用して取得したレプリケーションラグに近づく場合は、oplog サイズを増やします。
入力ボックスに、任意のOplog Sizeを指定します（メガバイト単位）。 この設定では、ディスク上のサイズではなく、oplog の非圧縮サイズが構成されます。
シャーディングされたクラスターの配置の場合、このオプションによりクラスター内の各シャードの oplog サイズが変更されます。
このオプションは、クラスター内の各
mongodのreplication.oplogSizeMB構成ファイル オプションの変更に対応します。警告
oplog のサイズを小さくするには、oplog からデータを削除する必要があります。Atlas は、oplog の削減の結果として削除された oplog エントリにアクセスしたり、復元したりすることはできません。oplog を削減する前に、このデータ損失の影響を考慮してください。
ディスク容量に関する考慮事項
使用可能なディスク容量を増やすために oplog のサイズを小さくしないでください。oplog サイズを縮小することで節約されるスペースは、oplog コレクション（local.oplog.rs）のみが再利用できます。他のコレクションには、oplog ストレージを削減することによるメリットはありません。
サーバーサイド JavaScript を許可する
JavaScript をサーバー側で実行する操作の実行を有効または無効にします。
MongoDB 5.0未満のバージョンでクラスターを実行する場合、このオプションはクラスター内の各
mongodのsecurity.javascriptEnabled構成ファイル オプションの変更に対応します。MongoDB バージョン5.0以上でクラスターを実行している場合、このオプションは、クラスター内の各
mongodおよびmongosのsecurity.javascriptEnabled構成ファイル オプションの変更に対応します。
注意
MongoDB バージョン 7.0 以降では、security.javascriptEnabled は mongos にも適用されます。
冗長化および匿名化されたクエリ データのログを有効にする
編集され匿名化された $queryStats 出力を MongoDB ログに含めます。$queryStats 出力にはリテラル値またはフィールド値が含まれていません。この設定を有効にすると、クラスターのパフォーマンスに影響を与える可能性があります。
注意
クエリ データのロギングは、MongoDB 7.1 以降を実行する Atlas クラスターでのみ有効にできます。
TLS プロトコルの最小バージョンの設定
着信接続に対してクラスターが許可する最小 TLS バージョンを設定します。このオプションは、クラスター内の各 mongodに対するnet.tls.disabledProtocols 構成ファイル オプションの構成に対応します。
重要: Atlas は1.0 1.1TLS1.0 または1 のサポートを終了しました。 TLS または.1 を使用した接続試行をすべてのクラスターが拒否します。クラスターの最小 TLS 1バージョンを.2 以上に設定します。
カスタム暗号スイート構成の設定
暗号スイートのリストから、クラスターのノード間通信およびクライアントと Atlas 間の通信に使用する暗号スイートを選択してください。使用可能な暗号のリストは、クラスターの最小 TLS バージョンによって異なります。
注意
カスタム TLS 1.2 暗号構成があり、TLS 1.3 にアップグレードする場合は、構成を更新して TLS 1.3 暗号を含める必要があります。
すべてのクエリにインデックスが必要
重要
このページで説明されている機能は、public preview中に Atlas Infinite クラスターで現在サポートされていません。public previewでサポートされている機能については、「 パブリック プレビューの可用性 」を参照してください。
コレクションスキャンが結果を返すために必要なクエリの実行を有効または無効にします。このオプションは、クラスター内の各mongodに対するsetParameterコマンドを介したnotablescanパラメーターの変更に対応します。
重要
MongoDB Search インデックスを作成している場合は、このパラメーターを無効にする必要がある場合があります。詳しくは、 「 MongoDB Search インデックスに関する考慮事項 」を参照してください。
デフォルトの書込み保証 (write concern)
Atlas Infinite クラスターではデフォルトの書込み保証 (write concern)を設定できません。 Atlas Infinite クラスターで書込み保証 (write concern)がどのように機能するかについては、「 Atlas Infinite クラスターの書込み保証（write concern） 」を参照してください。
このクラスターの書込み (write) 操作に対して MongoDB から要求される確認応答のデフォルト レベルを設定します。
クラスターのデフォルトの書込み保証 (write concern)は過半数です。
トランザクションの有効期間を設定する
重要
このページで説明されている機能は、public preview中に Atlas Infinite クラスターで現在サポートされていません。public previewでサポートされている機能については、「 パブリック プレビューの可用性 」を参照してください。
マルチドキュメントトランザクションの最大有効期間を設定します。このオプションは、クラスター内の各 mongod に対する setParameter コマンドを介した transactionLifetimeLimitSeconds パラメーターの変更に対応します。
重要
トランザクションの有効期間を 1 秒未満に設定することはできません。
クラスターのデフォルトのトランザクション有効期間は 60 秒です。
高速ディスク事前ウォーミングの有効化または無効化
注意
この機能は Atlas Infinite には適用されません。 Atlas Infinite の機能と動作の詳細については、 「 MongoDB Atlas Infinite: 概要 」を参照してください。
Atlas では、Fast Disk Pre-Warming AWSとAzureでホストされているクラスターに対して 設定を提供しています。 Atlas はこれらのクラスターに対してデフォルトで高速ディスク事前ウォーミングを有効にします。
AWSまたはAzureクラスターの高速ディスク事前ウォーミングを無効にするには、 OffFast Disk Pre-Warming設定の下で を選択します。再度有効にするには、Fast Pre-Warming (Default) を選択します。
基礎のクラウドプロバイダーのインフラストラクチャの設計により、Atlas が クラウドベースの最初の同期 を実行するたびに、ディスクの事前ウォーミングが行われます。たとえば、Atlas がクラスター内の既存のリージョンに新しいノードを追加する場合などです。クラウドベースの最初の同期中に、Atlas は新しいノードを一時的に非表示にし、準備ができるまで読み取りを処理しないようにします。
高速ディスク事前ウォーミングは、バックグラウンド ディスク ウォーミングよりも高速です。高速ディスク事前ウォーミングが有効になっている場合、新しいノードは事前ウォーミング中にプロビジョニングされた IOPS のほとんどを消費するため、Atlas は事前ウォーミングが完了するまでノードを非表示にします。高速ディスク事前ウォーミングが無効になっている場合、Atlas はノードが準備できるとすぐにノードを再表示し、バックグラウンドでディスクをウォームアップすることで、ノードがより早く表示されるようになります。
NVMeストレージ M40+を使用しない AWSクラスターでは、Atlas は クラウドベースの最初の同期中に高速ディスク事前ウォーミングをサポートするために、よりパフォーマンスのAWSストレージボリュームを一時的にプロビジョニングします。ディスクの事前ウォーミングが完了すると、Atlas はボリュームを変更し、ノードの元のストレージ設定に戻ります。この変更では、 AWS が 時間の各 EBS ボリュームに対して許可する 4 つの EBS24 ボリューム変更のいずれかを使用します。 EBS ボリュームの変更制限の詳細については、「 AWSにおけるストレージ容量または IOPS の変更 」を参照してください。
よりパフォーマンスの高い一時ストレージボリュームをプロビジョニングすると、Atlas の月間請求でクラスターのストレージコストが一時的に増加する可能性があります。詳細については、「 ストレージ容量 」を参照してください。
次の推奨事項を検討してください。
一貫したクエリ レイテンシを求めるワークロードがある場合は、この設定を有効にします。
一貫したクエリ パフォーマンスによる最大限の可用性の保証を求めるワークロードがあり、新しく追加または交換されたノードをすぐにアクティブにして表示できるようにする必要がある場合は、事前ウォーミングプロセスが完了するまで、この設定を無効にし、事前ウォーミングを行うノードのタグを含むカスタム接続文字列を使用します。この接続文字列を使用すると、ノードでの読み取りが防止されますが、IOPS のほとんどが事前ウォーミング プロセスによって使用されます。
読み取り操作のデフォルトタイムアウトを設定する
MongoDB のバージョン 8.0 以降を実行しているクラスターの場合、これらのクラスターのすべての読み取り操作の、デフォルトの最大タイムアウトをミリ秒単位で指定できます。これにより、データベースを意図せず長時間実行されるクエリから保護します。このオプションは、クラスター パラメータの defaultMaxTimeMS に対応します。
レプリカセット スケーリング モードの構成
注意
この機能は Atlas Infinite には適用されません。 Atlas Infinite の機能と動作の詳細については、 「 MongoDB Atlas Infinite: 概要 」を参照してください。
クラスターのレプリカセットスケーリングモードを変更します。Atlas はデフォルトで拡大モードIn Parallel By Workload Type を使用します。Atlas は、In Parallel By Node Type モードと Sequential モードを使用してレプリカセットを増やすこともできます。
次のリストでは、使用可能なスケーリング モードについて説明します。
In Parallel By Workload Type モードは、読み取り専用の運用ノードと分析ノードを持つクラスターにのみ適用されます。別の 拡大モードを指定しない限り、Atlas はデフォルトでこの拡大モードを使用します。このモードでは 、Atlas は分析ノードを運用ノードと並行して拡張します。
注意
クラスターに選挙可能なノードしかない場合、拡大モードIn Parallel By Workload Type はクラスターの動作に影響を与えません。
Sequential モードは、定常状態のワークロードとレイテンシのセカンダリ読み取りを実行するアプリケーション用です。このモードでは 、Atlas はすべてのノードを順番にスケーリングします。
ログ リダクションを有効にする
これをオンに切り替えると、潜在的に機密性の高い情報がログに記録されなくなります。詳しくは、「ログ リダクション」を参照してください。
ログリダクションを有効および無効にするには、ローリング再起動が必要です。
シャーディングされたクラスターの Atlas 管理設定サーバ
新しいシャーディングされたクラスターの コンフィギュレーションサーバー タイプの Atlas の管理を有効または無効にします。Atlas が管理するコンフィギュレーションサーバーは、最適なパフォーマンスとコスト削減の基準に基づいてコンフィギュレーションサーバーの種類を自動的に切り替えます。シャーディングされたクラスターで Atlas が管理するコンフィギュレーションサーバーを有効にしない場合、Atlas は常にクラスター専用のコンフィギュレーションサーバーを使用します。
すべての 8.0 Atlas のシャーディングされたクラスター、Atlas コンフィギュレーションサーバーサーバーは、デフォルトで On です。Atlas 管理のコンフィギュレーションサーバーを無効にするには、トグルを Off に設定します。クラスターのシャードが6つ未満で、コンフィギュレーションサーバーが組み込まれている場合、Atlas 管理のコンフィギュレーションサーバーをオフにすると、クラスターは直ちに専用のコンフィギュレーションサーバーに移行します。
注意
組み込み型コンフィギュレーションサーバーまたはコンフィギュレーションシャードは、グローバルクラスターではサポートされていません。
コンフィギュレーションサーバーのタイプ
Atlas が管理するコンフィギュレーションサーバーが有効になっている新しいシャーディングされたクラスターごとに、シャードが 6 未満のクラスターには埋め込みコンフィギュレーションサーバーを配置し、シャードが 5 つを超えるクラスターには専用のコンフィギュレーションサーバーを配置します。
組み込みコンフィギュレーションサーバーは、アプリケーションデータをコンフィギュレーションシャード上の構成データと同じ場所に配置します。組み込みコンフィギュレーションサーバー クラスターは使用するリソースが少ないため、コストが低くなります。
専用コンフィギュレーションサーバーは、構成データ用に別の専用コンフィギュレーションサーバーのレプリカセットを使用します。アプリケーションデータは、専用コンフィギュレーションサーバーの構成データと同じ場所に配置されません。専用のコンフィギュレーションサーバー クラスターは、追加のレプリカセットを使用するため、コストが高くなります。
コンフィギュレーションサーバーの種類に関する詳細な考慮事項については、「コンフィギュレーションサーバーの考慮事項」を参照してください。
コンフィギュレーションサーバーの変更基準
Atlas 管理のコンフィギュレーションサーバーを有効にする場合、Atlas は初期クラスターのコンフィギュレーションサーバーのタイプを次のように決定します。
クラスターのシャード数が 5 を超える場合、Atlas は専用のコンフィギュレーションサーバーを使用します。
クラスター シャード数が 5 以下の場合、Atlas は埋め込みコンフィギュレーションサーバーを使用します。
Atlas 管理のコンフィギュレーションサーバーを有効にしてシャードを追加または削除すると、Atlas は自動的に同じ基準で、シャーディングされたクラスターのコンフィギュレーションサーバーの種類を再選択します。
既存のシャーディングされたクラスターをMongoDB 7.0 から 8.0 にアップグレードすると、Atlas は Atlas が管理するコンフィギュレーションサーバーをオンにしますが、クラスターの既存のコンフィギュレーションサーバーのタイプは変更されません。これらの基準は、シャード数の変更にのみ適用されます。
コンフィギュレーションサーバーに関する考慮事項
MongoDB 8.0 より前のバージョンのすべてのクラスターは、専用のコンフィギュレーションサーバーを使用します。
次の機能のいずれかを使用する場合、Atlas はコンフィギュレーションサーバーのタイプを変更しません。
クラスターにシャードが 5 つ以上あり、これらの機能を使用しているため専用のコンフィギュレーションサーバーに移行できない場合は、MongoDB サポートに問い合わせてコンフィギュレーションサーバーのタイプを変更してください。
Atlas 管理のコンフィギュレーションサーバーを有効にする場合は、次の考慮事項が該当します。
MongoDB 8.0 以降を実行しているクラスターでは、レプリカセット ID にはレプリカセットに保存されているデータのタイプが反映されません。
レプリカセット ID に
shardが含まれるレプリカセットには、アプリケーションデータと構成データ、またはその両方が保存される場合があります（例:atlas-abc123-shard-0）。レプリカセット ID に
configが含まれるレプリカセットには、アプリケーションデータが保存される場合があります（例:atlas-abc123-config-0）。
バックアップ スナップショットに関する考慮事項
専用コンフィギュレーションサーバーのあるクラスターのスナップショットは、同じく専用コンフィギュレーションサーバーを使用するクラスターにのみ復元できます。
組み込みコンフィギュレーションサーバーのあるクラスターのスナップショットは、同じく組み込みコンフィギュレーションサーバーを使用するクラスターにのみ復元できます。