Installation
Supported Deployment Models
The following table describes Relational Migrator's supported deployment models and example use cases for each deployment model:
Deployment Model | Use Cases |
|---|---|
| |
| |
| |
|
Local Desktop
You can install Relational Migrator to a single machine that cannot be externally accessed. Local installations are suitable for development, evaluation, and small production jobs that are expected to run for less than one day.
Note
If you must perform a large migration, you can split the migration into multiple jobs using table filters.
For more information, see Development Installation.
Unattended Server/VM
You can install Relational Migrator on an unattended server or VM that binds Relational Migrator to an IP address and port, exposing it as a web application. Installing Relational Migrator on an unattended server is suitable for the majority of use cases, including tests and production migrations.
Note
Installing Relational Migrator on an unattended server is not a highly-available solution. If an application issue occurs, users must manually intervene.
For more information, see Production Installation.
Kafka Cluster
Apache Kafka is an open-source platform for distributed workloads. If you use Relational Migrator for critical production workloads or long-running CDC syncs, MongoDB recommends using Kafka. Using Relational Migrator as a Kafka Connect plugin can enable high availability and automatic failure recovery, provided that the underlying cluster configuration supports these features.
For more information, see Kafka Deployments.
Kafka on Confluent Cloud
Confluent is an official MongoDB partner providing a fully-managed cloud-based Kafka solution. This deployment method is intended for users who want the reliability of Kafka without having to manage their own cluster.
For more information, see Confluent Cloud Setup Guide.
Deployment Considerations
Where to Run Relational Migrator
For best performance, locate the machine or server running Relational Migrator as geographically close to the source and target databases as possible. Proximity to the target database influences performance the most:
If you're using Relational Migrator for an on-premises migration, run Relational Migrator in the same data center as the source database.
If you're using a cloud hosted database, run Relational Migrator on an EC2 instance or VM in the same VPC as the source database.
Tip
Check the sleep timeout setting for your operating system. If your machine goes to sleep during a migration, the migration job fails.
Network Considerations
When using Relational Migrator, the system firewall on the machine or server must allow outbound TCP traffic to both the source and destination databases.
Cloud Networking
When running Relational Migrator in a cloud environment, check the cloud specific firewall (security group), router table, and the server firewall configurations. For details on specific cloud provider network configurations, see these pages:
Telemetry
By default, Relational Migrator includes telemetry that reports usage information and errors back to MongoDB to help improve the product. This telemetry does not include any sensitive details such as database connection strings, schema information or customer data.
You can disable telemetry by editing the application's
user.properties file, adding the following line, and restarting
Relational Migrator:
migrator.app.telemetry.enable: false
For information about the user.properties file location, see Relational Migrator File Locations.
System Hardware
For specific hardware recommendations, see System Requirements.
Note
Scaling up the Atlas cluster size can significantly improve migration speeds. For details, see Modify the Cluster Tier.
Get Started
For local and Docker deployment installation instructions, see Development Installation
For unattended server and Kafka deployment installation instructions, see Production Installation