追加設定の構成

リリース ケイデンスの選択

Atlas クラスターをメジャー リリース ケイデンスまたは Rapid Release ケイデンスのいずれかに従うように設定できます。

無料階層クラスターと共有階層クラスターは、メジャー リリースのケイデンスに従う必要があります。クラスター フォームの Additional Settings セクションのドロップダウンから特定の MongoDB バージョンを選択することで、メジャー リリースのケイデンスに従うように専用階層クラスターを構成できます。

Atlas はメジャー リリース ケイデンスでクラスターを自動的にアップグレードしません。新しいメジャー リリースが一般公開されるたびに、手動でアップグレードをスケジュールする必要があります。

クラスター フォームの Additional Settings セクションのドロップダウンから Latest Release を選択することで、Rapid Release のケイデンスに従うように専用の階層クラスターを構成できます。

クラスターを Rapid Release 用に設定できるのは、MongoDB の最新のメジャー リリースを実行している場合に限られます。クラスターが以前のメジャー リリースを実行している場合は、最新のメジャー リリースに手動でアップグレードして、Rapid Release に以降できるようにします。

Atlas は、Rapid Release ケイデンスに従うクラスターに最新の MongoDB リリースを使用します。Atlas はクラスターの可用性を維持するため、各リリースが利用可能になるたびにローリングプロセスを通じてこれらのクラスターを新しいメジャー リリース バージョンおよび Rapid Release バージョンに自動的にアップグレードします。次の Rapid Release バージョンへのアップグレード中に、Atlas UI のClusters ページのクラスターに、MongoDB バージョンではなくクラスターの FCV が表示される場合があります。これは、クラスターで現在使用可能な機能を反映するためです。

Select a Version ドロップダウン メニューから最新のメジャー リリースを選択すると、Rapid Release のケイデンスに従っているクラスターをメジャー リリースのケイデンスに戻すことができます。ただし、これができるのは、当年の最初の Rapid Release が利用可能になる前までです。クラスターがメジャー リリース バージョンから Rapid Release に更新されたら、次のメジャー リリースまでクラスターを元に戻すことはできません。

MongoDB のバージョンの詳細については、MongoDB マニュアルの「MongoDB のバージョン管理」を参照してください。Rapid Release ケイデンスに関する詳細については、「MongoDB Stable API と Rapid Release のケイデンスの理解」を参照してください。

M2/M5 階層バックアップ オプション

Atlas はM2とM5共有クラスターのバックアップを自動的に有効にし、無効にすることはできません。詳細については、「共有クラスターのバックアップ 」を参照してください。

M10+ 階層 バックアップ オプション

M10+ Atlas クラスターのバックアップを有効にするには、Turn on Backup (M10 and up) を Yes に切り替えます。有効にすると、Atlas は定期的にデータベースのスナップショットを取得し、プロジェクトの保持ポリシーに従って保持します。

Atlas は、M10+ クラスターに対して次のバックアップ オプションを提供します。

シャード配置について

Atlas は各シャードを 3 ノードのレプリカセットとして配置します。各ノードは、構成された Cloud Provider & Region、Cluster Tier、および Additional Settings を使用して配置します。Atlas は、シャード ノードごとに 1 つの mongod を配置します。

クロスリージョン クラスターの場合、シャードあたりのノード数は、設定されたすべてのリージョンにわたる選挙可能なノードと読み取り専用ノードの合計数に等しくなります。Atlas は、選択したリージョンにシャード ノードを分散します。

コンフィギュレーションサーバーの配置について

専用コンフィギュレーションサーバーの場合、Atlas はコンフィギュレーションサーバーを 3 ノードのレプリカセットとして配置します。コンフィギュレーションサーバーは M30 のクラスター階層で動作します。マルチリージョンクラスターでは、コンフィギュレーションサーバーはリージョン全体に分散されます。

クロスリージョン クラスターの場合、Atlas は最適な可用性を確保するためにコンフィギュレーションサーバーのレプリカセット ノードを分散します。たとえば、Atlasは、選択したクラウド サービス プロバイダーとリージョン構成がサポートしていれば、3 つの異なるアベイラビリティーゾーンと 3 つの異なるリージョンにコンフィギュレーションサーバーを配置することができます。シャーディングされた読み取り操作が引き続き機能するために、コンフィギュレーションサーバーが読み取り可能な状態である必要があります。詳細については、「「コンフィギュレーションサーバーの可用性」を参照してください。

