Mongo Read hangs up indefinitely when readPreference is secondary

We have a backend API app in Google Cloud using all the Kubernetes goodness. For some reason, we don’t use a Google Cloud backed MongoDB service. Instead, we spin our own MongoDB replicaSet using one of the stable helm charts mongodb-replicaset.

Tech Stack

  • NestJS framework for the backend service – latest as of writing
  • Mongoose library for MongoDB connectivity – latest as of writing
  • MongoDB 3.6 replicaSet hosted in GCP with mongodb-replicaset helm chart

Here is the DATABASE_URL for reference:

DATABASE_URL: mongodb://jx-service-mongodb-ha:27017/dbname?replicaSet=rs0&readPreference=secondary&maxStalenessSeconds=120

The helm chart for the MongoDB replicaSet just do the magic where it exposes one service name and under the hood, there are 3 replicas with 1 primary and 2 secondaries. The setup is pretty straightforward.

MongoDB Read

The problem occurs when we do a simple read like findOne or findById using the Mongoose models. No errors are being thrown and the read process didn’t proceed to the next line of code as if it is stuck indefinitely.

We didn’t really find any solution for now so the temporary fix is to remove the read preference.

DATABASE_URL: mongodb://jx-service-mongodb-ha:27017/dbname?replicaSet=rs0

I’m hoping to find some alternative helm chart or better yet, fix the real issue and still enjoy the awesome helm charts that give us stable deployments.

This entry was posted in kubernetes, MongoDB. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *