Error 603000: Connection Failed During Migration from AWS RDS to Azure PostgreSQL

Question

Error 603000: Connection Failed During Migration from AWS RDS to Azure PostgreSQL

Blackbucks Education 0

I'm in the process of migrating my PostgreSQL database from AWS RDS to Azure PostgreSQL, but I'm encountering a connectivity error. The validation process fails with the following details:

AuthenticationAndConnectivityValidation

Validation status: Failed

Start time: 2025-04-07 06:35:08 UTC

End time: 2025-04-07 06:35:09 UTC

Validation details: Error 603000: Connection failed. Connection to the server 'myservername-region.rds.amazonaws.com' was unsuccessful. Ensure that source server is reachable from the target or runtime server.

When testing connection it shows successful but when validation it shows this issue. User's image

Screenshot from 2025-04-07 13-20-48

Mallaiah Sangi 1,145 Reputation points Microsoft External Staff Moderator

2025-04-07T13:57:52.86+00:00
Hi @Blackbucks Education

Greetings!

As I understand, while migrating from AWS to Azure PostgreSQL Flexible Server you are getting connection issue.

1. Migration Target connection Error:

the error Number "Error 603000" indicates that PostgreSQL has exhausted the shared memory allocated for locks. It typically occurs when the migration process involves many locks beyond the current setting of the max_locks_per_transaction parameter.

Resolution:

Increase the value of the max_locks_per_transaction parameter to accommodate the another locks required during the migration process.

Example command to modify this setting: ALTER SYSTEM SET max_locks_per_transaction = <<>>;

Ensure that, max_locks_per_transaction * max_connections > Number of tables + Number of indexes

If the issue persists, consider increasing the shared_buffers parameter to ensure sufficient shared memory is available for lock management.

2. Connection issue from AWS to Azure PostgreSQL Flexible Server:

The steps below may be helpful for your issue:

If you have an internet connection with dynamic IP addressing and you're having trouble getting through the firewall, try one of the following solutions:

Ask your internet service provider (ISP) for the IP address range assigned to your client computers that access the Azure Database for PostgreSQL server. Then add the IP address range as a firewall rule.

Get static IP addressing instead for your client computers, and then add the static IP address as a firewall rule.

In Delegated subnet. A virtual network contains subnets (sub-networks). Subnets enable you to segment your virtual network into smaller address spaces. Azure resources are deployed into specific subnets within a virtual network.

Your flexible server must be in a subnet that's delegated. That is, only Azure Database for PostgreSQL - Flexible Server instances can use that subnet. No other Azure resource types can be in the delegated subnet. You delegate a subnet by assigning its delegation property as Microsoft.DBforPostgreSQL/flexibleServers. The smallest CIDR range you can specify for the subnet is /28, which provides sixteen IP addresses, however the first and last address in any network or subnet can't be assigned to any individual host. Azure reserves five IPs to be utilized internally by Azure networking, which include two IPs that cannot be assigned to host, mentioned above. This leaves you eleven available IP addresses for /28 CIDR range, whereas a single Flexible Server with High Availability features utilizes 4 addresses.

I hope, this response will address your query and helped you to overcome on your challenges.

Please reach out to me if you need any assistance
Mallaiah Sangi 1,145 Reputation points Microsoft External Staff Moderator

2025-04-08T09:38:52.75+00:00

Hi @Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Blackbucks Education 0 Reputation points

2025-04-09T06:14:35.3866667+00:00
Hi @Mallaiah Sangi

Thanks for your detailed response.

We have tried increasing the max_locks_per_transaction from 64 to 128 (even though it's already higher than Number of tables + Number of indexes as you've mentioned). And we got the same error.

Also, we have allowed all IP address (0.0.0.0-255.255.255.255) in both source (AWS RDS Postgres DB) and target (Azure Flexible Server for Postgres). So, dynamic IP's might not be the issue.

These are the things we tried but still didn't resolve the issue:

We tried pinging the Server URL of the source and target and it's connecting successfully.

The Source DB is publicly accessible.

In Target DB (Azure Flexible Server for PostgreSQL), we have allowed all IP addresses in Firewall.

In Source (AWS RDS), we have set the server parameter rds.logical_replication to 1.

Both Source and Target is of same PostgreSQL version - 13.

The User (of source DB) we are using for migration has full-access to the DB. So, there's no way for authentication issue.

I hope I have provided all the details you may need. If not so, we are ready to provide more details.

Can you look into these and provide any more suggestions to resolve this issue.
Narendra Pakkirigari 475 Reputation points Microsoft External Staff Moderator

2025-04-16T07:03:32.26+00:00

Hi Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Narendra Pakkirigari 475 Reputation points Microsoft External Staff Moderator

2025-04-17T08:43:01.9433333+00:00

Hi Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

1 answer

Your answer

Mallaiah Sangi 1,145 Reputation points Microsoft External Staff Moderator

2025-04-08T09:38:52.75+00:00

Hi @Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Blackbucks Education 0 Reputation points

2025-04-09T06:14:35.3866667+00:00

Hi @Mallaiah Sangi

Thanks for your detailed response.

We have tried increasing the max_locks_per_transaction from 64 to 128 (even though it's already higher than Number of tables + Number of indexes as you've mentioned). And we got the same error.

Also, we have allowed all IP address (0.0.0.0-255.255.255.255) in both source (AWS RDS Postgres DB) and target (Azure Flexible Server for Postgres). So, dynamic IP's might not be the issue.

These are the things we tried but still didn't resolve the issue:

We tried pinging the Server URL of the source and target and it's connecting successfully.

The Source DB is publicly accessible.

In Target DB (Azure Flexible Server for PostgreSQL), we have allowed all IP addresses in Firewall.

In Source (AWS RDS), we have set the server parameter rds.logical_replication to 1.

Both Source and Target is of same PostgreSQL version - 13.

The User (of source DB) we are using for migration has full-access to the DB. So, there's no way for authentication issue.

I hope I have provided all the details you may need. If not so, we are ready to provide more details.

Can you look into these and provide any more suggestions to resolve this issue.
Narendra Pakkirigari 475 Reputation points Microsoft External Staff Moderator

2025-04-16T07:03:32.26+00:00

Hi Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Narendra Pakkirigari 475 Reputation points Microsoft External Staff Moderator

2025-04-17T08:43:01.9433333+00:00

Hi Blackbucks Education

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Answer 1

Hi@Blackbucks Education

Thanks For the Response:

Public Access

Make PostgreSQL instance publicly accessible in AWS/GCP console.

Add inbound rule to allow traffic from Azure Database for PostgreSQL's IP/domain (port 5432).

Private Access

Use private link (ExpressRoute, VPN, Direct Connect, etc.) between source cloud and Azure.

In AWS/GCP, allow inbound traffic from Azure VNet IP range on port 5432.

In Azure:

Create VNet in same region as Azure DB.

Allow outbound to source PostgreSQL IP (port 5432).

Allow inbound from source cloud to Azure DB IP range.

Request to refer the below documents:

https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/troubleshoot-error-codes?utm_source=chatgpt.com#migration-error-codes

https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/how-to-network-setup-migration-service#managed-postgresql-service-public-ip-to-flexible-server-publicprivate-access

Share via

Error 603000: Connection Failed During Migration from AWS RDS to Azure PostgreSQL

1 answer

Your answer