Function Compute functions that access databases can fail in two distinct patterns: failures that happen occasionally or failures that occur on every attempt. This guide walks you through the most common causes and how to resolve each one.
Intermittent connection failures
If database connections fail occasionally, work through the following checks in order.
1. Use `destroy()` instead of `end()` to close connections.
Function instances are recycled automatically after 2 to 5 minutes of inactivity. The end() method waits for the MySQL server to acknowledge a query result before closing the connection, which can leave the connection in an inconsistent state and cause the next invocation to time out. Call destroy() to force-close the connection immediately.
2. Replace your security group with an IP address whitelist if you access the database over a Virtual Private Cloud (VPC).
A security group on the database side can make connections unstable when accessed from Function Compute. Use an IP address whitelist instead to allow traffic reliably.
3. If failures continue, follow the steps in [Database connection constantly fails](#database-connection-constantly-fails).
Database connection constantly fails
If every connection attempt fails, work through the following steps in order.
Check connection records in the database for the time window when failures occurred.
No connection requests from Function Compute found → go to step 2.
Connection requests from Function Compute are present → go to step 4.
Verify the username and password.
Credentials are correct → go to step 3.
Credentials are wrong → correct them and retry.
Test network connectivity with telnet from a Function Compute instance. Run the following command, replacing
<DB_HOST>and<DB_PORT>with your database endpoint and port:Connection succeeds → go to step 4.
Connection fails → follow the steps in Troubleshoot network issues.
telnet <DB_HOST> <DB_PORT>Review your function code logic for connection-handling bugs.
If the issue persists after completing all steps, join the DingTalk user group 11721331 for technical support.
Troubleshoot network issues
VPC access
Confirm the database instance and the function are in the same region.
If you see an
AccessDeniederror (error code 403), check whether your function has the required permissions on the elastic network interface (ENI).If you see an
InvalidArgumenterror (error code 400), verify that the VPC, vSwitch, and Security Group configurations are valid.If you configured an IP address whitelist on the database, include both the VPC private CIDR block and the vSwitch CIDR block. To allow traffic from all IP addresses, add
0.0.0.0/0.Confirm that the security group allows outbound traffic on the database's private IP address and port.
If you see a
ResourceExhaustederror (error code 429), the vSwitch has run out of available IP addresses. The default CIDR block has a prefix length of/24, which provides 252 usable addresses. If your function scales beyond this limit, manually expand the vSwitch CIDR block and update the security group accordingly.
Internet access
Enable Internet access for your service. For details, see Configure network settings.
If the database uses a static IP address whitelist, configure a static public IP address for your function. Function Compute allocates IP addresses dynamically, so without a static IP address your function cannot pass the whitelist check. For details, see Configure static public IP addresses.
Database-side network issues
To isolate whether the problem is on the database side, set up a similar network environment in another service and run a telnet test:
telnet <DB_HOST> <DB_PORT>If the connection succeeds, the network on the database side is normal.