FAQ

MongoDB への接続中にエラーが発生するのはなぜですか?

MongoDB 配置への接続に問題がある場合は、考えられる解決策について接続トラブルシューティング ガイドを参照してください。

.NET/C# ドライバーで接続プーリングはどのように機能しますか。

すべての MongoClientインスタンスには、MongoDB トポロジー内の各サーバーに対する接続プールが組み込まれています。 接続プールはオンデマンドでソケットを開き、マルチスレッド アプリケーションで同時 MongoDB 操作をサポートします。

各接続プールの最大サイズはMaxConnectionPoolSizeオプションによって設定され、デフォルトは100になります。 サーバーへの使用中の接続数がMaxConnectionPoolSizeの値に達した場合、そのサーバーへの次のリクエストは、接続が利用可能になるまで待機します。 次の図は、 MongoClientが接続プールを管理する方法の概要を示しています。

アプリケーションのスレッドをサポートするために必要なソケットに加えて、各MongoClientインスタンスは、サーバーの状態を監視するために MongoDB トポロジー内のサーバーごとに 2 つの追加のソケットを開きます。 たとえば、3 ノードのレプリカセットに接続されたクライアントは、6 つの監視ソケットを開きます。 アプリケーションがMaxConnectionPoolSizeのデフォルト設定を使用し、プライマリ（デフォルト）ノードのみをクエリする場合、最大合計接続数は最大106使用できます。 アプリケーションが読み込み設定（ read preference ）を使用してセカンダリ ノードをクエリする場合、それらの接続プールは増大し、合計接続数は306になる可能性があります。

1 つのプロセス内で多数の同時 MongoDB スレッドをサポートするには、 MaxConnectionPoolSizeを増やすことができます。

ドライバーには、接続を待機できるスレッド数を制限する待機キューがあります。 待機キューのサイズはWaitQueueMultipleオプションによって決まります。デフォルトは5です。 待機キューの最大サイズを計算するために、ドライバーはWaitQueueMultipleにMaxConnectionPoolSizeを乗算します。 各オプションにデフォルト値を使用する場合、待機キューのサイズは500になります。 また、 WaitQueueSizeオプションを指定して待機キューのサイズを設定することもできます。これにより、他の設定が上書きされます。 ただし、待機キューのサイズをデフォルトから変更することはお勧めしません。

Connection pools are rate-limited. MaxConnectingの設定により、プールがいつでも並列に作成できる接続数が決まります。 たとえば、 MaxConnectingの値が2の場合、接続を同時にチェックアウトしようとする 3 つ目のスレッドは、次のいずれかの場合にのみ成功します。

• 最初の 2 つのスレッドのうち 1 つは接続の作成を完了します。

• 既存の接続がプールにチェックバックされます。

• 接続作成のレート制限により、既存の接続を再利用するドライバーの能力が向上します。

各サーバーへの同時接続の最小数はMinConnectionPoolSizeオプションを使用して設定できます。このオプションのデフォルトは0です。 接続プールはこのソケット数で初期化されます。 エラーによりいずれかのソケットが閉じ、ソケットの合計数（使用中とアイドル状態の両方）が最小値を下回ると、ドライバーは数が最小値に達するまでさらにソケットを開きます。

MaxConnectionIdleTimeオプションを使用して、プール内で接続がアイドル状態を維持できる最大ミリ秒数を設定できます。 MaxConnectionIdleTimeの接続がアイドル状態になると、ドライバーはその接続を削除します。 このオプションのデフォルトは 10 分です。 プール サイズがMinConnectionPoolSizeを下回ると、ドライバーはアイドル接続を削除して置き換えます。

MongoClient には、期限が切れる前に接続をプールできる時間の長さを指定するMaxConnectionLifeTimeオプションもあり、デフォルトでは 30 分です。

MongoClientの次のデフォルト構成はほとんどのアプリケーションで動作します。

var client = new MongoClient("<connection string>");

クライアントはプロセスごとに 1 回作成し、すべての操作で再利用します。 リクエストごとに新しいクライアントを作成することがよくあり、非常に非効率的です。

