Database Migration Failed during CDC

[gunturjaya]

looking any help

Migration job status changed from RUNNING, CDC in progress to FAILED, during CDC.

Failure due to the following error:

 error code: 13,

 error message: An internal error occurred. Contact support. Dapper trace id: -2676606707425661476

looking for any help. thank you

[ms4446]

The error message you provided is quite generic and it doesn't provide specific details about the problem. 

Here are some general steps you can take to troubleshoot:

1. Check the configuration: Make sure that all your configuration settings are correct. This includes the source and target databases, connection details, migration type, etc.

2. Logs and error details: Look for any additional error details in the logs of your migration job. This might give you more insight into what went wrong.

3. Retry the operation: Sometimes, retrying the operation might resolve the issue if it was caused by a temporary glitch in the system.

[gunturjaya]

whether in the CDC process requires CPU to process? cause i did the migration process when the cpu from the source database was 98-99%

[ms4446]

High CPU usage on the source database during migration can definitely be a factor that causes migration to fail. Here are a few reasons why this could be an issue:

1. Performance Impact: High CPU utilization can impact the performance of the database, slowing down the migration process. If the CPU is maxed out, it may not be able to handle the additional load caused by the migration process, leading to a failure.

2. Connection Issues: High CPU usage can lead to intermittent connectivity issues. The migration service requires a stable connection to the source database to function correctly. Any disruptions in this connection can cause the migration to fail.

3. Timeouts: Database operations that take too long due to high CPU usage can cause timeouts, which can lead to migration failure.

To avoid these issues, it's generally recommended to ensure that the source database has enough resources to handle both its regular workload and the additional load caused by the migration process. You might need to optimize your database or upgrade your database server to a more powerful instance.

In your case, it seems like the source database was under high load during the migration. You may want to consider reducing the load on the database during migration or increasing the resources available to the database.

[gunturjaya]

i tried to check all the log, there is some error like SELECT Aurora_Version() and some schema doesnt created automatically on destination database. how to recover?

[ms4446]

The SELECT Aurora_Version() function is specific to Amazon Aurora not recognized by Cloud SQL. 

As for the schemas not being created automatically on the destination database, this could be due to a variety of reasons. It might be a permissions issue, or it could be that the schema creation statements are not included in the migration process.

Here are a few steps you could take to resolve these issues:

1. Modify the Database Scripts: If possible, modify the database scripts to remove or replace any functions or queries that are not supported by the destination database. In this case, you might need to find an alternative to the SELECT Aurora_Version() function.

2. Create the Schemas Manually: If the schemas are not being created automatically, you could try creating them manually on the destination database before starting the migration.

3. Check the Permissions: Make sure that the account used for the migration has the necessary permissions to create schemas on the destination database.

[gunturjaya]

hi @ms4446,

thank you for the replying, right now after observed the error log from destination instance i got the error message like this : 
finished setup replication with errors: [seen]: error restoring predata: failed to restore schema: stderr=pg_restore: while PROCESSING TOC: pg_restore: from TOC entry 240; 1259 22588 TABLE alert cloudsqlsuperuser pg_restore: error: could not execute query: ERROR: schema "data" does not exist LINE 1:
and some schema is still doesnt create automatically. when i try to create schema manually then restart the migration job, the error getting back and the schema that i create manually before is disappeared? getting confused of this error

[ms4446]

The error message you're seeing indicates that the pg_restore command is trying to restore a table (alert) into a schema (data) that does not exist in the destination database. This is likely why the migration is failing.

As for the schemas disappearing when you restart the migration job, it's possible that the migration process is dropping and recreating the database or schemas as part of its operation. This would explain why the schemas you created manually are disappearing.

Here are a few potential solutions:

1. Include Schema Creation in the Migration: Ensure that the migration job includes commands to create the necessary schemas before it tries to restore the tables. This might involve modifying the migration scripts or settings.

2. Pre-create All Necessary Schemas: If possible, create all the necessary schemas in the destination database before starting the migration job. This might prevent the pg_restore command from failing.

3. Modify the Migration Job Settings: Check the settings of the migration job to see if there's an option to not drop and recreate the database or schemas. This might prevent the schemas you created manually from being dropped.