Atlas 管理のコンフィギュレーションサーバーを有効にすると、Atlas は専用のコンフィギュレーションサーバーを使用する代わりに、コンフィギュレーションサーバーのデータをアプリケーションデータと同じ場所に設置する場合があります。詳細は、「シャーディングされたクラスターのための Atlas が管理するコンフィギュレーションサーバー」を参照してください。

シャーディングされたクラスター内の最も優先度の高いリージョンに影響するリージョン停止時またはリージョン停止時シミュレーションにより、クラスターが読み取り操作を実行できなくなる可能性があります。コンフィギュレーションサーバーを復元するには、次の手順を実行します。

• セカンダリ ノードの読み込みクエリに適した読み込み設定 (read preference) を構成します。

• 選挙可能なノードを取り戻すようにクラスターを再構成します。

mongos 配置について

Atlas は、各シャード内の各ノードに対して 1 つのmongosルーターを配置します。クロス リージョン クラスターの場合、これにより、MongoDB ドライバーを使用するクライアントは、地理的に「最も近い」mongosに接続できます。

クラスター内のmongosルーターの数を計算するには、シャードの数にシャードあたりのレプリカセット ノードの数を掛けます。

シャーディングされたクラスターの配置をレプリカセットの配置に変換することはできません。

サーバー インスタンスの数がコストに与える影響の詳細については、「ノード数」を参照してください。

シャーディングされたクラスターの詳細については、MongoDB マニュアルの「シャーディング」を参照してください。

シャードの数を設定する

このフィールドは、配置がシャーディングされたクラスターである場合にのみ表示されます。

クラスターは、1 から 100 までのシャードを持つことができます。

レプリカセットをマルチシャーディングされたクラスターにスケール アップするには、まず単一のシャーディングされたクラスターにスケール アップし、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。

アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。

レプリカセットクラスターを単一のシャーディングされたクラスターにスケール アップしたら、そのシャーディングされたクラスターで配置するシャードの数を設定できます。

シャーディングされたクラスター内のシャードの数を減らす場合、Atlas は "_id" フィールドの数に基づいてシャードを降順で削除します（「シャーディングされたクラスターの構成」を参照）。たとえば、次の 3 つのシャードを含むシャーディングされたクラスターを考えてみます。

• "shard0"

• "shard1"

• "shard2"

シャードの数を 2 に設定すると、Atlas はクラスターから "shard2" を削除します。

実稼働環境では、単一のシャードを含むシャーディングされたクラスターを作成しないでください。 単一シャードのシャード クラスターでは、マルチシャード構成と同じ利点は得られません。 単一シャード クラスターを作成したら、アプリケーションを再起動し、クラスターに再接続して、クラスターにシャードを追加します。

レプリカセットをシャーディングされたクラスターにアップグレードする場合の考慮事項

クラスター階層が M30 以上の場合は、レプリカセットの配置をシャーディングされたクラスターの配置にアップグレードできます。

レプリカセットをマルチシャーディングされたクラスターにスケール アップするには、まず単一のシャーディングされたクラスターにスケール アップし、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。

アプリケーション クライアントを再起動しないと、Atlas によってシャード間でのデータ分散が開始された後、データの整合性が失われる可能性があります。

アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。

• DNS シードリスト接続文字列を使用している場合、アプリケーションがシャーディングされたクラスターの mongos に自動的に接続されます。

• 標準の接続文字列を使用している場合は、新しいクラスター トポロジーを反映するように接続文字列を更新する必要があります。

読み込み設定（read preference）

次の表では、BI Connector で使用可能な読み込み設定 (read preference) と、それに対応する readPreference 接続文字列オプションおよび readPreferenceTag 接続文字列オプションについて説明しています。

サンプリング設定

リレーショナル スキーマを生成するには、BI Connector に MongoDB からのサンプリング データが必要です。

