Finisky Garden

It's pretty easy to configure a MongoDB standalone instance (almost zero configuration). However, if you want to run a production-level MongoDB cluster, the configuration process is non-trivial. For a production cluster, replication/sharding/dyanmic scaling/backup/transport encryption/monitoring are required. Is there a nice tool to help us?

MongoDB cluster is a distributed system, which is well suited to run in Kubernetes. However, the collaboration of MongoDB instances usually need to manually run commands on each instance which is independent of Kubernetes. Therefore, MongoDB Enterprise Kubernetes Operator is developed to mitigate the gap. Morever, MongoDB Ops Manager is a great web portal to help these automation tasks.

The whole deployment and configure process is a little bit long, I wrote a series of small pieces to make each of them compact and easy to follow:

1. Install MongoDB Ops Manager
2. Create a UserDB ReplicaSet
3. Expose UserDB to Public
4. Openssl Generates Self-signed Certificates
5. Enable UserDB TLS and Auth

Prerequisites

• Have a Kubernetes cluster
• Basic understanding of MongoDB
• Basic understanding of Kubernetes deployment/service/statefulset
• Familiar with kubectl operations

This is part1, we first introduce the MongoDB Ops Manager components, then install it into your Kubernetes cluster.

本文为系列第五部分，用生成的自签名证书打开userdb的TLS和AUTH，并且完成userdb的公网域名访问。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

本文为系列第四部分，相对独立，先生成一个自签名CA证书，然后生成MongoDB各个server证书。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

自签名证书不推荐在生产环境使用，虽然它可以保证通信过程中的加密，但不能避免中间人攻击。Public Key Infrastructure (PKI)相关的内容也不在本文的讨论范围，这里假设读者对PKI已有基本的认识。

本文为系列第三部分，使用第二部分创建好的userdb可以从公网访问，方法是通过Kubernetes Service暴露userdb pod到公网上。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

官方文档是通过NodePort的方式暴露给公网，而我们这里是通过创建service的方式完成，好处是这种方式不必管理pod和node之间的端口映射，也不必担心pod被调度到不同node上之后IP的改变。不知道官方使用NodePort进行服务暴露是基于怎样的考虑。 # Connect to a MongoDB Database Resource from Outside Kubernetes

本文为系列第二部分，使用第一部分安装好的MongoDB Ops Manager创建用户数据库。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

所谓的Application Database是MongoDB Ops Manager的后端DB，并不能用来存放用户数据，所以我们需要用Ops Manager创建用户数据库。使用Ops Manager创建的MongoDB叫做Deployment，注意此Deployment是MongoDB Deployment，与kubernetes的Deployment不是一码事。

简单起见，本文以创建一个3实例的MongoDB userdb为例，Sharding Cluster由于组件复杂，server数量更多，配置比ReplicaSet要麻烦些，但配置过程基本一致。可参考： MongoDB Ops Manager部署Sharded Cluster

MongoDB的入门配置门槛（单机）很低，但如果想达到生产环境的要求则有些技术含量。生产环境的配置要求包括Replica Set、Sharding、Scale up/down、数据备份、通信加密TLS和指标实时监控等。配置这些功能比较繁琐，有不少坑要踩。那么有没有好用的工具帮我们配置和管理呢？

MongoDB是个分布式系统，且需要动态的增加或删除节点，那么与kubernetes结合使用则是珠联璧合。结合之后就需要一套kubernetes工具对其进行管理，它就是MongoDB Enterprise Kubernetes Operator，更进一步，可以使用MongoDB Ops Manager完成上面所有生产环境的配置需求。

整个配置流程比较繁杂，为不使一篇万字长文吓到读者，写成了系列教程，力求每一块简明内聚：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

阅读教程前提：有Kubernetes集群，了解deployment/service/statefulset含义，熟悉kubectl基本操作。

本文为系列第一部分，简介MongoDB Ops Manager Kubernetes的构成，以及如何安装MongoDB Ops Manager。

如果你按官方文档 Configure mongod and mongos for TLS/SSL 配置MongoDB证书，可能会遇到如下问题：

{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"E",  "c":"NETWORK",  "id":23248,   "ctx":"main","msg":"Cannot read certificate file","attr":{"keyFile":"/etc/ssl/testserver1.pem","error":"error:0200100D:system library:fopen:Permission denied"}}
{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"F",  "c":"CONTROL",  "id":20574,   "ctx":"main","msg":"Error during global initialization","attr":{"error":{"code":140,"codeName":"InvalidSSLConfiguration","errmsg":"Can not set up PEM key file."}}}

or

{"t":{"$date":"2020-11-30T08:01:14.545+00:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"permissions on / are too open"}}}

真难伺候，一会儿没权限读证书，一会儿权限太开放了，到底证书要什么权限？官方文档没加个tips解释这些细节，可能假设用户对PKI和证书这套东西非常熟悉。

运行mongod的用户是mongodb，所以看起来证书权限需要是：能让用户mongodb读此证书但不能修改。

When you setup TLS/SSL for MongoDB Configure mongod and mongos for TLS/SSL, you might encounter the following errors:

{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"E",  "c":"NETWORK",  "id":23248,   "ctx":"main","msg":"Cannot read certificate file","attr":{"keyFile":"/etc/ssl/testserver1.pem","error":"error:0200100D:system library:fopen:Permission denied"}}
{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"F",  "c":"CONTROL",  "id":20574,   "ctx":"main","msg":"Error during global initialization","attr":{"error":{"code":140,"codeName":"InvalidSSLConfiguration","errmsg":"Can not set up PEM key file."}}}

or

{"t":{"$date":"2020-11-30T08:01:14.545+00:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"permissions on / are too open"}}}

So what's the right ownership and permission for the certificate pem file? The answer is: the pem file should have read access but no write access for the user mongodb.

最近遇到个数据库表设计的问题，一张账号表，业务逻辑存在一列唯一accountId，是否还要在数据库表中加一列自增int作为主键？这应该是实践中普遍存在的问题，于是研究了下推荐做法。

简单回答：这个问题没有明确答案，看情况决定。stackoverflow的相关问题已经被标记为带有观点的回答。没有答案的原因在于是否需要自增主键主要取决于应用场景。不过我倾向于在绝大部分情况下，使用自增int主键，如有必要，增加额外的唯一键（如这里的accountId）进行索引和查询。

如下讨论都基于InnoDB引擎。

对一个DBA来说监控mysql服务器的性能指标是非常重要的。我们可以通过mysqlbench中的Server Status来轻松监测服务器最近一段时间的状态。但是这些指标具体代表了什么含义？比如，Selects per second 和Innodb reads per second的区别是什么？如何评估服务器当前写入的性能？

下图展示了一个运行中的服务器性能状态：