MongoDB の機能を活用して、レプリカセットの選挙をグレースフルに処理するアプリケーション コードを作成するには、次の手順を実行する必要があります。
最新のクライアントライブラリをインストールします。
すべてのホストを指定する接続文字列を使用します。
再試行可能な書込み と 再試行可能な読み取り を使用します。
アプリケーションにとって意味のある
majorityの書込み保証と読み取り保証を使用します。アプリケーション内のエラーを処理します。
最新のクライアント ライブラリのインストール
まず、MongoDBクライアント ライブラリから、ご使用の言語の最新のクライアントライブラリをインストールします。クライアント ライブラリは、アプリケーションからのクエリをデータベースに接続して中継します。最新のクライアントライブラリを使用すると、最新のMongoDB機能が有効になります。
次に、アプリケーションに依存関係をインポートします。
接続文字列
配置内のすべてのホストを指定する接続文字列を使用して、アプリケーションをデータベースに接続します。 配置でレプリカセットの選挙が実行され、新しいプライマリが選択された場合、配置内のすべてのホストを指定する接続文字列によって、アプリケーション ロジックなしで新しいプライマリが検出されます。
次のいずれかを使用して、配置内のすべてのホストを指定できます。
標準接続文字列形式、または
接続文字列では、オプション（ retryWritesと writeConcern など）を指定することもできます。
Tip
接続文字列の形式の詳細については、「MongoDBクライアントライブラリを使用した配置への接続」を参照してください。
接続文字列を使用して、アプリケーション内で MongoDB クライアントをインスタンス化します。
再試行可能な書込みと読み取り
注意
MongoDBバージョン 3.6 および 4.2 互換クライアントライブラリ以降、 MongoDB はデフォルトで 書き込み (write)と読み取りの両方を 1 回再試行します。
再試行可能な書き込み
再試行可能な書込みを使用して、特定の書込み操作が失敗した場合に 1 回再試行します。
書き込みを 1 回だけ 再試行する ことは、アプリケーションが正常な プライマリ ノード を一時的に見つけられない場合に、一時的なネットワークエラーやレプリカセットの選挙を処理するための最善の戦略です。 再試行が成功すると、操作全体が成功し、エラーは返されません。 操作が失敗した場合は、次の理由が原因で失敗した可能性があります。
永続的なネットワークエラー、または
無効なコマンド。
Tip
再試行可能な書込みを有効にする方法の詳細については、「 再試行可能な書込みの有効化 」を参照してください。
操作が失敗した場合、アプリケーションは自分自身を処理する必要があります。
再試行可能な読み取り
MongoDBバージョン 3.6 および 4.2 互換クライアントライブラリ以降、読み取り操作が失敗した場合、読み取り操作は 1 回自動的に再試行されます。読み取りを再試行するようにアプリケーションを構成する必要はありません。
書込み保証 (write concern) と読み取り保証 (read concern)
書込み保証 (write concern) と読み取り保証 (read concern) を使用して、アプリケーションの整合性と可用性を調整できます。 懸念が深い場合は、データベース操作により強力なデータ整合性保証が必要になりますが、整合性要件を緩和すると可用性が向上します。
例
アプリケーションが金銭の残高を処理する場合、整合性は非常に重要です。 majorityの書込み保証と読み取り保証 を使用して、古いデータやロールバックされる可能性のあるデータからの読み取りを行わないようにできます。
あるいは、アプリケーションが 1 秒ごとに数百のセンサーからの温度データを記録する場合、最新の読み取り値を含まないデータを読み取る場合は問題が発生しない場合があります。 整合性要件を緩和すると、そのデータへのアクセスが速くなります。
書込み保証 (write concern)
接続string URI を使用してレプリカセットの 書込み保証レベル を設定できます。majority書込み保証（write concern）を使用して、データがデータベースに正常に書き込まれ、永続化されるようにします。 これは推奨のデフォルトであり、ほとんどのユースケースで十分です。
majorityなど、確認応答が必要な書込み保証を使用する場合は、そのレベルの確認応答を実現するための書込みの最大時間制限を指定することもできます。
すべての書き込み (write) の
wtimeoutMS接続文字列パラメータ、または単一の書込み (write) 操作のwtimeoutオプション。
時間制限を使用するかどうかと、使用する値は、アプリケーションのコンテキストによって異なります。
Tip
書込み保証 (write concern) レベルの設定の詳細については、「 書込み保証 (write concern)オプション 」を参照してください。
重要
書込みに時間制限を指定せず、書込み保証 (write concern) レベルが達成できない場合、書込み (write) 操作は完了しません。
読み取り保証（read concern）
接続文字列 URI を使用して、レプリカセットの 読み取り保証レベル を設定できます。理想的な読み取り保証はアプリケーションの要件によって異なりますが、ほとんどのユースケースではデフォルトで十分です。 デフォルトの読み取り保証を使用する場合、接続文字列パラメーターは必要ありません。
読み取り保証 (read concern) を指定すると、アプリケーションがデータベースから受信するデータの保証が強化されます。
Tip
読み取り保証 (read concern) レベルの設定の詳細については、「読み取り保証 (read concern) オプション 」を参照してください。
注意
アプリケーションが使用する書込み保証 (write concern) と読み取り保証 (read concern) の特定の組み合わせは、操作順序の保証に影響します。 これは 因果整合性 と呼ばれます。 因果整合性の保証の詳細については、「因果整合性、読み取り保証、書込み保証 」を参照してください。
Error Handling
再試行可能な書き込みで処理されていないコマンド、ネットワークの停止、ネットワークエラーはエラーを返します。エラーの詳細については、クライアントライブラリのAPIドキュメントを参照してください。
例、アプリケーションが重複した _id を含むドキュメントを挿入しようとすると、クライアントライブラリは次のようなエラーを返します。
適切なエラー処理を行わないと、エラーによってアプリケーションが再起動されるまでリクエストの処理がブロックされる可能性があります。
アプリケーションは、クラッシュしたり副作用のないエラーを処理する必要があります。 重複する_idを挿入するアプリケーションの以前の例では、そのアプリケーションは次のようにエラーを処理できます。
この例の挿入操作では、 _idフィールドが一意である必要があるため、2 回目に呼び出されるときに「重複キー」エラーがスローされます。 アプリケーションはエラーをキャッチし、クライアントに通知され、アプリは実行を続行します。 しかし、挿入操作は失敗します。ユーザーに メッセージを表示するか、操作を再試行するか、または別の操作を実行するかは、ユーザーが決定する必要があります。
エラーは常にログに記録する必要があります。 これ以上の処理エラーを発生させる一般的な戦略は次のとおりです。
エラーを、エラー メッセージとともにクライアントに返します。 これは、エラーを解決できず、アクションが完了できないことをユーザーに通知する必要がある場合に適した戦略です。
バックアップ データベースに書き込みます。 これは、エラーを解決できないが、リクエスト データが失われるリスクを避けたい場合に適した戦略です。
操作を1 回のデフォルトの 再試行 を超えて再試行します。 これは、エラーの原因をプログラムで解決して再試行する場合に適した戦略です。
アプリケーションのコンテキストに最適な戦略を選択する必要があります。
例
重複キー エラーの例では、エラーをログに記録する必要がありますが、操作は成功しないため、再試行しないでください。 代わりに、フォールバック データベースに書き込みを行い、後でそのデータベースの内容を確認して、情報が失われることを確認することができます。 ユーザーは他に何もする必要がなく、データが記録されるため、クライアントにエラーメッセージを送信しないことを選択できます。
ネットワークエラーの計画
操作が完了せず、アプリケーションが新しい操作を実行する際にブロックされる場合は、エラーを返すことが推奨されます。 maxTimeMSメソッドを使用して、個々の操作に時間制限を設定でき、その時間制限を超えた場合にアプリケーションが処理するエラーを返します。
各操作に設定する時間制限は、その操作のコンテキストによって異なります。
例
アプリケーションがinventoryコレクションから簡単な製品情報を読み取って表示する場合、これらの読み取り操作にかかる時間は 1 時間のみであることがかなり確実です。 クエリの実行時間が異常に長い場合は、ネットワークの問題が永続していることを示す適切なインジケーターです。 この操作でmaxTimeMSを 5000、つまり 5 秒に設定すると、アプリケーションはネットワークの問題があることを確認するとすぐにフィードバックを受け取ることを意味します。
回復力のあるサンプルアプリケーション
次のサンプルアプリケーションでは、回復力のあるアプリケーションを構築するための推奨事項をまとめています。
このアプリケーションは 、 http://localhost:3000 で 2 つのエンドポイントを公開するシンプルなユーザー レコードAPIです。
方式 | エンドポイント | 説明 |
|---|---|---|
|
|
|
|
| リクエスト本文に |