Using MongoDB in .NET is easy. However, there are two ways to manipulate the documents in C# code: raw bson document or stronly-typed document. In this article, we will compare the difference of them by examples. Basically, strongly-typed collection is preferred unless you have strong reason to use weakly-typed document (different types in the same collection?).
MongoDB事务是个很好的功能，但对于高并发场景下的多文档事务，写冲突难以避免。一个写冲突的实例:
Exception: Command update failed: Encountered error from mongodb.svc.cluster.local:27017 during a transaction :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction..
那么如何正确实现事务的重试？
MongoDB transaction is a nice feature. Although MongoDB uses optimistic concurrency control, write conflict is unavoidable. The situation becomes worse in multi-document transaction which modifies many documents in one transaction. If a write conflict happens, a MongoDBCommandException will be thrown:
Exception: Command update failed: Encountered error from mongodb.svc.cluster.local:27017 during a transaction :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction..
How to handle the writeconflict error in MongoDB?
Today I try to import an existing MongoDB deployment (out of the kubernetes cluster) into MongoDB Ops Manager which is running in kubernetes. After installing MongoDB Agent to the deployment, only automation functionality works while monitoring and backup not work. The root cause is that the agent still try to post data into Ops Manager's internal endpoint.
I have a sharded cluster (2 shards, each 3 mongods; 3 config server, 2 mongoses) which is deployed by MongoDB Ops Manager.
Last week, one of the shard host status was shown as a grey diamond
(Hover: "Last Ping: Never"). Besides, in the Ops Manager's server page,
a server had two processes (e.g. sharddb-0 and
sharddb-config). However, the cluster still works well and
we can list the host sharddb-0-0(shard 0, replica 0) in the
mongo shell by sh.status() and rs.status().
What's wrong with the cluster?
在一个分片MongoDB集群上并发执行transaction时遇到许多MongoCommandException错误:
code 251, codename NoSuchTransaction:
Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 5. Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 6. Command insert failed: cannot continue txnId 31 for session 3ed7ea61-eae1-440f-8d95-b6e066b35b69 - = with txnId 34.
When I execute MongoDB transactions in parallel, I encounter lots of
MongoCommandException: code 251, codename
NoSuchTransaction:
Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 5. Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 6. Command insert failed: cannot continue txnId 31 for session 3ed7ea61-eae1-440f-8d95-b6e066b35b69 - = with txnId 34.
Lightsquid is a handy log analyzer for squid proxy. However, the project is not maintained since 2009.
Today, I found lightsquid doesn't work in 2021. Why?
MongoDB sharded cluster is the most complicated architecture. The deployment of sharded cluster in Kubernetes is relatively hard. We will go through the deployment process by MongoDB Ops Manager in this post.
Before start, please go through the Create a UserDB ReplicaSet first.
A MongoDB sharded
cluster consists of the following components: - shard:
Each shard contains a subset of the sharded data. Each shard can be
deployed as a replica
set. - mongos:
The mongos acts as a query router, providing an interface
between client applications and the sharded cluster. - config
servers: Config servers store metadata and configuration settings
for the cluster.
In this post, we are going to create a sharded cluster with 2 shards (3 instances replica set), 2 mongos and 3 config servers.
MongoDB Ops Manager Series:
Sharded cluster是MongoDB部署中最复杂的形式，因为Sharded cluster的组件较多，部署步骤也更为繁琐。在实际部署中还有几个部署ReplicaSet时没遇到的证书和TLS问题。阅读本文前，强烈建议先阅读 创建用户数据库(replicaset) 作为基础。
一个Sharded cluster由三部分构成：
本文以创建一个2个Shard（每个由3实例ReplicaSet构成），2个mongos及3个config server的sharded cluster为例，演示具体部署流程。本文可做为Kubernetes部署MongoDB集群的番外篇。
整个系列：