Amazon Web Services統合の構成
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
重要
MongoDBを使用してAmazon Web Services で サーバーをプロビジョニングする機能は、10Cloud Manager 月2017 で廃止されました。
既存のクラスターは引き続き設定されます。
この廃止は、 DNSエントリに次の影響を与えます。
既存サーバーのエントリは、少なくとも1 、 2023まで、現在解決されている IP アドレスと同じ IP アドレスに解決され続けます。
メンテナンスまたはインスタンスの停止/再起動により IP アドレスが変更されたサーバーは、
mongodbdns.comホスト名では解決できなくなります。既存のすべての
mongodbdns.comホスト名は 5 月2023に動作を停止します。
Cloud Managerは、 AWSを通じて直接プロビジョニングされたホストを管理できます。 「 オートメーション用にサーバーをプロビジョニング 」を参照してください。
Amazon Web Servicesでのフルマネージドプロビジョニングに懸念がある場合は、 MongoDB Atlasを評価してください。
Cloud Manager を使用してこれらの配置を管理する場合は、レプリカセットに対して次のいずれかの方法を使用して、各ホストのホスト名を更新します。
Considerations
これらの手順には、古いプライマリを解任し、新しいプライマリに対して少なくとも 1 回の選挙をトリガーすることが含まれます。 rs.stepDown()メソッドが受信されてから、新しいプライマリが選出されるまで、または選択可能なセカンダリが存在しない場合は、元のプライマリが通常の操作を再開するまで、プライマリへのすべての書き込みは失敗します。 MongoDB バージョン4.0以前の場合、すべてのクライアント接続が閉じられます。
アプリケーションがクラスターへのすべての書き込み操作を停止するメンテナンスウィンド中に、この手順を実行することを検討します。
選挙について詳しくは、「 rs.stepDown() の動作」と「レプリカセットの選挙 」を参照してください。
新しい EC 2インスタンスへのローリング再同期
非プライマリ レプリカセットの各ノードを新しい EC 2インスタンスに置き換えます。
EC 2ホスト名を使用してレプリカセットに新しいインスタンスを追加します。 詳しくは、「レプリカセットへのノードの追加 」を参照してください。
最初の同期が完了するまで待ちます。 最初の同期のステータスを取得する方法については、 MongoDB マニュアルを参照してください。
mongodbdns.comホスト名を持つ古いレプリカセット メンバーを 1 つ削除します。 詳細については、「レプリカセットからのノードの削除 」を参照してください。
プライマリ以外のレプリカセット ノードごとに繰り返します。
プライマリを新しい EC 2インスタンスに置き換えます。
EC 2ホスト名を使用して、最後の新しいインスタンスをレプリカセットに追加します。 詳しくは、「レプリカセットへのノードの追加 」を参照してください。
最初の同期が完了するまで待ちます。 最初の同期のステータスを取得する方法については、 MongoDB マニュアルを参照してください。
プライマリに接続し、プライマリを降格します。 詳しくは
rs.stepDown()を参照してください。注意
プライマリを降格すると、新しいプライマリに対して少なくとも 1 回の選挙がトリガーされます。 選挙の詳細については、「レプリカセットの選挙 」を参照してください。
レプリカセットから
mongodbdns.comホスト名を持つ古いプライマリをレプリカセットから削除します。 詳細については、「レプリカセットからのノードの削除 」を参照してください。
レプリカセットのホスト名の更新
MongoDB マニュアルの 「レプリカセットの可用性を維持しながらホスト名を変更する」 手順に従います。
リンクされた手順の概要は次のとおりです。
プライマリに再接続し、プライマリを降格します。
注意
プライマリを降格すると、新しいプライマリに対して少なくとも 1 回の選挙がトリガーされます。 選挙の詳細については、「レプリカセットの選挙 」を参照してください。