Added as a suppport case here : https://support.mongodb.com/case/00634630

When using the connector as a Source, i.e we capture change streams from the Source Mongo DB and stream that to a Kafka endpoint.

Imagine these are updates on financial transactions in mongodb and they are NOT tolerant to
1) missed data and
2) duplicated data
in that order.

So, we need to make sure that the Change Streams that we are observing(matching) on, are delivered once and exactly once to the Kafka pipeline. (Blog on the same : https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/). If exactly-once semantics are enabled, it makes commits transactional by default.

We were informed verbally that the connector supports once-only-semantics, however if it is not available in the worst case, we would need atleast-once-semantics enabled to make sure that we do not loose data in the any case.

What is the problem that needs to be solved? Store (historically) serverStatus.uptime counter info on MongoDB Server process, so that it will be possible to track serverStatus.uptime changes through the time.

Why is it a problem? (the pain) As of now (2020-02-25) there's no way to see historical info of MongoDB Server process restarts since serverStatus.uptime counter is restarted every time MongoDB Server process is restarted. There's no other way (other than going into MongoDB Server process logs) to know if the process was restarted and when it was restarted. If you'd like to calculate MongoDB Server process availability, you'll need to analyze MongoDB Server process logs/monitor MongoDB Server process Process IP (PID).

Hello.
We are preparing to introduce MongoDB 4.2 and expect distributed transaction function.

I read document which arbiter don't be member when use distributed transaction.
>> https://docs.mongodb.com/manual/core/transactions/index.html#arbiters

PSA can do that, but it's weird that it doesn't even work out to PSSA.

It usually operates as a PSS from an operating point of view, but can temporarily become a PSA in the event of equipment problems.

Why should there be no Arbiter in the Shard to use Distributed Transaction?
I can not understand restriction.

Can you tell me technical reason for not being able to support Distributed Transaction with Arbiter?
Do you have plans to improve in the next version?

Deleting tens of millions of documents can have a big impact on the performance of the Clusters, even using Bulk Delete. A "Limit" must be added to Delete and Bulk Delete to let us limit the number of operations, making sure we do not kill the Clusters' performance.

• For the delete, this would make sure we only delete n number of documents.


• For the Bulk Delete, this would also make sure we only delete n number of documents, or it could instead limit the number of batches/groups of documents to be deleted.

Right now, the only solution is a hack, which is to query the documents with a Limit and a projection to get the IDs, then delete only those. This means we need to do large queries/projections and large delete operations. This workaround/hack is not efficient and not good in any possible way. It is, after all, just a temporary hack we have to use until a valid solution is supported by MongoDB, which is to add a Limit to deletes.