MongoDB MongoClientOptions Sınıfı - Kullanmayın

Giriş

Şu satırı dahil ederiz.

import com.mongodb.MongoClientOptions;

Yeni kodlarda MongoClientSettings kullanılmalı

connectionsPerHost metodu

Açıklaması şöyle

connectionsPerHost are the amount of physical connections a single Mongo instance (it's singleton so you usually have one per application) can establish to a mongod/mongos process. At time of writing the java driver will establish this amount of connections eventually even if the actual query throughput is low (in order words you will see the "conn" statistic in mongostat rise until it hits this number per app server).

There is no need to set this higher than 100 in most cases but this setting is one of those "test it and see" things. Do note that you will have to make sure you set this low enough so that the total amount of connections to your server do not exceed

db.serverStatus().connections.available

In production we currently have this at 40.

Eğer connection sayısı yetersiz ise thread'ler beklemeye başlarlar. Bekleyen thread sayısı driver'da atanmış sayıyı geçerse şöyle bir hata alırız

Exception in thread "pool-1-thread-301" com.mongodb.MongoWaitQueueFullException:
 Too many threads are already waiting for a connection.
 Max number of threads (maxWaitQueueSize) of 500 has been exceeded.

Şöyle yaparız

MongoClientOptions.Builder builder = new MongoClientOptions.Builder();
builder.connectionsPerHost(200);
MongoClientOptions options = builder.build();
mongoClient = new MongoClient(URI, connectionOptions);

writeConcern metodu

Örnek

Şöyle yaparız

@Bean
public MongoClientOptions mongoClientOptions(){
  return MongoClientOptions.builder()
    .readConcern(ReadConcern.LOCAL)
    .writeConcern(WriteConcern.W1)
    .readPreference(ReadPreference.primary())
    .serverSelectionTimeout(120000)
    .maxWaitTime(120000)
    .connectionsPerHost(10)
    .connectTimeout(120000).build();
}

ACKNOWLEDGED için açıklaması şöyle

The following are the WriteConcern options you can configure on a per-connection, per-database, per-collection, or even per-operation basis.

The options are as follows-

Write Acknowledged- This will use the default Write concern configured on the server and wait for the server’s acknowledgment.

You can pass the w value to define the Write Acknowledgement behavior.

W0: With this concern, the write operation will not wait for an acknowledgment from the server. In this case, the data can be rolled back if the primary step-down before the write operation is replicated to secondary.

W1: With this concern, the write operation will wait for an acknowledgment from Primary in case of a replica set. In this case, data can be rolled back if the primary step-down gets replicated to the secondary before the write operation.

W2: With this concern, the write operation will wait for an acknowledgment from the Primary and one of the Secondaries.

W3: With this concern, the write operation will wait for an acknowledgment from the Primary and both the Secondaries.

Bir başka açıklama şöyle

This value determines the "safety" of the write. When this value is -1 the write will not report any errors regardless of network or database errors. WriteConcern.NONE is the appropriate predefined WriteConcern for this. If w is 0 then network errors will make the write fail but mongo errors will not. This is typically referred to as "fire and forget" writes and should be used when performance is more important than consistency and durability. Use WriteConcern.NORMAL for this mode.

If you set w to 1 or higher the write is considered safe. Safe writes perform the write and follow it up by a request to the server to make sure the write succeeded or retrieve an error value if it did not (in other words, it sends a getLastError() command after you write). Note that until this getLastError() command is completed the connection is reserved. As a result of that and the additional command the throughput will be significantly lower than writes with w <= 0. With a w value of exactly 1 MongoDB guarantees the write succeeded (or verifiably failed) on the instance you sent the write to.

In the case of replica sets you can use higher values for w which tell MongoDB to send the write to at least "w" members of the replica set before returning (or more accurately, wait for the replication of your write to "w" members). You can also set w to the string "majority" which tells MongoDB to perform the write to the majority of replica set members (WriteConcern.MAJORITY). Typicall you should set this to 1 unless you need raw performance (-1 or 0) or replicated writes (>1). Values higher than 1 have a considerable impact on write throughput.

Diğer seçenekler için açıklama şöyle

Journal Acknowledged: With this concern, the Write operation will be confirmed by the server after it gets flushed to the journal on the primary. Write operation with this concern ensures durable data on the disk, even if the MongoDB server crashes.

Replica Acknowledged: This is a deprecated option and the preferred option is to use the WriteConcern W2, which behaves the same as the Replica-set acknowledgment concern.

Majority: With this concern, the write operation waits for a majority of the replica set data-bearing and electable members, and it cannot be rolled-back even in the event of a primary election. This concern also ensures that the write operation gets recorded in the journal on a majority of replicas, including primary.