ドライバー でMongoClientを終了する方法はサポートされていません。

サーバー選択中にドライバーがタイムアウトをスローするのはなぜですか?

各ドライバー操作には、サーバー選択基準 を満たす正常なサーバーを選択する必要があります。サーバー選択タイムアウト 内に適切なサーバーを選択しない場合、ドライバーはサーバー選択タイムアウトの例外をスローします。例外は、次のようになります。

A timeout occurred after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 }, OperationsCountServerSelector }.
Client view of cluster state is
{
    ClusterId : "1",
    Type : "Unknown",
    State : "Disconnected",
    Servers :
    [{
        ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/localhost:27017" }",
        EndPoint: "Unspecified/localhost:27017",
        ReasonChanged: "Heartbeat",
        State: "Disconnected",
        ServerVersion: ,
        TopologyVersion: ,
        Type: "Unknown",
        HeartbeatException: "<exception details>"
    }]
}.

エラーメッセージは複数の部分で構成されています。

1. サーバー選択タイムアウト（30000 ミリ秒）。

2. 検討されたサーバー セレクター（CompositeServerSelector AreSessionsSupportedServerSelectorLatencyLimitingServerSelector、 、 を含むOperationsCountServerSelector ）

3. クラスター トポロジーのドライバーの現在のビュー。 ドライバーが認識しているサーバーのリストは、このビューの重要な部分です。 各サーバーの説明には、エンドポイント、サーバーバージョン、サーバーのタイプ、現在のヘルス状態に関する情報など、そのサーバーの現在の状態を網羅的な説明が含まれています。 サーバーが正常性をレポートする際に問題が発生した場合、 HeartbeatExceptionには最後に失敗したハートビートからの例外が含まれます。 各クラスター ノードのHeartbeatExceptionを分析すると、ほとんどのサーバー選択の問題を診断するのに役立ちます。 次のハートビートの例外はよくあることです。

   • No connection could be made because the target machine actively refused it: ドライバーはこのクラスター ノードを参照できません。 これは、クラスター ノードがクラッシュしたり、ファイアウォールによってネットワーク トラフィックがクラスター ノードまたはポートに到達しなくなったり、その他のネットワークエラーがトラフィックをクラスター ノードに正常にルーティングできなくなったりしていることが原因です。

   • Attempted to read past the end of the stream: このエラーは、ネットワークエラー、ファイアウォールの設定誤り、またはその他のネットワーク問題により、ドライバーがクラスター ノードに接続できない場合に発生します。 この例外に対処するには、すべてのクラスター ノードがアクセス可能であることを確認します。 このエラーは通常、クライアント マシンの IP アドレスが Atlas IP アクセス リストで構成されていない場合に発生します。このリストは、Atlas プロジェクトの [ Network Accessタブで確認できます。

   • The remote certificate is invalid according to the validation procedure: このエラーは通常、期限切れ/無効な証明書やルート CA など、TLS/SSL 関連の問題を示します。 TLS/SSL 関連の証明書の問題をデバッグするには、 openssl s_clientなどのツールを使用します。

ドキュメントをクエリするときに、LINQ クラスまたはビルダ クラスを使用する必要がありますか？

C# でプログラミングに使用されている場合は、ネイティブ C# でのプログラミングと操作性が似ているため、LINQ の使用を検討してください。 他の MongoDB ドライバーを使用した経験がある場合は、他のドライバーとの整合性があるため、ビルダ クラスの使用を検討してください。

目的に最も適したメカニズムを決定するために、両方のアプローチを試すことをお勧めします。

特定の LINQ またはビルダ式がサポートされていない理由

各 LINQ または Builder 式は Query API で使用できる必要があります。 これは、次の理由により、必ずしも可能ではありません。

1. 同等の MongoDB 表現を持たない .NET/C# 機能を使用しようとしている たとえば、.NET/C# と MongoDB では照合に関するセマンティクスが異なります。

2. ドライバーでは、LINQ または Builder 式から MQL（MongoDB 問い合わせ言語）への特定の変換はサポートされていません。 これは、提供されたクエリに MQL の変換がない場合、またはドライバーに機能がまだ実装されていないために発生する可能性があります。

Unsupported filter ...またはExpression not supported ...の例外メッセージが表示された場合は、次の手順をお試しください。

1. 新しい LINQ3 の構成を試す プロバイダー。LINQ 3プロバイダーには、LINQ 2プロバイダーに対する多くの修正と新機能が含まれています。

2. MongoDB C# Analyzerを使用して式を分析します。

3. 可能な場合はクエリを簡素化するようにしてください。

4. クエリはBsonDocumentまたは JSON string として指定します。 FilterDefinition 、 ProjectionDefinition 、 PipelineDefinitionなどのすべてのドライバー定義クラスは、 BsonDocumentまたは JSON string からの暗黙的な変換をサポートしています。 たとえば、次のフィルターは、クエリまたは集計で使用する場合に同等です。

FilterDefinition<Entity> typedFilter = Builders<Entity>.Filter.Eq(e => e.A, 1);
FilterDefinition<Entity> bsonFilter = new BsonDocument {{ "a", 1 }};
FilterDefinition<Entity> jsonFilter = "{ a : 1 }";

次のコードが示すように、同じクエリで未加工の形式と型付きの形式を組み合わせることができます。

FilterDefinition<Entity> filter = Builders<Entity>.Filter
    .And(Builders<Entity>.Filter
        .Eq(e => e.A, 1), BsonDocument
        .Parse("{ b : 2 }"));

どのオブジェクトタイプをシリアル化できますか

ObjectSerializerは、安全と見なされるタイプの直列化と逆直列化のみを許可します。 ObjectSerializerを構築する際、 Func<Type, bool>タイプの委任を渡すことができます。 この委任はオブジェクトタイプを受け入れ、そのタイプが直列化に安全かどうかを示すブール値を返します。

ほとんどの場合、 ObjectSerializer.DefaultAllowedTypes()委任を渡す必要があります。 このメソッドは、安全であると判断した既知のフレームワーク タイプの数に対して true を返します。 カスタムタイプをシリアル化するには、含めるタイプに対してtrueと評価されるブール値の式を作成します。 次に、この式をObjectSerializerコンストラクターに渡す委任の末尾に追加します。

次の例では、 ObjectSerializerは、 ObjectSerializer.DefaultAllowedTypes()によって許可されているタイプ、またはフル名が"MyNamespace"で始まるタイプを直列化および逆直列化します。

var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type)
    || type.FullName.StartsWith("MyNamespace"));
