Connect to MongoDB¶

Note

This connector is subject to the Snowflake Connector Terms.

This topic describes how to configure the source MongoDB database and the target Snowflake account for the Openflow Connector for MongoDB.

Set up the source MongoDB database¶

The connector requires a MongoDB deployment running as either a Replica Set or a Sharded Cluster. This architecture ensures high availability and enables the use of Change Streams, which the connector uses to track and sync data changes in real time.

To configure the MongoDB environment, perform the following steps:

Configure a basic Replica Set.

Ensure all nodes have the same replSetName in their mongod.conf as shown in the following example:
```
replication:
  replSetName: "myReplicaSet"
```

Initialize the replica set.

Run this command in the mongosh console. In this example, the replica set consists of two nodes:

rs.initiate({
  _id: "myReplicaSet",
  members: [
    {
      _id: 0,
      host: "10.11.98.246:27017",
    },
    {
      _id: 1,
      host: "10.11.104.58:27017",
    },
  ],
});

Create a dedicated database user.

The connector opens a cluster-level Change Stream, which requires the readAnyDatabase role on the admin database. Create the user with the following role by running the following command in the mongosh console:
```
use admin
db.createUser(
  {
 user: "openflowUser",
 pwd: "yourSecurePassword",
 roles: [
   {
     role: "readAnyDatabase",
     db: "admin"
   }
 ]
  }
);
```
Note
The readAnyDatabase role is required because the connector currently monitors change events at the cluster level. Database-scoped Change Stream support, which would allow a narrower read role on a specific database, is not currently supported.

When configuring the connector, set MongoDB Authentication Source to admin. For more information, see MongoDB source parameters.

Set up the target Snowflake account¶

As an Openflow administrator, perform the following tasks for this connector. With the default SNOWFLAKE_MANAGED authentication strategy, the runtime’s execute-as role is the identity the connector uses to access Snowflake, so you grant these privileges to that role.

Note

If you’re deploying the connector in Openflow - BYOC Deployments and using the KEY_PAIR authentication strategy instead of the recommended SNOWFLAKE_MANAGED, you’ll also grant this same execute-as role to a service user rather than relying on the runtime’s managed token. See Set up key-pair authentication for Openflow - BYOC Deployments to create the service user.

Create a database to store the replicated data, and grant the execute-as role USAGE and CREATE SCHEMA on it. The connector creates destination schemas automatically. Snowflake recommends a dedicated destination database per connector, to avoid collisions with other data sources including other connectors.

Keep this destination database separate from the database that holds your Openflow infrastructure objects, such as the runtime, the connector, and any secrets. A connector creates destination objects based on the source schema and table names, so those names aren’t under your control and can change as the source changes.
```
CREATE DATABASE IF NOT EXISTS <destination_database>;

GRANT USAGE ON DATABASE <destination_database> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
GRANT CREATE SCHEMA ON DATABASE <destination_database> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
```
Designate a warehouse for the connector to use, and grant the execute-as role USAGE and OPERATE on it. Start with the XSMALL warehouse size, then experiment with size depending on the number of tables being replicated, and the amount of data transferred. Large table numbers typically scale better with multi-cluster warehouses, rather than the warehouse size.
```
CREATE WAREHOUSE <ingest_warehouse>
  WITH
    WAREHOUSE_SIZE = 'XSMALL'
    AUTO_SUSPEND = 300
    AUTO_RESUME = TRUE;

GRANT USAGE, OPERATE ON WAREHOUSE <ingest_warehouse> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
```
Snowflake deployments only: Make sure this connector’s source host and port are permitted by a network rule that your runtime’s external access integration (EAI) allows.

The EAI itself belongs to the runtime, not to this connector. You create it once, attach it to the runtime, and grant the execute-as role USAGE on it. For those steps, see Creating network rules and external access integrations. What is specific to this connector is getting its source host into a rule that EAI references.

The rule takes the source’s host and port as a single value, such as db.example.com:<port>. That’s the host and port from the connector’s connection URL, without the jdbc: scheme, the driver name, or the database path.

BYOC deployments handle outbound connectivity in the cloud environment and don’t use EAIs or network rules.

Next steps¶

After setting up the source MongoDB database and the target Snowflake account, Set up the connector.