.drdl ファイルを使用したり、mongodrdl コマンドを使用して Atlas BI Connector のサンプリング ステージを置き換えたりすることはできません。

構成可能なサンプリング設定は以下の通りです。

前提条件

• Atlas クラスターでこの機能を有効にする前に、使用しているキー管理を使用して Atlas プロジェクトの保管時の暗号化を設定する必要があります。詳細については、「カスタマー キー 管理を使用した保管時の暗号化」を参照してください。

• クラスターの保管時の暗号化のプロバイダーを別のプロバイダーに切り替えるには、まずクラスターの保管時の暗号化のプロバイダーを無効にし、その後に変更先の保管時の暗号化のプロバイダーで再度有効にする必要があります。詳細については、「カスタマー キー 管理を使用した保管時の暗号化」を参照してください。

手順

このクラスターの独自の暗号化のキーの管理を開始するには、Encryption using your Key Management (M10 and up) を Yes に切り替えてください。

キー管理を使用した Atlas Encryption at Rest は、 M10+レプリカセット クラスターで利用できます。Atlas Encryption at Rest は、クラスターのバックアップの暗号化のみをサポートします。レガシーバックアップ（非推奨）を使用してクラスター上で保管時の暗号化を有効にすることはできません。

独自の暗号化のキーを管理すると、クラスターの 1 時間あたりの運用コストが上昇します。高度なセキュリティ機能に対する Atlas の課金の詳細については、「高度なセキュリティ」を参照してください。

Considerations

Atlas はレプリカセットとシャーディングされたクラスターの Oplog Size を動的に変更します。ただし、Minimum TLS Protocol Version と Allow Server-Side JavaScript の設定では、シャード ノードとコンフィギュレーションサーバーのレプリカセットのローリング再起動が実行されます。Atlas がメンテナンス操作中に高可用性をサポートする方法の詳細については、「MongoDB Atlas ではどのようにして高可用性が実現されますか」を参照してください。

追加設定の表示と編集

これらの設定を表示および編集する方法は、次のとおりです。

atlas clusters advancedSettings update <clusterName> [options]

最小 oplog window の設定

クラスターの oplog 内にある oplog エントリの保持期間を変更します。デフォルトでは、Atlas がエントリを24時間保持した後、mongodが oplog からそれらを削除します。

このオプションは、クラスター内の各mongodのstorage.oplogMinRetentionHours 構成ファイル オプションの変更に対応します。

最小 oplog window を設定するには、次の手順を行います。

1. ストレージのオートスケーリングが有効になっており、オプトアウトしていないことを確認します。Atlas ではデフォルトでオートスケーリングが有効になっています。

2. 最小 oplog window を任意の値に設定します。この値を設定しない場合、Atlas が oplog エントリを24時間保持した後、mongodが oplog からそれらを削除します。

Oplog サイズの設定

固定の oplog サイズを設定できるため、ライブ移行中や集中的なデータ読み込み時に役立ちます。

Set Oplog Size 構成設定は、クラスターのストレージ オートスケーリングをオプトアウトした場合にのみ設定できます。

ストレージのオートスケーリングが有効になっているクラスターでは、代わりに Minimum Oplog Window を設定できます。詳しくは、最小 Oplog Window の設定を参照してください。Atlas では、ストレージのオートスケーリングはデフォルトで有効になっています。

設定できる oplog の最小サイズは 990 メガバイトです。選択した oplog サイズによってクラスターのディスクの空きキャパシティーが 25% 未満になった場合、Atlas はエラーを返します。

現在の oplog サイズとレプリケーションラグ時間を確認するには

1. mongosh経由でクラスターに接続します。

2. Atlas admin ロールを持つユーザーとして認証します。

3. rs.printReplicationInfo()メソッドを実行します。

Atlas では、現在の oplog サイズとレプリケーションラグ時間を表示します。

固定 oplog サイズを設定するには、次の手順を行います。

1. ストレージの自動スケーリングをオプトアウトします。

2. 最小 Oplog Window を0に設定します。

3. 必要な oplog のサイズを決定します。

   • Atlas UI で移行プロセス中のラグ時間を監視します。

   • 移行中、Atlas UI に表示されるラグ時間がrs.printReplicationInfo()メソッドを使用して取得したレプリケーションラグに近づく場合は、oplog サイズを増やします。

