Skip to content

Draft: Mongo ReplicaSet instance support #244

Draft
shivaprasadmb wants to merge 1 commit into
mainfrom
ERA-66338
Draft

Draft: Mongo ReplicaSet instance support #244
shivaprasadmb wants to merge 1 commit into
mainfrom
ERA-66338

Conversation

@shivaprasadmb

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:
This PR is for adding support for Mongo HA (ReplicaSet type) via NDB Operator.

How Has This Been Tested?:

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration and test output

Special notes for your reviewer:
Mongo ReplicaSet instance contains of primary, secondary nodes and optional arbiter node. Primary node would receive write/read traffic and secondary nodes would be used for read only traffic. There is asynchronous replication happening from primary to secondary nodes. Arbiter node is optional as it doesn't hold any actual data but its helps in leader election incase primary node goes down. Use arbiter node for smaller workloads (to save infra costs) and not for production workload.

  • Mongo driver is used in application code to connect to its DBs, this driver contains SDAM (service discovery and monitoring) which monitors health of nodes in the cluster and helps in traffic routing and automation failover scenario.
  • Since SDAM handles which requests should go to primary and secondary nodes, we don't need to create separate read and write endpoints. We will have a single connection URI string used in application code.
  • Users would require a ready-to-use connection string when DB is provisioned, they don't need to make much changes in code to use this string. This should be stored securely and be accessible to code.
  • NDB-Operator can generate connection URI string which consists of user, password, node IPs and replicaSet name. This would be stored in K8s secret object and become accessible to users.
  • SDAM component uses hostnames to resolve and route traffic, since we need to resolve the hostnames we need to create headless service for each node so that it becomes a raw DNS record in coreDNS.
  • we create headless service instead of normal service object because when normal service object is used then it gets a clusterIP which is different from actual node IPs. kube-rbac-proxy intercepts the traffic to resolve service name to actual IPs which messes the flow, hence headless service would be used.

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant