追加設定の構成

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 に指示します。

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

Atlas Infinite クラスターのバックアップオプション

Atlas Infinite クラスターには、24 時間の継続的なクラウドバックアップウィンドウが含まれています。そのウィンドウを超えてスナップショットを保持するには、Atlas がデフォルトで有効にする Additional Backup Retention 設定を使用します。追加のバックアップ保持には、バックアップポリシーとワークロードに基づいて追加コストが発生します。

Atlas Administration APIでは、backupEnabledフィールドはAtlas InfiniteクラスターのAdditional Backup Retentionを制御します。継続的なバックアップウィンドウは常に適用されるため、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 でのみ実行できます。レプリカセットからシャーディングされたクラスターに移行している間は、これらの操作が一時的に利用できなくなることがあります。

変換した後、コレクションを シャーディング し、シャード間でデータを分散するために適切なシャードキーを選択する必要があります。詳細については、「クラスターへのレプリカセットの変換」を参照してください。

BI Connector for Atlas 利用可能性

クラスター構成フォームは、EOL に達したため Atlas 用 BI Connector を制限します：

• クラスターで BI Connector for Atlas がまだ有効になっていない場合、Enable Business Intelligence Connector セクションは表示されず、有効にすることもできません。

• Atlas用BI Connectorが既に有効になっている場合、セクションに非推奨の通知が表示され、Atlas用BI Connectorをオフにすることしかできません。一度無効にすると、再度有効にすることはできません。Review Changesページにも同じ通知が表示されます。

代わりに MongoDB SQL Interface (Atlas Dedicated) を使用することをお勧めします。既存の BI Connector for Atlas ワークロードを移行するには、移行ガイドを参照してください。

前提条件

• 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 を動的に変更します。Atlas が oplog サイズを管理する方法の詳細については、「Oplog サイズの動作」を参照してください。ただし、Minimum TLS Protocol Version および Allow Server-Side JavaScript の設定では、シャードメンバーとコンフィギュレーションサーバーレプリカセットのローリング再起動が実行されます。Atlas がメンテナンス操作中に高可用性をサポートする方法の詳細については、「MongoDB Atlas が高可用性を実現する方法」を参照してください。

追加設定の表示と編集

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

atlas clusters advancedSettings update <clusterName> [options]

Atlas Core Amazon Web Servicesクラスターのリージョン間での最初の同期を高速化

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 および Google Cloud Platform クラスターの適応型キャパシティー

Atlasは、Microsoft AzureおよびGoogle Cloud上の少なくとも1つのノードを持つクラスターに対して、デフォルトでAdaptive Capacityを有効にします。Microsoft Azureの場合、適応型キャパシティーはM30+クラスターにのみ適用されます。より多くを学ぶには、以下を参照してください。

• Microsoft Azure 参照 - 適応型キャパシティー

• Google Cloud Platform 参照 - 適応型キャパシティー

個々のクラスターの適応型キャパシティーを無効または再有効にするには、Atlas UIまたはAtlas Administration APIを使用します。

最小 oplog window の設定

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

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

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

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

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

Oplog サイズの設定

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

Set Oplog Size 構成設定は、クラスターのストレージ オートスケーリングをオプトアウトした場合にのみ設定できます。MongoDB のコマンド replSetResizeOplog を使用して、Atlas のクラスター上の oplog のサイズを変更することはできません。

ストレージのオートスケーリングが有効になっているクラスターでは、代わりに 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 を削減する前に、このデータ損失の影響を考慮してください。

サーバーサイド 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 構成ファイル オプションの構成に対応します。

重要: Atlas は、もはや TLS 1.0 または 1.1 をサポートしていません。すべてのクラスターは、TLS 1.0 または 1.1 での接続試行を拒否します。クラスターの最小 TLS バージョンを 1.2 以上に設定します。

カスタム暗号スイート構成の設定

暗号スイートのリストから、クラスターのノード間通信およびクライアントと Atlas 間の通信に使用する暗号スイートを選択してください。使用可能な暗号のリストは、クラスターの最小 TLS バージョンによって異なります。

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

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

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

Atlas Infiniteクラスターでは、デフォルトの書込み保証 (write concern)を設定することはできません。Atlas Infiniteクラスターでの書込み保証 (write concern)の仕組みを学ぶには、「Atlas Infiniteクラスターでの書込み保証 (write concern)」を参照してください。

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

クラスターのデフォルトの書込み保証 (write concern)は過半数です。

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

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

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

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

Atlas では、AWS および Azure でホストされているクラスターに対して、Fast Disk Pre-Warming 設定を提供しています。Atlas は、これらのクラスターではデフォルトで高速ディスクのプレウォーミングを可能にします。

Amazon Web Services または Azure クラスターの高速ディスクプレウォーミングを無効にするには、「Fast Disk Pre-Warming」設定の下の「Off」を選択します。再度有効にするには、Fast Pre-Warming (Default) を選択します。

基礎のクラウドプロバイダーのインフラストラクチャの設計により、クラスターの既存のリージョンに新しいノードを追加する場合など、Atlas がクラウドベースの最初の同期を実行するたびに、ディスクの事前ウォーミングが行われます。クラウドベースの最初の同期中、Atlas は新しいノードが準備できるまで読み取りを提供しないように、一時的に非表示にします。

高速ディスク事前ウォーミングは、バックグラウンド ディスク ウォーミングよりも高速です。高速ディスクのプレウォーミングが有効になっている場合、新しいノードはプレウォーミング中にプロビジョニングされた IOPS の大部分を消費します。そのため Atlas はプレウォーミングが完了するまでノードを非表示にします。高速ディスクの事前ウォームアップが無効になっている場合、Atlas はノードの準備が整い次第、ノードを再表示し、ディスクをバックグラウンドでウォームアップします。これにより、ノードがより早く表示されるようになります。

M40+ AWS クラスターで、NVMeストレージを使用しない場合、Atlas は、クラウドベースの最初の同期中の高速ディスクの事前温めをサポートするため、ハイパフォーマンスな AWS ストレージボリュームを一時的にプロビジョニングします。ディスクのプレウォーミングが完了した後、Atlas はボリュームをノードの元のストレージ設定に戻します。この変更では、AWS が各 EBS ボリュームに対して 24 時間の任意の期間内で許可している 4 つの EBS ボリューム変更のいずれか 1 つを使用します。EBS ボリューム変更制限について詳しくは、「Amazon Web Services でのストレージ容量または IOPS の変更」を参照してください。

より高性能な一時ストレージボリュームをプロビジョニングすると、Atlas の月額請求書におけるクラスターのストレージコストが一時的に増加する可能性があります。詳細については、「ストレージ キャパシティー」を参照してください。

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

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

• 一貫したクエリ パフォーマンスによる最大限の可用性の保証を求めるワークロードがあり、新しく追加または交換されたノードをすぐにアクティブにして表示できるようにする必要がある場合は、事前ウォーミングプロセスが完了するまで、この設定を無効にし、事前ウォーミングを行うノードのタグを含むカスタム接続文字列を使用します。この接続文字列を使用すると、ノードでの読み取りが防止されますが、IOPS のほとんどが事前ウォーミング プロセスによって使用されます。

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

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

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

クラスターのレプリカセットスケーリングモードを変更します。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 はクラスターの動作に影響を与えません。

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

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

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

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

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

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

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

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