BsonSerializer.RegisterSerializer(objectSerializer);

匿名型をシリアル化するには、次の例に示すように、ブール値type.FullName.StartsWith("<>f__AnonymousType"))を削除に追加します。

var objectSerializer = new ObjectSerializer(type => ObjectSerializer.DefaultAllowedTypes(type)
    || type.FullName.StartsWith("<>f__AnonymousType"));
BsonSerializer.RegisterSerializer(objectSerializer);

他の操作を行う前に、プログラムの開始時にObjectSerializerを作成して登録する必要があります。

.NET/C# ドライバーと MongoDB Entity Framework コア プロバイダーの違いは何ですか?

.NET/C# ドライバーは、MongoDB 機能を直接公開し、プロジェクション、グループ操作、柔軟なマッピングを持つ LINQ プロバイダーを含むライブラリです。 ドライバーには次のような機能が含まれています。

• トランザクション

• 一括操作

• LINQ クエリ

• データベースを直接変更する操作

• 集計操作

• カスタムマッピング

Entity Framework コアプロバイダーを使用すると、.NET/C# アプリケーションで MongoDB とともに Microsoft の Entity Framework コア を使用できます。 Entity Framework コアプロバイダーは、変更追跡、エンティティベースの LINQ 操作、および Entity Framework コア ユーザーに適したモデリングをサポートしています。 プロバイダーには、次のような機能が含まれています。

• 高度なオブジェクト追跡

• エンティティベースの LINQ 操作

• Flutter API による Entity Framework のモデリングとマッピング

• 変更追跡によるデータベースの自動更新