关于使用DMS实现异构本地（on-prem db）与云数据库持续复制的技术咨询

Great question—let’s tackle your three core concerns about using Database Migration Service (DMS) for continuous replication between your on-premises heterogeneous database and cloud analytics database, especially since you need to keep your business applications running without downtime:

1. Can DMS enable ongoing replication between on-prem and cloud heterogeneous databases? #

Absolutely. DMS is built specifically to handle heterogeneous database replication (across different database engines) for both one-time migrations and continuous, ongoing syncs. It supports a wide range of on-premises sources (like Oracle, MySQL, SQL Server, PostgreSQL) and cloud targets (like cloud-native databases, data warehouses such as Redshift or Snowflake, and analytics platforms).

The key here is its Change Data Capture (CDC) capability: after completing the initial full data load, DMS will automatically capture incremental changes (inserts, updates, deletes) from your on-prem database’s transaction logs (e.g., MySQL binlogs, Oracle redo logs) and replicate them to the cloud target in an ongoing fashion. No manual re-runs or full data refreshes are needed once the setup is complete.

2. Does the replication offer near-real-time performance? #

Yes, DMS can achieve near-real-time replication with latency typically ranging from a few seconds to a couple of minutes—depending on your configuration and environment.

CDC-based replication works by tailing your source database’s transaction logs as they’re generated, so changes are picked up almost immediately. Factors that can tweak latency include:

• Network bandwidth between your on-prem environment and the cloud
• Volume of concurrent changes in the source database
• Configuration settings like log polling frequency or batch size for replication

For most analytics use cases, this level of latency is more than sufficient to keep your cloud database fresh for timely analysis.

3. Will replication impact the performance of my on-prem database (which is accessed by other business apps)? #

The performance impact on your source on-prem database is minimal, especially when using CDC mode—and you absolutely don’t need to shut down your applications during replication.

Here’s why:

• CDC reads directly from the source database’s transaction logs, not by querying or locking production tables. This means it doesn’t compete with your business applications for critical database resources like CPU, memory, or I/O.
• You can further mitigate any potential minor impact by:
  • Using a read replica of your on-prem database as the replication source (if available) instead of the primary production instance
  • Configuring DMS to limit the number of concurrent replication tasks or adjust log polling intervals to avoid overwhelming the source
  • Filtering only the tables/columns you need for analytics, reducing the overall data volume being replicated

In most production scenarios, the performance hit is negligible and won’t affect your application’s end-users.

内容的提问来源于stack exchange，提问作者Punter Vicky