FAQ

MongoDB에 연결하는 동안 오류가 발생하는 이유는 무엇인가요?

MongoDB deployment에 연결하는 데 문제가 있는 경우 연결 문제 해결 가이드에서 가능한 해결 방법을 참조하세요.

.NET/C# 드라이버에서 연결 풀링은 어떻게 작동하나요?

모든 MongoClient 인스턴스에는 MongoDB 토폴로지의 각 서버에 대한 기본 제공 연결 풀이 있습니다. 연결 풀은 필요에 따라 소켓을 열어 멀티스레드 애플리케이션에서 동시 MongoDB 작업을 지원합니다.

각 연결 풀의 최대 크기는 MaxConnectionPoolSize 옵션으로 설정되며 기본값은 100 입니다. 서버에 대한 사용 중인 연결 수가 MaxConnectionPoolSize 값에 도달하면 해당 서버에 대한 다음 요청은 연결을 사용할 수 있을 때까지 대기합니다. 다음 다이어그램은 MongoClient 가 연결 풀을 관리하는 방법에 대한 높은 수준의 보기를 보여줍니다.

애플리케이션의 스레드를 지원하는 데 필요한 소켓 외에도 각 MongoClient 인스턴스는 MongoDB 토폴로지에서 서버당 두 개의 추가 소켓을 열어 서버 상태를 모니터링합니다. 예를 들어, 3노드 복제본 세트에 연결된 클라이언트는 6개의 모니터링 소켓을 엽니다. 애플리케이션이 MaxConnectionPoolSize 에 대한 기본 설정을 사용하고 프라이머리(기본) 노드만 쿼리하는 경우, 사용 중인 총 연결은 최대 106 개일 수 있습니다. 애플리케이션이 읽기 설정 을 사용하여 세컨더리 노드를 쿼리하는 경우 이러한 연결 풀이 커져 총 연결 수가 306 개가 될 수 있습니다.

한 프로세스 내에서 많은 수의 동시 MongoDB 스레드를 지원하려면 MaxConnectionPoolSize를 늘리면 됩니다.

드라이버에는 연결을 기다릴 수 있는 스레드 수를 제한하는 대기열이 있습니다. 대기열의 크기는 WaitQueueMultiple 옵션에 의해 결정되며 기본값은 5입니다. 드라이버는 최대 대기열 크기를 계산하기 위해 WaitQueueMultiple에 MaxConnectionPoolSize를 곱합니다. 각 옵션에 기본값을 사용하는 경우 대기열 크기는 500입니다. 다른 설정을 재정의하는 WaitQueueSize 옵션을 지정하여 대기열 크기를 설정할 수도 있습니다. 그러나 대기열 크기를 기본값에서 변경하지 않는 것이 좋습니다.

연결 풀은 속도 제한이 있습니다. MaxConnecting 설정은 풀이 언제든지 병렬로 생성할 수 있는 연결 수를 결정합니다. 예를 들어 MaxConnecting 값이 2인 경우 연결을 동시에 체크아웃하려고 시도하는 세 번째 스레드는 다음 중 하나의 경우에만 성공합니다.

• 처음 두 스레드 중 하나가 연결 만들기를 완료합니다.

• 기존 연결이 풀로 다시 확인됩니다.

• 연결 생성에 대한 속도 제한으로 인해 기존 연결을 재사용하는 드라이버의 기능이 향상됩니다.

MinConnectionPoolSize 옵션(기본값 0)을 사용하여 각 서버에 대한 최소 동시 연결 수를 설정할 수 있습니다. 연결 풀은 이 수의 소켓으로 초기화됩니다. 오류로 인해 소켓이 닫히고 총 소켓 수(사용 중인 소켓과 유휴 상태 모두)가 최소값 아래로 떨어지면 드라이버는 해당 수가 최소값에 도달할 때까지 소켓을 추가로 엽니다.

MaxConnectionIdleTime 옵션을 사용하여 연결이 풀에서 유휴 상태로 유지될 수 있는 최대 시간(밀리초)을 설정할 수 있습니다. MaxConnectionIdleTime에 대한 연결이 유휴 상태가 되면 드라이버가 연결을 제거합니다. 이 옵션의 기본값은 10분입니다. 풀 크기가 MinConnectionPoolSize 미만으로 떨어지면 드라이버가 유휴 연결을 제거하고 대체합니다.

MongoClient 에는 MaxConnectionLifeTime 옵션도 있습니다. 이 옵션은 만료되기 전에 연결을 풀링할 수 있는 시간(기본적으로 30분)을 지정합니다.

MongoClient에 대한 다음 기본 구성은 대부분의 애플리케이션에서 작동합니다.

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

각 프로세스에 대해 한 번씩 클라이언트를 생성하고 모든 작업에 재사용합니다. 각 요청에 대해 새 클라이언트를 생성하는 것은 흔한 실수이며 이는 매우 비효율적입니다.

드라이버에서 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. 고려된 서버 선택기(AreSessionsSupportedServerSelector, LatencyLimitingServerSelector, OperationsCountServerSelector가 포함된 CompositeServerSelector).

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 프로젝트의 Network Access 탭 아래에 있는 Atlas IP 액세스 목록에 구성되어 있지 않을 때 발생합니다.

   • The remote certificate is invalid according to the validation procedure: 이 오류는 일반적으로 만료되었거나 유효하지 않은 인증서 또는 신뢰할 수 없는 루트 CA와 같은 TLS/SSL 관련 문제를 나타냅니다. openssl s_client와 같은 도구를 사용하여 TLS/SSL 관련 인증서 문제를 디버깅할 수 있습니다.

문서를 쿼리할 때 LINQ 또는 빌더 클래스를 사용해야 하나요?

C#으로 프로그래밍하는 데 익숙하다면 기본 C#으로 프로그래밍하는 것과 비슷한 느낌을 주는 LINQ를 사용하는 것이 좋습니다. 다른 MongoDB 드라이버를 사용해 본 경험이 있다면 다른 드라이버와의 일관성을 위해 빌더 클래스를 사용하는 것이 좋습니다.

두 가지 접근 방식을 모두 실험해보고 목적에 가장 적합한 메커니즘을 결정하는 것이 좋습니다.

특정 LINQ 또는 빌더 표현식이 지원되지 않는 이유는 무엇인가요?

각 LINQ 또는 빌더 표현식은 Query API에서 사용할 수 있어야 합니다. 다음과 같은 이유로 항상 가능한 것은 아닙니다.

1. 이에 해당하는 MongoDB 표현이 없는 .NET/C# 기능을 사용하려고 합니다. 예를 들어 .NET/C#과 MongoDB는 데이터 정렬과 관련하여 서로 다른 의미를 가집니다.

2. 드라이버는 LINQ 또는 빌더 표현식에서 MQL(MongoDB 쿼리 언어)로의 특정 변환을 지원하지 않습니다. 이는 제공된 쿼리에 MQL 변환이 없거나 드라이버에 기능이 아직 구현되지 않았기 때문에 발생할 수 있습니다.

Unsupported filter ... 또는 Expression not supported ... 예외 메시지가 표시되면 다음 단계를 시도해 보세요.

1. 새 LINQ3 를 구성해 보세요. 제공자. LINQ3 제공자에는 LINQ2 제공자에 비해 많은 수정 사항과 새로운 기능이 포함되어 있습니다.

2. MongoDB C# 분석기 를 사용하여 표현식을 분석합니다.

3. 가능하면 쿼리를 단순화합니다.

4. 쿼리를 BsonDocument 또는 JSON 문자열로 제공합니다. FilterDefinition, ProjectionDefinition, PipelineDefinition과 같은 모든 드라이버 정의 클래스는 BsonDocument 또는 JSON 문자열로부터의 암시적 변환을 지원합니다. 예를 들어 다음 필터는 쿼리 또는 집계에 사용될 때 동일합니다.

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 엔티티 프레임워크 코어 제공자의 차이점은 무엇인가요?

.NET/ C# 드라이버 는 MongoDB 기능을 직접 노출하는 라이브러리이며 프로젝션, 그룹 작업 및 유연한 매핑을 제공하는 LINQ 제공자 를 포함합니다. 운전자 에는 다음과 같은 기능이 포함되어 있습니다.

• 트랜잭션

• 대량 작업

• LINQ 쿼리

• 데이터베이스 를 직접 수정하는 작업

• 집계 작업

• 사용자 지정 매핑

Entity Framework Core Provider 를 사용하면 .NET/ C# 애플리케이션에서 Microsoft의 Entity Framework Core를 MongoDB 와 함께 사용할 수 있습니다. Entity Framework Core Provider는 변경 추적, 엔터티 기반 LINQ 작업 및 Entity Framework Core 사용자에게 친숙한 모델링을 지원합니다. 제공자 에는 다음과 같은 기능이 포함되어 있습니다.

• 지능형 객체 추적

• 엔터티 기반 LINQ 작업

• Fluent API 를 사용한 Entity Framework 모델링 및 매핑

• 변경 사항 추적을 통한 자동 데이터베이스 업데이트