There was a problem using percona-server-mongodb-operator:1.11.0. Specifically, the problem is with the operationProfiling parameter. Here is an example for configuring a mongoDB instance:
--- apiVersion: psmdb.percona.com/v1-12-0 kind: PerconaServerMongoDB metadata: name: test-mongo spec: crVersion: 1.11.0 image: percona/percona-server-mongodb:4.4.12 allowUnsafeConfigurations: true updateStrategy: SmartUpdate upgradeOptions: apply: Never secrets: users: user-secrets pmm: enabled: false replsets: - name: rs0 size: 1 expose: enabled: false volumeSpec: persistentVolumeClaim: storageClassName: test resources: requests: storage: 1Gi resources: limits: memory: 1Gi requests: cpu: 50m memory: 1Gi arbiter: enabled: false sharding: enabled: false
In this case, an instance will be deployed in mongodb which will have the following command to start the mongodb process:
mongod --bind_ip_all --auth --dbpath=/data/db --port=27017 --replSet=rs0 --storageEngine=wiredTiger --relaxPermChecks --clusterAuthMode=keyFile --keyFile=/etc/mongodb-secrets/mongodb-key --slowms=0 --profile=1 --enableEncryption --encryptionKeyFile=/etc/mongodb-encryption/encryption-key --wiredTigerCacheSizeGB=0.25 --wiredTigerIndexPrefixCompression=true --config=/etc/mongodb-config/mongod.conf --tlsAllowInvalidCertificates
In a similar configuration, the monga will start with two parameters –slowms=0 --profile=1.
What does logging of all operations mean and how in our case it led to a huge number of logs.
According to your documentation, I can do similar configuration for two parameters such as operationProfiling and systemLog like this:
configuration: | operationProfiling: mode: off systemLog: verbosity: 0
But this did not work because these two parameters were still in the launch command, although my parameters were written to the config.
The problem with a large number of logs due to the included operationProfiling needed to be solved. In the end, I came to such a decision and substituted the following construction in the spec:
mongod: operationProfiling: enabled: false
This design helped me to avoid running mongoDB with the –slowms=0 and –profile=1 parameters.
mongod --bind_ip_all --auth --dbpath=/data/db --port=27017 --replSet=rs0 --storageEngine=wiredTiger --relaxPermChecks --clusterAuthMode=keyFile --keyFile=/etc/mongodb-secrets/mongodb-key --enableEncryption --encryptionKeyFile=/etc/mongodb-encryption/encryption-key --wiredTigerCacheSizeGB=0.25 --wiredTigerIndexPrefixCompression=true --tlsAllowInvalidCertificates
I had to come up with this solution to the problem myself, since there is nothing in the documentation for configuring the operationProfiling parameter. In my opinion, if we do not configure the current parameter at all, then we need to run mongoDB with mode: off for operationProfiling.
You have this part of the code where parameters are added to start the mongoDB process, for some reason the current scheme does not take into account at all, for example, mode: off is needed.
Or it looks like a bug, because if the operationProfiling parameter is empty, then it should not add two parameters –slowms=0 and –profile=1 to the launch.