初期設定後にクラスターを変更できます。
利用可能なオプションの概要については、 「Atlas 構成オプション」を参照してください。
詳細な構成手順については、「必要なアクセス権」とそれに続くオプションを参照してください。
クラスターの変更による影響、コスト、バックアップ ポリシーの詳細については、「考慮事項」を参照してください。
Atlas 構成オプション
Atlas クラスターの次のオプションを変更できます。
設定 | アクション | 制限 |
クラスターの種類を変更します。 | Flex クラスターから専有クラスターに移動できます。 | |
クラスターのグローバル書き込みを有効にするか、既存のグローバルクラスター構成を変更します。 | クラスターのグローバル書き込みを有効にした後で、無効にすることはできません。 グローバル書き込みが有効になっている場合、グローバルクラスターは専用の検索ノードをサポートしません。 | |
| Atlas は、プライマリまたはセカンダリがすでに存在するリージョンでノードを追加または置き換える場合、より高速なクラウドベースの最初の同期を実行します。Atlas は、Amazon Web Services および Google Cloud Platform のクラスターに対してのみ、リージョンをまたぐクラウドベースの最初の同期をサポートしています。Azure クラスターでは、新しいリージョンにノードを追加する際、Atlas は論理的な最初の同期を実行します。 Atlasがマルチクラウド クラスターのサポートを追加した 11 月 2、2020 より前にGoogle Cloud PlatformまたはAzureでAtlasクラスターを作成した場合、別のプロバイダーに変更すると、接続stringが新しいクラスターに変更されます。 クラスターに再度接続するには、 新しい接続stringでアプリケーションをアップデートする時間をスケジュールすることを検討してください。 詳しくは、専有クラスターでクラウドプロバイダーを変更する場合は、接続文字列を更新する必要がありますか？を参照してください。 Azure 上のクラスターでは、リージョンを変更すると、そのリージョンで一部のストレージ機能が利用できなくなる場合があります。Atlas UI は、IOPS が減少することを通知し、アプリケーションのパフォーマンスに影響を与える可能性があります。詳細については、「拡張ストレージをサポートするリージョン」、および「Azure 上での IOPS とストレージ容量の変更」を参照してください。 | |
マルチクラウド、マルチリージョンクラスターを配置または変更します。 | Azure 上のクラスターでは、マルチリージョンクラスターに変更すると、いずれかのリージョンで一部のストレージボリューム機能が利用できなくなる可能性があります。Atlas UI は、IOPS が減少することを通知し、アプリケーションのパフォーマンスに影響を与える可能性があります。詳細については、「拡張ストレージをサポートするリージョン」、および「Azure 上での IOPS とストレージ容量の変更」を参照してください。 | |
クラスター階層を変更します。 | クラスターで NVMeストレージを使用する場合、Atlas は最初の同期を実行する必要があります。 ファイルコピーベースの最初の同期は、最初の同期が必要な場合はいつでも、NVME クラスターのすべてのノードを同期するために常に使用されます。 | |
クラスター世代を変更します。 | Gen2 は、AWS 上に配置された 対象となるクラスターでは、クラスターの階層を変更するのと同じ方法で、世代を切り替えることができます。詳細については、「Cluster Tier の変更」を参照してください。 | |
クラスター階層のストレージ オプションを変更します。 | NVMeストレージを使用するクラスターでは、クラスター階層ごとにサイズが固定されます。 | |
ストレージのオートスケーリングを含む、クラスターのオートスケーリング オプションを変更します。ストレージのオートスケーリングを使用するかどうかに応じて、Atlas は oplog の最小保持ウィンドウまたは oplog サイズに基づいて oplog エントリを管理します。詳細については、「Oplog サイズの動作」を参照してください。Atlas では、ストレージのオートスケーリングはデフォルトで有効になっています。 | ||
クラスターのメジャー MongoDB バージョンをアップグレードします。 | アップグレードする前にクラスターの FCV を固定しない限り、 MongoDB のバージョンをダウングレードすることはできません。 固定された FCV バージョンよりも 2 バージョン以上のバージョンにはアップグレードできません。クラスターが FCV 6.0 に固定されている場合は、7.0 にのみアップグレードでき、8.0 + はアップグレードできません。 | |
レプリカセットをシャーディングされたクラスターにスケール アップします。 | この操作を元に戻すことはできません。 Atlas では、 クラスターが MongoDB 5.3 以降を実行し、Document Preimage 構成オプションが有効な状態でデータベーストリガーを実行している場合、レプリカセットをシャーディングされたクラスターに変換できます。MongoDB のバージョン 5.3 以前で実行するクラスターでは、シャーディングされたクラスターに変換する前に、Document Preimage 構成オプションを無効にする必要があります。 | |
シャーディングされたクラスターのシャードの数を設定します。 | シャードの数を減らすには、少し時間がかかります。Atlas は、 重要: 8.0 でシャードを削除すると、Atlas は
Atlas では、 | |
クラスターのバックアップを有効または無効にします。 | Atlas は、フレックス クラスターのバックアップを自動的に有効にします。これらの階層のクラスターのバックアップを無効にすることはできません。 | |
クラスターの Atlas 用BI Connector を有効または無効にします。 MongoDB Connector for Business Intelligence for Atlas（BI Connector）は、 BI Connector は、 MongoDBデータベースへのSQLベースのアクセスをユーザーに提供する強力なツールです。 その結果、 BI Connector は、CPU とメモリを集中的に消費する可能性のある操作を実行します。 | ||
クラスターで独自の暗号化のキーの使用を有効または無効にします。 |
これらの変更のいずれかを完了したら、「変更を適用」をクリックします。
Considerations
移行、可用性、パフォーマンスへの影響
クラスターに変更を加えると、多くの場合、新しいサーバーとストレージ ボリュームへの移行が必要になります。ストレージ ボリューム間でデータの最初の同期と再同期に必要な時間は、クラスター内のデータの量に応じて直線的に増加します。
ファイルコピーベースの最初の同期は、最初の同期が必要な場合はいつでも、NVME クラスターのすべてのノードを同期するために常に使用されます。
次の移行では最初の同期が必要です。
無料クラスター（以前は
M0と呼ばれる）または Flex クラスターから上位のクラスター階層にスケールアップします。一般ストレージ ボリュームから NVMeストレージ ボリュームへ、および NVMeストレージ ボリュームから一般ストレージ ボリュームへ変更します。
ある NVMeクラスター層から別のNVMeクラスター階層へのスケールアップまたはスケールダウンは、手動またはオートスケーリングによって開始されます。NVMe 90クラスターは、使用可能なストレージ領域の % が消費されると、次の上位層にオートスケールします。
リージョンの変更など、NVMe を使用した Atlas クラスターの交換が必要な変更。
Azure にデプロイされたクラスターの場合、クラスタークラスが変更されます。
可用性を最大化するには:
レプリカセットの場合、Atlas は一度に 1 つのノードを移行します。最初にセカンダリ ノード、次にプライマリ ノードを移行します。
シャーディングされたクラスターの場合、Atlas はシャードの移行を互いに独立して実行します。 レプリカセットなどの各シャードの場合、Atlas は一度に 1 つのノードを移行します。最初にセカンダリ ノード、次にプライマリ ノードを移行します。
再試行可能な書き込みにより、新しいプライマリの選挙中に書き込みエラーが発生するのを防ぐことができます。平均して、選挙には5秒かかります。
プライマリがすでに運用キャパシティーに達している場合、移行によってパフォーマンスが影響を受ける可能性があります。 新しく移行された各レプリカセット ノードはプライマリからの最初の同期を実行する必要があり、運用負荷が増加します。 また 読み込み設定（ read preference ） をセカンダリから読み取るように設定した場合、移行によってパフォーマンスが影響を受ける可能性もあります。 移行中はレプリカセットのセカンダリが 1 つダウンします。
Atlas クラスターのワークロードが原因で、スケーリング機能などの操作が妨げられる場合、MongoDB Atlas は、状況によっては、予防手段としてクラスターにインデックスを作成することがあります。
請求
クラスターを変更する際には、適用前にさまざまなオプションのコストを比較できます。Cluster Overview ボックスには、データ転送を除き、選択した構成のコストが表示されます。
以下のセクションでは、各 Atlas クラスターのスケーリング構成オプションに関する詳細なドキュメントを提供します。
バックアップ
クラスターのバックアップについての詳細は、クラウドバックアップを参照してください。
必要なアクセス権
クラスターを変更するには、プロジェクトへの Project Cluster Manager 以上のアクセス権が必要です。
クラウドベースの最初の同期
Atlas は、プライマリノードまたはセカンダリノードがすでに存在するクラウドプロバイダーのリージョンにノードを追加する場合、または既存のプライマリノードまたはセカンダリノードが存在しない Amazon Web Services または GCP リージョンにノードを追加する場合に、 クラウドベースの最初の同期 を実行します。クラウドベースの最初の同期では、クラウドプロバイダーのネイティブ機能を活用して、ソースノードのデータのスナップショットを作成し、新しいノードに復元します。
Atlas クラスターに少なくとも 1 つのAWSリージョンを含む複数のリージョンにノードがある場合は、クラスターの Additional Settings でAWS クラスターのクロスリージョン最初の同期の高速化を追加コストで有効にできます。これにより、Atlas はAWS時間ベースのスナップショットコピーを使用して、クラウドベースの最初の同期中にAWSノード間のクロスリージョンデータコピーを高速化します。この設定の詳細については、AWSクラスターのより高速なクロスリージョン最初の同期の有効化を参照してください。
Atlas は、Amazon Web Services および Google Cloud Platform のクラスターに対してのみ、リージョンをまたがるクラウドベースの最初の同期をサポートしています。Azure クラスターでは、新しいリージョンにノードを追加する際、Atlas は論理的な最初の同期を実行します。クラスター設定を編集すると、クラスター内のノードを追加または除くことができます。
注意
自己管理型の最初の同期の曖昧さ回避
自己管理型配置の場合、最初の同期とはMongoDBがレプリカセットに新しいノードを追加するために使用するプロセスです。MongoDB 5.2 以降では、最初の同期プロセスは論理的またはファイルコピー ベースにすることができます。これらのプロセスは、MongoDB Atlasで利用可能なクラウドベースの最初の同期とは異なります。クラウドプロバイダーのネイティブ機能を活用して、ソースノードのデータのスナップショットを作成し、それを新しいノードに復元します。自己管理型の最初の同期プロセスの詳細については、 MongoDBマニュアルの 最初の同期 を参照してください。
クラスターを編集
Atlas CLI を使用して、このページのクラスター設定を変更できます。
Atlas CLI を使用して Atlas クラスターを更新するには、次のコマンドを実行します。
atlas clusters update [clusterName] [options]
Atlas CLI を使用して、M0 またはフレックス Atlas クラスターのクラスター階層、ディスク サイズ、および/または MongoDB バージョンをアップグレードするには、次のコマンドを実行します。
atlas clusters upgrade [clusterName] [options]
前のコマンドの構文とパラメータの詳細については、Atlas CLI ドキュメントの atlas clusters updateと atlas clusters upgrade を参照してください。
詳細設定を編集
MongoDB Atlas CLIを使用して1つのクラスターの詳細構成設定をアップデートするには、次のコマンドを実行します。
atlas clusters advancedSettings update <clusterName> [options]
コマンドの構文とパラメータの詳細については、Atlas CLI ドキュメントの atlas clusters advancedSettings update を参照してください。
Atlas で、プロジェクトの [Clusters] ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、 Database見出しの下のClustersをクリックします。
[ Clusters （クラスター） ] ページが表示されます。
または、特定のクラスターをすでに表示している場合は、Configuration ボタンをクリックします。無料クラスターの場合は、クラスターの [Upgrade] ボタンをクリックすることもできます。
クラスター タイプの変更
無料クラスターまたは Flex クラスターがある場合は、それを専有クラスターに変更できます 。
無料クラスターまたは Flex クラスターを M10+ クラスターに増やすアップするには、次の手順を実行します。
Atlas で、プロジェクトの [Clusters] ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、 Database見出しの下のClustersをクリックします。
[ Clusters （クラスター） ] ページが表示されます。
希望のクラスター階層を選択します。
詳細については、「Cluster Tier の変更」を参照してください。
注意
Considerations
専有クラスターを無料クラスターまたは Flex クラスターに変更することはできません。
変更 Global Cluster Configuration
重要
一度配置したクラスターのグローバル書き込みを無効にすることはできません。
クラスターのグローバル書き込みを有効にしたり、既存のグローバルクラスター構成を変更したりできます。
変更 Cloud Provider & Region
注意
Considerations
- 無料クラスター 階層クラスター
- クラウドプロバイダーとリージョンを変更できるのは、無料クラスターをより大きなクラスターに増やすアップする場合のみです。
- フレックス クラスターまたはそれ以上の階層のクラスター
- クラスターを変更したり、より大きなクラスターにスケール アップしたりする場合に、クラウドプロバイダーとリージョンを変更できます。
古いクラスターが 10 月 2020 以前に Google Cloud Platform または Azure に配置されていた場合、別のプロバイダーに変更すると、新しいクラスターへの文字列が変更される可能性があります。クラスターへの接続を再開するために、新しい接続文字列でアプリケーションを更新する時間をスケジュールすることを検討してください。Atlas はデータを新しいクラスターに移行します。
クラスターの現在のクラウドプロバイダーとリージョンを表示するには、Cloud Provider & Region を選択します。
クラスターに適用されるクラウドプロバイダーとリージョンを変更するには、高可用性の選挙可能なノード の手順に従ってください。
リージョン停止時に選挙可能なノードをクラスターに追加するには、「リージョン停止時にレプリカセットを再構成する」の手順に従ってください。
Atlas 無料クラスターまたはフレックス クラスターからスケールアップするには、利用可能なクラウド プロバイダーから選択します。
クラスターに検索ノードが含まれている場合は、検索ノードをサポートするリージョンにのみ移動できます。検索ノードをサポートしていないリージョンの完全なリストについては、クラウドプロバイダー リージョンを参照してください。
クラウドバックアップが有効になっているクラスターのプライマリ リージョンを変更すると、Atlas はオンデマンドスナップショットを取得し、次にスケジュールされたスナップショットを待たずに新しいプライマリ リージョンに保存します。新しいプライマリ リージョンが以前はスナップショット コピー配布のセカンダリバックアップリージョンであった場合、Atlas はバックアップポリシーを自動的に更新して、新しいプライマリ リージョンからスナップショット コピーを元のプライマリ リージョンと他のセカンダリ リージョンに配布します。
追加の検索ノードを削除または配置するには、Search nodes for workload isolation の下の Number of Search Nodes 設定を調整します。クラスターには 2 から 32 の検索ノードを配置できます。
クラスター上の既存の検索ノードをすべて削除すると、検索クエリ結果の処理が中断され、一方 Atlas は、専用検索ノード上で個別に動作している
mongotプロセスから、mongodと並行して動作しているmongotプロセスに移行します。mongotとmongodの両方のプロセスをホストするノードでインデックスが作成されている間はクエリを実行できず、クエリのダウンタイムが発生します。検索ノードがないクラスターに検索ノードを追加すると、 MongoDB Search が最初の同期を完了した後に発生するデータベースへの
mongodテール書込みと並行実行中既存のmongotプロセスと MongoDB Search が初期同期を完了した後に発生するデータベースへのmongotプロセスと新しい専用検索ノードは、必要なコレクションの最初の同期を実行します。これにより、移行プロセス中に二重に読み取りが行われます。詳細については、専用の検索ノードの追加を参照してください。
利用可能なリージョンの表示
Atlas CLI を使用して、Atlas が新しい配置でサポートする利用可能なリージョンを一覧表示するには、次のコマンドを実行します。
atlas clusters availableRegions list [options]
構文とパラメータの詳細については、Atlas CLI ドキュメントの atlas clusters availableRegions list を参照してください。
変更 Cluster Tier
選択したクラスターのクラスター階層だけでなく、世代、メモリ、ストレージ、IOPS（速度）の仕様も変更できます。検索ノードを M10 以上のクラスターに個別に配置した場合は、検索階層を変更することもできます。
注意
バックアップ コンプライアンス ポリシーを有効にしている場合、クラスター階層を、クラウドバックアップをサポートしない階層に変更することはできません。
AWS Gen2 専有クラスターのクラスター世代を変更する
M30+ AWS 上の専有クラスターでは、クラスター世代として Gen1 または Gen2 で利用できます。AWS Gen2 専有クラスターでは、拡張標準 IOPS をサポートすることで、Gen1 クラスターと比較してパフォーマンスが向上し、次の利点があります。
クラスターの標準 IOPS とストレージ容量を個別に拡大
最大標準 IOPS レート
80kIOPSクラスターの標準 IOPS に応じて増やされるディスクスループット
詳細については、「AWS Gen2 専有クラスター」を参照してください。
クラスターの階層を変更するのと同じ方法で、対象となるクラスターを Gen1 と Gen2 の間で切り替えることができます。Atlas UI を使用してクラスターの世代を変更するには、Cluster Tier セクションの下にある Gen2 または Gen1 オプションを選択します。
これらのオプションは、クラスター構成が Gen2 クラスターをサポートしている場合にのみ選択できます。Gen2 オプションがグレー表示されている場合、クラスターはデフォルトで Gen1 です。詳細については、「AWS Gen2 のサポート対象リージョン」を参照してください。
Tip
Atlas Administration API または Atlas CLI を使用したクラスターの世代の設定
Atlas Administration API または Atlas CLI を使用して クラスターの世代 を指定するには、それぞれ instanceSize または --tier オプションを使用します。
Gen1 クラスターは AP および CLI の名前でクラスター階層のみを使用しますが、Gen2 クラスターはクラスター階層に _GEN_2 を付加して使用します。たとえば、M30 階層クラスターを配置するには、次のようにします。
Gen1
M30クラスターにはM30を使用します。Gen2
M30クラスターにはM30_GEN_2を使用します。
「Available Cluster Tiers」（AWS リファレンス）を参照して、Atlas の Gen2 クラスターをサポートするクラスター階層の一覧を確認してください。
リアクティブなオートスケーリングを使用して、クラスターを Gen1 から Gen2 の間で自動的に増やすこともできます。詳しくは、「AWS Gen2 専有クラスターの拡大」を参照してください。
重要
クラスターの世代切り替え時のオートスケーリング境界
クラスターのオートスケーリング境界は、そのクラスターと同じ世代に属している必要があります。
M10 また、M20 クラスターは世代に依存しません。オートスケーリングの境界は任意の世代に設定でき、M10 および M20 クラスターを任意のクラスター世代のオートスケーリング境界として使用できます。
次のいずれかを行おうとすると、Atlas Administration API は INVALID_ATTRIBUTE エラーを返します。
クラスターの世代を、そのクラスターのオートスケーリング境界の世代とは異なる世代に変更します。
クラスターのオートスケーリングの境界を、そのクラスターとは異なる世代に属する
M30+階層クラスターに設定します。
AWS Gen2 専有クラスターに関する考慮事項
AWS Gen2 クラスターを使用する前に、次の制限事項を確認してください。また、Gen1 クラスターと Gen2 クラスターを比較することもできます。
AWS Gen2 クラスターは AWSでのみ利用できます。
AWS Gen2 専有クラスターでは、マルチクラウドのサポートは利用できません。
すべてのリージョンが AWS Gen2 専有クラスターをサポートしているわけではありません。詳細については、「Amazon Web Services Gen2 のサポート対象リージョン」を参照してください。
リージョン間サポートは、クラスターを配置するすべてのリージョンが Gen2 クラスターをサポートしている場合にのみ利用可能です。
M10また、M20クラスターは世代に依存しません。M10およびM20クラスターを配置する場合は、クラスター世代を選択しません。クラスター内のすべてのノードは、同じ世代である必要があります。同じクラスター内でGen1ノードとGen2ノードを混在させることはできません。
AWS Gen2 クラスターは、予測オートスケーリングではなく、リアクティブオートスケーリングのみがサポートされます。詳しくは、「AWS Gen2 専有クラスターの拡大」を参照してください。
無料クラスターとフレックス クラスターに関する考慮事項
M10+専有クラスターを 無料クラスターまたは Flex クラスターに増やすダウンすることはできません。以下のシナリオでは、クラスター階層の変更にダウンタイムが必要です。
無料クラスターまたは Flex クラスターから
M10以上のクラスター階層に変更する場合。無料クラスターから Flex クラスターに変更する場合。
データの破損を防ぐため、スケール操作中はクラスターへの書き込み操作を停止してください。
クラスター ノードの階層
ご希望のクラスター階層を選択します。Search Nodes を個別に配置した場合は、Base Tierタブで希望のクラスター階層を選択します。選択したインスタンス サイズによって、クラスター内の各データ保持サーバー [1 ] のメモリ、ストレージ、vCPU、および IOPS 仕様が決まります。
警告
無料クラスターまたはフレックス クラスターから専有クラスター階層にアップグレードすると、現在のクラスターとそれに関連するすべてのバックアップ スナップショットが永久に削除されます。アップグレードの完了後は、これらのスナップショットを復元することはできません。データを保存するには、アップグレードを開始する前に、必要なスナップショットをダウンロードするか、mongodump を使用してデータのエクスポートを実行してください。
注意
クラスター階層を変更すると、Atlas はクラスター内のすべてのノードを再起動します。
Cluster Tierセクションでは、次の操作も実行できます。
分析ワークロードに適したサイズのクラスター層を選択できます 。詳細については、「 ワークロード分離のための分析ノード 」を参照してください。
重要
無料クラスターを専有クラスターに、無料クラスターを Flex クラスターに、または Flex クラスターを専有クラスターにアップグレードした後、アップグレードしたクラスターに接続する前にアプリケーションを再起動する必要があります。
もし読み取り専用ノードを配置しており、クラスターのスケールを速めたい場合は、レプリカセットのスケーリングモードを調整することを検討してください。
検索ノードの階層
[Search Tier] タブで、希望する検索レベルを選択します。選択した検索階層がお住まいの地域で利用できない場合、Atlas はお客様の地域で次に上位の検索階層に自動的に切り替わります。選択したインスタンス サイズによって、クラスターの各検索ノードのメモリ、ストレージ、IOPS 仕様、およびコストが決まります。
注意
検索階層を変更すると、Atlas はクラスター内のすべてのノードを再起動します。
Modify Additional Settings
次のオプションを設定できます。
クラスターバージョンのアップグレード
クラスター バージョンを選択またはアップグレードするには、「 クラスター バージョンの選択または変更」を参照してください。
クラスターのバックアップの有効化または無効化
Atlas は Flex クラスターのバックアップを自動的に有効にするため、この設定を無効にすることはできません。詳細については、「Flex クラスターのバックアップ」をご覧ください。
M10+ Atlas クラスターのクラウドバックアップを有効にするには、Turn on Cloud Backup トグルを On に設定します。有効にすると、Atlas は定期的にデータベースのスナップショットを取得し、プロジェクトのバックアップポリシーに従ってそれらを保持します。
M10+ Atlas クラスターのクラウドバックアップを無効にするには、[Turn on Cloud Backup] トグルを [Off] に設定します。これにより、クラスターの継続的クラウドバックアップも無効になります。クラウドバックアップが無効になった後に、既存のスナップショットを保持するには、[Keep
existing snapshots after backups disabled?] トグルを [On] に設定します。このオプションは、クラスターのバックアップポリシーに従って、既存のスナップショットと oplog を保持するよう Atlas に指示します。
使用可能なバックアップオプションの説明については、「クラスターのバックアップオプションの設定」を参照してください。
クラスターの終了保護の有効化または無効化
クラスターに対して Termination Protection を有効にするには、Termination Protection を Yes に切り替えます。
有効にすると、Atlas はユーザーによるクラスターの削除を防止します。終了保護が有効になっているクラスターを削除するには、まず終了保護を無効にする必要があります。デフォルトでは、Atlas はすべてのクラスターの終了保護を無効にします。
シャーディングされたクラスターへのレプリカセットのスケーリング
クラスターが MongoDB 5.3 以降を実行し、Document Preimage 構成オプションが有効な状態でデータベーストリガーを実行している場合、レプリカセットをシャーディングされたクラスターに変換できます。MongoDB のバージョン 5.3 以前で実行するクラスターでは、シャーディングされたクラスターに変換する前に、Document Preimage 構成オプションを無効にする必要があります。
クラスターをシャーディングされたクラスターとして配置するには、Shard your cluster (M30 and up) を Yes に切り替えます。
単数形のレプリカセットクラスターを複数シャードのシャーディングされたクラスターに変換するには、まず単一のシャード シャーシャーディングされたクラスターに変換し、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再起動しないと、Atlas によってシャード間でのデータ分散が開始された後、データの整合性が失われる可能性があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
DNS シードリスト接続文字列を使用している場合、アプリケーションがシャーディングされたクラスターの
mongosに自動的に接続されます。標準の接続文字列を使用している場合は、新しいクラスター トポロジーを反映するように接続文字列を更新する必要があります。
MongoDB 8.3 以降、DDL 操作 と applyOps は、すべてのシャーディングされたクラスターの mongos でのみ実行できます。レプリカセットからシャーディングされたクラスターに移行している間は、これらの操作が一時的に利用できなくなることがあります。
レプリカセットをクラスターに変換する方法については、レプリカセットをクラスターに変換する を参照してください。
変更 Number of Shards
このフィールドは、配置がシャーディングされたクラスターである場合にのみ表示されます。
クラスターは、1 から 70 までのシャードを持つことができます。
レプリカセットをマルチシャーディングされたクラスターにスケール アップするには、まず単一のシャーディングされたクラスターにスケール アップし、アプリケーションを再起動してクラスターに再接続してから、シャードを追加する必要があります。
アプリケーション クライアントを再接続しないと、アプリケーションにデータが停止する可能性があります。
レプリカセットクラスターを単一のシャーディングされたクラスターにスケール アップしたら、そのシャーディングされたクラスターで配置するシャードの数を設定できます。
シャーディングされたクラスター内のシャードの数を減らす場合、Atlas は "_id" フィールドの数に基づいてシャードを降順で削除します（「シャーディングされたクラスターの構成」を参照）。たとえば、次の 3 つのシャードを含むシャーディングされたクラスターを考えてみます。
"shard0""shard1""shard2"
シャードの数を 2 に設定すると、Atlas はクラスターから "shard2" を削除します。
重要: 8.0 でシャードを削除すると、Atlas は moveCollection コマンドを使用して、そのシャード内のシャーディングされていないコレクションを残りのシャードに移動します。このプロセス中、シャーディングされていないコレクションはすべてオンラインのままになります。
すべてのシャーディングされたコレクションは、シャード削除プロセス中もオンラインのままとなり、利用可能です。削除されたシャードからシャーディングされたコレクションを空にするには、バランサーをオンにする必要があります。
Atlas は、移動プライマリ コマンドを使用して、
moveCollectionコマンドでドレインできないシャーディングされていないコレクションを移動します。moveCollectionの制限の詳細については、制限を参照してください。movePrimaryは オフライン操作です。シャード削除の詳細については、 シャードクラスタからシャードを削除する を参照してください。
実稼働環境では、単一のシャードを含むシャーディングされたクラスターを作成しないでください。 単一シャードのシャード クラスターでは、マルチシャード構成と同じ利点は得られません。 単一シャード クラスターを作成したら、アプリケーションを再起動し、クラスターに再接続して、クラスターにシャードを追加します。
クラスターの I Connector for Atlas の有効化または無効化
このクラスターで BI Connector for Atlas を有効にするには、Enable Business Intelligence Connector (M10 and up) を Yes に切り替えます。
保存時の暗号化の有効化
KMS を使用してこのクラスターで Atlas Encryption at Rest を有効にするには、 Manage your own encryption keys (M10 and up)をYesに切り替えます。詳細については、「独自の暗号化鍵の管理」を参照してください。
追加の構成オプションの構成
このセクションからクラスターの追加オプションを設定します。
これらのオプションの詳細については、「追加オプションの構成」を参照してください。
Modify Cluster Details
タグの追加、既存のタグの表示、およびタグの管理を行います。詳細については、「既存のクラスターを変更する際のクラスター タグの管理」を参照してください。
重要
個人を特定できる情報（PII）や保護医療情報（PHI）などの機密情報をリソース タグに含めないでください。請求などの他の MongoDB サービスは、リソース タグにアクセスできます。MongoDB は、クラスター リソース タグを DataDog および Prometheus 統合にも送信します。リソース タグは、個人的な機密情報を扱うためのものではありません。詳細については、「機密情報」を参照してください。
変更を後で保存
変更を保存するには、クラスター構成フォームの最後にある Save Draft をクリックします。
Save Draft をクリックすると、Atlas アカウントに関連付けられているメールアドレスに、変更されたクラスター設定フォームに戻るボタン付きのメールが Atlas から送信されるよう指示が出されます。
フォームに戻ると、次のことができます。
表示されるポップアップで [Continue] をクリックして、変更を続行します。
表示されるポップアップで [Reset] をクリックして、変更をリセットします。
変更を確認して適用
Review Changes をクリックして、実施そた変更を確認します。
Review Changesページには、変更された属性の完全な概要と、変更に関連する警告やメモが並べて表示されます。元の属性設定は左側に、価格設定を変更した対応する新しい設定は右側に表示されています。
Atlas は、変更に関連するすべての警告とメモを上部に表示します。これには、次のような変更が含まれます。
ロールバックはできません。
最初の同期が必要です。
実行の遅延、ワークロードの増加、またはダウンタイムが予想されます。
変更を確認したら、 Apply Changesをクリックしてクラスターに適用します。
無料 クラスターからアップグレードする場合、変更を適用する前に支払い情報の入力を求めるプロンプトが Atlas に表示されます。
| [1] | レプリカセットの場合、データを保持するサーバーはレプリカセット ノードをホストするサーバーです。シャーディングされたクラスターの場合、データを持つサーバーはシャードをホストするサーバーである。シャーディングされたクラスターの場合、Atlas は コンフィギュレーションサーバー 用のサーバーも展開します。これらはクラスター コストとは別の料金で課金されます。 |
レプリカセットのシャーディングされたクラスターへの変換
レプリカセットをシャーディングされたクラスターに変換できます。
注意
Atlas は、レプリカセットをシャーディングされたクラスターに変換するときに、レプリカセット内のすべてのノードを再起動します。
前提条件
レプリカセットをシャーディングされたクラスターに変換するには:
M30+クラスターである必要があります。Project Cluster Manager以上のロールが必要です。
手順
Atlas で、プロジェクトの [Clusters] ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーで、 Database見出しの下のClustersをクリックします。
[ Clusters （クラスター） ] ページが表示されます。
クラスターのシャーディングを有効にします。
変更するクラスターで、をクリックして Edit Configuration を選択します。
Additional Settingsを展開してクラスター構成を変更します。
Shard your clusterセクションで、トグルをOnに切り替えて、シャーディングを有効にします。
重要
レプリカセットをシャーディングされたクラスターに変換した後、再度レプリカセットに変換することはできません。
Atlas はドロップダウン メニューから1 Shard を自動的に選択します。アプリケーション クライアントを再起動した後の手順で、シャードの数を増やすことができます。
警告
コレクションが複数のシャードに分散していない場合、レプリカセットからMongoDB v7.0を実行中のシャーディングされたクラスターへのアップグレード中に、サブパイプラインで
$unionWithと$searchを使用するクエリが失敗する可能性があります。これを軽減するには、クラスターに複数のシャードを配置し、コレクションをシャーディングして、複数のチャンクが複数のシャードに分散されるようにします。Review Changesをクリックして請求の変更を確認し、 Apply Changesをクリックします。
Atlas で変更が配置されるまでには時間がかかる場合があります。Atlas がクラスターを変換するまで待ってから次のステップに進みます。
すべてのアプリケーション クライアントを再起動し、シャーディングされたクラスターに再接続します。
アプリケーション クライアントを再起動しないと、Atlasによってシャード間でのデータ分散が開始された後、データの整合性が失われる可能性があります。
DNS シード リスト接続文字列を使用している場合、アプリケーションの再起動後、アプリケーションがシャード クラスターの
mongosに自動的に接続されます。標準の接続文字列を使用している場合は、新しいクラスター トポロジーを反映するように接続文字列を更新する必要があります。
プライベートエンドポイントを使用して Atlas クラスターに接続している場合、変換中はクラスターにダウンタイムが発生します。
詳細については、「 Atlas クラスターへの接続 」を参照してください。
クラスター内のシャード間でデータを分散します。
データを配信するコレクションをシャーディングする場合の詳細については、sh.shardCollection() を参照してください。
警告：MongoDB Search インデックスがすでに存在するコレクションをシャーディングする場合、インデックスがシャードで構築されている間に短時間、不完全な検索結果が発生する可能性があります。また、MongoDB Search インデックスを含むすでにシャーディングされたコレクションにシャードを追加する場合、追加されたシャードで最初の同期プロセスが完了するまで、そのコレクションに対する検索クエリでは不完全な結果が返される可能性があります。詳しくは、 「最初の同期プロセス」 を参照してください。
注意
結果として得られるシャーディングされたクラスターは、Atlas マネージド コンフィギュレーションサーバーが有効になっている場合でも、常に専用のコンフィギュレーションサーバーを使用します。MongoDB、本番ワークロードには専用のコンフィギュレーションサーバーを推奨しています。変換後に埋め込みコンフィギュレーションサーバーが必要な場合は、MongoDBサポート にお問い合わせください。