Replica Access Methods

After the MongoDB replica sets are deployed over the slice across multiple clusters, there are different deployment models that can be used to access the replicas.

Access Replicas from within the Clusters

In this deployment model, services deployed in different namespaces within the same slice can access any replica sets to read from and write to the primary replica set.

Step 1: Create the mongo-sh Namespace on the Master Cluster

1. On the master cluster, create the mongo-sh namespace using the following command:

   kubectl create ns mongo-sh

2. Onboard the namespace to the slice by applying the MongoDB slice configuration using the following command:

   kubectl apply -f examples/distributed-mongodb/mongodb-slice/mongodb-slice-lb-mongo-sh.yaml

Step 2: Deploy a MongoDB Shell Pod in the mongo-sh Namespace

Create and deploy a mongodb-sh pod in the mongo-sh namespace with the following configuration:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: mongodb-sh
  namespace: mongo-sh
spec:
  containers:
    - name: mongodb-shell
      image: mongo:4.4.6 # You can adjust the version as needed
      command: ["sleep"]
      args: ["3600"]
      stdin: true
      tty: true
EOF

Step 3: Connect to the MongoDB Multi-Replica Set from the MongoDB Shell Pod

1. Execute into the mongodb-sh container using the following command:

   kubectl exec -it mongodb-sh -c mongodb-shell -n mongo-sh -- sh

2. Inside the shell, connect to your MongoDB multi-replica set using the following command:

   mongo mongodb://multi-replica-set-0-0.mongodb.svc.slice.local:27017,multi-replica-set-1-0.mongodb.svc.slice.local:27017,multi-replica-set-2-0.mongodb.svc.slice.local:27017

   Example Output:

   MongoDB shell version v4.4.6
   connecting to: mongodb://multi-replica-set-0-0.mongodb.svc.slice.local:27017,multi-replica-set-1-0.mongodb.svc.slice.local:27017,multi-replica-set-2-0.mongodb.svc.slice.local:27017/?compressors=disabled&gssapiServiceName=mongodb
   Implicit session: session { "id": UUID("5265d73a-ecde-4608-8fb6-713dd35203ff") }
   MongoDB server version: 6.0.2
   WARNING: shell and server versions do not match
   Welcome to the MongoDB shell.
   For interactive help, type "help".
   For more comprehensive documentation, see
   	https://docs.mongodb.com/
   Questions? Try the MongoDB Developer Community Forums
   	https://community.mongodb.com
   ---
   The server generated these startup warnings when booting: 
           2024-10-16T13:55:22.237+00:00: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem
           2024-10-16T13:55:23.025+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
           2024-10-16T13:55:23.025+00:00: vm.max_map_count is too low
           2024-10-16T13:55:23.025+00:00:         currentValue: 524288
           2024-10-16T13:55:23.025+00:00:         recommendedMinimum: 1677720
           2024-10-16T13:55:23.025+00:00:         maxConns: 838860
   ---
   MongoDB Enterprise multi-replica-set:PRIMARY> 

Step 4: Perform Write Operations in the MongoDB Shell

After you are connected, you can perform write actions in the MongoDB shell and validate that the data is replicated across your MongoDB replica set deployment.

Disaster Recovery Failover

When the primary replica set fails over to a secondary replica set, the services can connect to the new primary and continue writing to it.

Access Replicas from Outside a Cluster

In this deployment model, MongoDB replicas are offered as a service to external clients. The replica sets, primary and secondary are accessed from clients through MongoDB service access points.

MongoDB replica set services are exposed through the Load Balancer service in each cluster with each replica set with its own FQDN. MongoDB clients can use the connection string to query the replica sets and determine the primary/secondary status. They can then connect to the primary for reads and writes for any of the replicas. With appropriate global DNS Load Balancer policies, the read requests can connect to low-latency or geolocation-based read-replica set endpoints.