4. 入力ボックスに、任意のOplog Sizeを指定します（メガバイト単位）。 この設定では、ディスク上のサイズではなく、oplog の非圧縮サイズが構成されます。

   シャーディングされたクラスターの配置の場合、このオプションによりクラスター内の各シャードの oplog サイズが変更されます。

   このオプションは、クラスター内の各mongodのreplication.oplogSizeMB 構成ファイル オプションの変更に対応します。

   警告

   oplog のサイズを小さくするには、oplog からデータを削除する必要があります。Atlas は、oplog の削減の結果として削除された oplog エントリにアクセスしたり、復元したりすることはできません。oplog を削減する前に、このデータ損失の影響を考慮してください。

インデックス キー制限の強制

1024 バイトのインデックス キー制限の適用を有効または無効にします。ターゲット コレクションのすべてのインデックス付きフィールドで、対応するインデックスエントリが 1024 バイトを超えない場合にのみ、ドキュメントを更新または挿入できます。

無効にすると、mongodは制限を超えるドキュメントを書き込みますが、インデックスは作成しません。このオプションは、クラスター内のmongod に対するsetParameter コマンドを介したparam.failIndexKeyTooLong パラメーターの変更に対応します。

サーバーサイド JavaScript を許可する

JavaScript をサーバー側で実行する操作の実行を有効または無効にします。

• MongoDB 5.0未満のバージョンでクラスターを実行する場合、このオプションはクラスター内の各mongodのsecurity.javascriptEnabled 構成ファイル オプションの変更に対応します。

• MongoDB バージョン5.0以上でクラスターを実行している場合、このオプションは、クラスター内の各mongodおよびmongosのsecurity.javascriptEnabled 構成ファイル オプションの変更に対応します。

• MongoDBバージョン 8.0 を実行しているクラスターの場合、セキュリティとパフォーマンスを向上させるために、Allow Server-Side JavaScript はデフォルトで無効になっています。このオプションは、クラスター内の各 mongod と mongos の security.javascriptEnabled 構成ファイルオプションに対応します。

冗長化および匿名化されたクエリ データのログを有効にする

編集され匿名化された $queryStats 出力を MongoDB ログに含めます。$queryStats 出力にはリテラル値またはフィールド値が含まれていません。この設定を有効にすると、クラスターのパフォーマンスに影響を与える可能性があります。

TLS プロトコルの最小バージョンの設定

着信接続に対してクラスターが許可する最小 TLS バージョンを設定します。このオプションは、クラスター内の各 mongodに対するnet.tls.disabledProtocols 構成ファイル オプションの構成に対応します。

すべてのクエリにインデックスが必要

コレクションスキャンが結果を返すために必要なクエリの実行を有効または無効にします。このオプションは、クラスター内の各mongodに対するsetParameterコマンドを介したnotablescanパラメーターの変更に対応します。

デフォルトの書込み保証 (write concern)

このクラスターの書込み (write) 操作に対して MongoDB から要求される確認応答のデフォルト レベルを設定します。

MongoDB 5.0 以降、クラスターのデフォルトの書込み保証 (write concern) は 過半数（majority）です。

トランザクションの有効期間を設定する

マルチドキュメントトランザクションの最大有効期間を設定します。このオプションは、クラスター内の各 mongod に対する setParameter コマンドを介した transactionLifetimeLimitSeconds パラメーターの変更に対応します。

クラスターのデフォルトのトランザクション有効期間は 60 秒です。

チャンク移行の同時実行を設定する

MongoDB バージョン 5.0.15 または 6.0.6 以降のバージョンを実行しているシャーディングされた Atlas クラスターの場合、ソース シャードと受信シャードのスレッド数を設定して、チャンク移行のパフォーマンスを向上させることができます。この値は、CPU コアの合計数の半分に設定できます。詳細については、chunkMigrationConcurrency を参照してください。

高速ディスク事前ウォーミングの有効化または無効化

クラスターに高速ディスク事前ウォーミング を有効にするには、Allow Fast Disk Pre-Warming を Yes に切り替えます。

クラスターの高速ディスク事前ウォーミングを無効にするには、Allow Fast Disk Pre-Warming を No に切り替えます。

基礎のクラウドプロバイダーのインフラストラクチャの設計により、既存のリージョンに新しいノードを追加する場合など、MongoDB Atlas がクラスターに新しいノードをプロビジョニングする必要があるときはいつでも、ディスクの事前ウォーミングが行われます。ディスクの事前ウォーミングでは、一時的に非表示のセカンダリ ノードが使用されます。

高速ディスク事前ウォーミングは、バックグラウンド ディスク ウォーミングよりも高速です。デフォルトでは、Atlas は配置に対して高速ディスク事前ウォーミングを有効にします。ディスク事前ウォーミングが有効になっている場合、Atlas はノードを非表示にし、これによりこのノードは読み取り操作を実行できなくなります。

次の推奨事項を検討してください。

• 一貫したクエリ レイテンシを求めるワークロードがある場合は、この設定を有効にします。

• 最大の可用性保証を重視し、一貫したクエリ性能よりも新しく追加または置き換えられたノードが即座にアクティブで可視であることを要求する場合は、この設定を無効にし、プレウォーミングを行うノードのカスタム接続文字列をタグ付きで使用する ことをお勧めします。プレウォーミングプロセスが完了するまで、この方法を使用してください。この接続文字列を使用することで、ノードのほとんどの IOPS がプレウォーミングプロセスによって利用されている間、ノードでの読み取りを防ぐことができます。

読み取り操作のデフォルトタイムアウトを設定する

MongoDB のバージョン 8.0 以降を実行しているクラスターの場合、これらのクラスターのすべての読み取り操作の、デフォルトの最大タイムアウトをミリ秒単位で指定できます。これにより、データベースを意図せず長時間実行されるクエリから保護します。このオプションは、クラスター パラメータの defaultMaxTimeMS に対応します。

レプリカセット スケーリング モードの構成

クラスターのレプリカセットスケーリング モードを変更します。 デフォルトでは、Atlas はノード をスケーリングします。つまり、Atlas はIn Parallel By Workload Type 運用ノード と並行して 分析 データをスケーリングします。

AtlasIn Parallel By Node Type Sequentialは、 モードと モードを使用してレプリカセットをスケーリングすることもできます。

In Parallel By Node Type モードは、頻繁にクラスター階層をスケーリングする必要がある大規模な動的ワークロード用です。 このモードでは、Atlas は選択可能なノードを 読み取り専用 ノードと 分析 ノードと並行して スケーリング します。これは最速のスケーリング戦略ですが、大量のセカンダリ読み取りを実行するとワークロードのレイテンシに影響を与える可能性があります。

Sequential モードは定常状態のワークロードと、レイテンシの影響を受けやすいセカンダリ読み取りを実行するアプリケーション用です。つまり、Atlas はすべてのノードを順次スケーリングします。

ログ リダクションを有効にする

これをオンに切り替えると、潜在的に機密性の高い情報がログに記録されなくなります。詳しくは、「ログ リダクション」を参照してください。

ログリダクションを有効および無効にするには、ローリング再起動が必要です。

シャーディングされたクラスターの Atlas 管理設定サーバ

新しいシャーディングされたクラスターの コンフィギュレーションサーバー タイプの Atlas の管理を有効または無効にします。Atlas が管理するコンフィギュレーションサーバーは、最適なパフォーマンスとコスト削減の基準に基づいてコンフィギュレーションサーバーの種類を自動的に切り替えます。シャーディングされたクラスターで Atlas が管理するコンフィギュレーションサーバーを有効にしない場合、Atlas は常にクラスター専用のコンフィギュレーションサーバーを使用します。

すべての 8.0 Atlas のシャーディングされたクラスター、Atlas 管理のコンフィギュレーションサーバーは、デフォルトで On です。Atlas 管理のコンフィギュレーションサーバーを無効にするには、トグルを Off に設定します。クラスターのシャードが4つ未満で、コンフィギュレーションサーバーが組み込まれている場合、Atlas 管理のコンフィギュレーションサーバーをオフにすると、クラスターは直ちに専用のコンフィギュレーションサーバーに移行します。