AWS DMS Task Failed with No Errors when we try to migrate data from a source engine to a target engine.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how to troubleshoot this issue?

AWS DMS Task Failed with No Errors

When an AWS DMS task fails, the task logs provide information about the cause of the failure with either error messages (]E:) or warning messages, (]W:).

In some cases, the task can fail without any errors or warnings.

Most often, the cause can be either of the following reasons:

1. Resource contention on the replication instance
2. Storage Full status on the replication instance
3. An internal error occurred

Resolution

Moving ahead, let us see how our Support Techs go about this query.

Initially, we check the time of the last entry in the task logs after the task failed silently.

Then, we verify the CPU, memory, and disk utilization on the replication instance around the same time of the failure.

Suppose we see a combination of the low FreeableMemory and high SwapUsage.

Then there might be memory contention on the replication instance.

Our Support Techs suggests these steps to view the CloudWatch metrics:

1. Open the AWS DMS console > Database migration tasks.
2. Here, we select the name of the failed task.
3. We note the name of the Replication instance from the Overview details section.
4. Then we select Replication instances from the navigation pane.
5. Select the name of the replication instance noted in step 3.
6. In the Migration task metrics section, we can view the CPUUtilization, SwapUsage, FreeableMemory, and FreeStorageSpace metrics.
7. For more details, we go over the metric > more options icon.
8. Finally, we select View in metrics.

This will open the CloudWatch console. In it, we can view the metric’s utilization at the time that the task failed.

Generally, if we see constant CPU or memory contention, we reduce the number of tasks running on the replication instance.

To do so, we launch new replication instances and distribute the tasks across multiple replication instances.

Or, we scale up the replication instance to a larger instance type.

Once we identify the source of the silent failure, we restart the task.

However, if there isn’t contention on CPU, memory, or disk space, then most likely it is an internal error.

To troubleshoot internal errors, we have to enable detailed debugging on all five log components.

Once done, we restart the task and review the task logs to identify why the task failed.

[Still, stuck with the error? We are available 24*7]

Conclusion

In short, we saw how our Support Techs fix and troubleshoot task failure in AWS DMS.