This page describes how to connect to your Cloud SQL instance using the Cloud SQL Auth Proxy.
For more information about how the Cloud SQL Auth Proxy works, see About the Cloud SQL Auth Proxy.
Overview
Using the Cloud SQL Auth Proxy is the recommended method for connecting to a Cloud SQL instance. The Cloud SQL Auth Proxy:
- Works with both public and private IP endpoints
- Validates connections using credentials for a user or service account
- Wraps the connection in a SSL/TLS layer that's authorized for a Cloud SQL instance
Some Google Cloud services and applications use the Cloud SQL Auth Proxy to provide connections for public IP paths with encryption and authorization, including:
Applications running in Google Kubernetes Engine can connect using the Cloud SQL Auth Proxy.
See the Quickstart for using the Cloud SQL Auth Proxy for a basic introduction to its usage.
You can also connect, with or without the Cloud SQL Auth Proxy, using a mysql client from a local machine or Compute Engine.
Before you begin
Before you can connect to a Cloud SQL instance, do the following:
-
- For a user or service account, make sure the account has the
Cloud SQL Client role. This role contains the
cloudsql.instances.connect
permission, which authorizes a principal to connect to all Cloud SQL instances in a project. - You can optionally include an IAM condition in the IAM policy binding that grants the account permission to connect only to one specific Cloud SQL instance.
- For a user or service account, make sure the account has the
Cloud SQL Client role. This role contains the
-
Enable the Cloud SQL Admin API.
- Install and initialize the gcloud CLI.
- Optional. Install the Cloud SQL Auth Proxy Docker client.
Download the Cloud SQL Auth Proxy
Linux 64-bit
- Download the Cloud SQL Auth Proxy:
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.linux.amd64
- Make the Cloud SQL Auth Proxy executable:
chmod +x cloud-sql-proxy
Linux 32-bit
- Download the Cloud SQL Auth Proxy:
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.linux.386
- If the
curl
command is not found, runsudo apt install curl
and repeat the download command. - Make the Cloud SQL Auth Proxy executable:
chmod +x cloud-sql-proxy
macOS 64-bit
- Download the Cloud SQL Auth Proxy:
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.darwin.amd64
- Make the Cloud SQL Auth Proxy executable:
chmod +x cloud-sql-proxy
Mac M1
- Download the Cloud SQL Auth Proxy:
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.darwin.arm64
- Make the Cloud SQL Auth Proxy executable:
chmod +x cloud-sql-proxy
Windows 64-bit
Right-click https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.x64.exe and select Save Link As to download the Cloud SQL Auth Proxy. Rename the file tocloud-sql-proxy.exe
.
Windows 32-bit
Right-click https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.14.0/cloud-sql-proxy.x86.exe and select Save Link As to download the Cloud SQL Auth Proxy. Rename the file tocloud-sql-proxy.exe
.
Cloud SQL Auth Proxy Docker image
The Cloud SQL Auth Proxy has different container images, such as distroless
, alpine
,
and buster
. The default Cloud SQL Auth Proxy container image uses
distroless
, which
contains no shell. If you need a shell or related tools, then download an image based on
alpine
or buster
.
For more information, see
Cloud SQL Auth Proxy Container Images.
You can pull the latest image to your local machine using Docker by using the following command:
docker pull gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0
Other OS
For other operating systems not included here, you can compile the Cloud SQL Auth Proxy from source.Start the Cloud SQL Auth Proxy
Depending on your language and environment, you can start the Cloud SQL Auth Proxy using TCP sockets, Unix sockets, or the Cloud SQL Auth Proxy Docker image. The Cloud SQL Auth Proxy binary connects to one or more Cloud SQL instances specified on the command line, and opens a local connection as either TCP or a Unix socket. Other applications and services, such as your application code or database management client tools, can connect to Cloud SQL instances through those TCP or Unix socket connections.
TCP sockets
For TCP connections, the Cloud SQL Auth Proxy listens on localhost
(127.0.0.1
) by default.
So, when you specify --port PORT_NUMBER
for an instance, the local connection
is at 127.0.0.1:PORT_NUMBER
.
Alternatively, you can specify a different address for the local connection.
For example, here's how to make the Cloud SQL Auth Proxy listen at 0.0.0.0:1234
for the
local connection:
./cloud-sql-proxy --address 0.0.0.0 --port 1234 INSTANCE_CONNECTION_NAME
Copy your INSTANCE_CONNECTION_NAME. This can be found on the Overview page for your instance in the Google Cloud console or by running the following command:
gcloud sql instances describe INSTANCE_NAME --format='value(connectionName)'
For example: myproject:myregion:myinstance.
- If the instance has both public and private IP configured, and you want the
Cloud SQL Auth Proxy to use the private IP address,
you must provide the following option when you start the Cloud SQL Auth Proxy:
--private-ip
- If you are using a service account to authenticate the Cloud SQL Auth Proxy, note the location on your client machine of the private key file that was created when you created the service account.
- Start the Cloud SQL Auth Proxy.
Some possible Cloud SQL Auth Proxy invocation strings:
- Using Cloud SDK authentication:
The specified port must not already be in use, for example, by a local database server../cloud-sql-proxy --port 3306 INSTANCE_CONNECTION_NAME
- Using a service account and explicitly including the name of the instance connection
(recommended for production environments):
./cloud-sql-proxy \ --credentials-file PATH_TO_KEY_FILE INSTANCE_CONNECTION_NAME &
For more information about Cloud SQL Auth Proxy options, see Options for authenticating the Cloud SQL Auth Proxy.
- Using Cloud SDK authentication:
Unix sockets
The Cloud SQL Auth Proxy can listen on a Unix socket, which is a Posix standard mechanism for using a folder to manage communication between two processes running on the same host. Advantages to using Unix sockets are improved security and lower latency, however, you cannot access a Unix socket from an external machine.
To create and use a Unix socket, the target directory must exist and both the Cloud SQL Auth Proxy and application must have read and write access to it.
Copy your INSTANCE_CONNECTION_NAME. This can be found on the Overview page for your instance in the Google Cloud console or by running the following command:
gcloud sql instances describe INSTANCE_NAME --format='value(connectionName)'
For example: myproject:myregion:myinstance.
- Create the directory where the Cloud SQL Auth Proxy sockets will live:
sudo mkdir /cloudsql; sudo chmod 777 /cloudsql
- If you are using a service account to authenticate the Cloud SQL Auth Proxy, note the location on your client machine of the private key file that was created when you created the service account.
- Open a new Cloud Shell terminal window and start the Cloud SQL Auth Proxy.
Some possible Cloud SQL Auth Proxy invocation strings:
- Using Google Cloud SDK authentication:
./cloud-sql-proxy --unix-socket /cloudsql INSTANCE_CONNECTION_NAME &
- Using a service account:
./cloud-sql-proxy --unix-socket /cloudsql --credentials-file PATH_TO_KEY_FILE INSTANCE_CONNECTION_NAME &
Start the Cloud SQL Auth Proxy in its own Cloud Shell terminal so you can monitor its output without it mixing with the output from other programs.
For more information about Cloud SQL Auth Proxy options, see Options for authenticating the Cloud SQL Auth Proxy.
- Using Google Cloud SDK authentication:
Docker
To run the Cloud SQL Auth Proxy in a Docker container, use the Cloud SQL Auth Proxy Docker image available from the Google Container Registry.
You can start the Cloud SQL Auth Proxy using either TCP sockets or Unix sockets, with the commands shown below. The options use an INSTANCE_CONNECTION_NAME as the connection string to identify a Cloud SQL instance. You can find the INSTANCE_CONNECTION_NAME on the Overview page for your instance in the Google Cloud console. or by running the following command:
gcloud sql instances describe INSTANCE_NAME
For example: myproject:myregion:myinstance
.
Depending on your language and environment, you can start the Cloud SQL Auth Proxy using either TCP sockets or Unix sockets. Unix sockets are not supported for applications written in the Java programming language or for the Windows environment.
Using TCP sockets
docker run -d \\ -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \\ -p 127.0.0.1:3306:3306 \\ gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0 \\ --address 0.0.0.0 --port 3306 \\ --credentials-file /path/to/service-account-key.json INSTANCE_CONNECTION_NAME
If you're using the credentials provided by your Compute Engine instance,
don't include the --credentials-file
parameter and the
-v PATH_TO_KEY_FILE:/path/to/service-account-key.json
line.
Always specify 127.0.0.1
prefix in -p so that the Cloud SQL Auth Proxy is not
exposed outside the local host. The "0.0.0.0" in the instances parameter
is required to make the port accessible from outside of the Docker
container.
Using Unix sockets
docker run -d -v /cloudsql:/cloudsql \\ -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \\ gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0 --unix-socket=/cloudsql \\ --credentials-file /path/to/service-account-key.json INSTANCE_CONNECTION_NAME
If you're using the credentials provided by your Compute Engine instance,
don't include the --credentials-file
parameter and the
-v PATH_TO_KEY_FILE:/path/to/service-account-key.json
line.
If you are using a container optimized image, use a writeable directory
in place of /cloudsql
, for example:
-v /mnt/stateful_partition/cloudsql:/cloudsql
You can specify more than one instance, separated by commas. You can also use Compute Engine metadata to dynamically determine the instances to connect to. Learn more about the Cloud SQL Auth Proxy parameters.
Connect with the mysql client
- Download the MySQL Community Server for your platform from the
MySQL Community Server download page.
The Community Server includes the MySQL client. - Install the Community Server, following the directions on the download page.
For more information about installing MySQL, see Installing and Upgrading MySQL.
The connection string you use depends on whether you started the Cloud SQL Auth Proxy using a TCP socket or a UNIX socket or Docker.
TCP sockets
- Start the mysql client:
If you're connecting to a MySQL 8.4 instance, then use the following command:mysql -u USERNAME -p --host 127.0.0.1
mysql -u USERNAME -p --host 127.0.0.1 --get-server-public-key
When you connect using TCP sockets, the Cloud SQL Auth Proxy is accessed through
127.0.0.1
. - If prompted, enter the password.
- The mysql prompt appears.
Using Unix sockets
- Start the mysql client:
mysql -u USERNAME -p -S /cloudsql/INSTANCE_CONNECTION_NAME
Note: You can't use the Cloud SQL Auth Proxy over a UNIX socket connection to a MySQL 8.4 instance.
- Enter the password.
- The mysql prompt appears.
Need help? For help troubleshooting the proxy, see Troubleshooting Cloud SQL Auth Proxy connections, or see our Cloud SQL Support page.
Connect with an application
You can connect to the Cloud SQL Auth Proxy from any language that enables you to connect to a Unix or TCP socket. Below are some code snippets from complete examples on GitHub to help you understand how they work together in your application.
Additional topics
Cloud SQL Auth Proxy command-line arguments
The examples above cover the most common use cases, but the Cloud SQL Auth Proxy
also has other configuration options that can be set with command-line
arguments. For help on command-line arguments, use the --help
flag
to view the latest documentation:
./cloud-sql-proxy --help
See the README on the Cloud SQL Auth Proxy GitHub repository for additional examples of how to use Cloud SQL Auth Proxy command-line options.
Options for authenticating the Cloud SQL Auth Proxy
All of these options use an INSTANCE_CONNECTION_NAME as the connection string to identify a Cloud SQL instance. You can find the INSTANCE_CONNECTION_NAME on the Overview page for your instance in the Google Cloud console. or by running the following command:
gcloud sql instances describe --project PROJECT_ID INSTANCE_CONNECTION_NAME
.
For example: gcloud sql instances describe --project myproject myinstance
.
Some of these options use a JSON credentials file that includes the RSA private key for the account. For instructions on creating a JSON credentials file for a service account, see Creating a service account.
The Cloud SQL Auth Proxy provides several alternatives for authentication, depending on your environment. The Cloud SQL Auth Proxy checks for each of the following items, in the following order, using the first one it finds to attempt to authenticate:
Credentials supplied by the credentials-file flag.
Use a service account to create and download the associated JSON file, and set the--credentials-file
flag to the path of the file when you start the Cloud SQL Auth Proxy. The service account must have the required permissions for the Cloud SQL instance.To use this option on the command-line, invoke the
cloud-sql-proxy
command with the--credentials-file
flag set to the path and filename of a JSON credential file. The path can be absolute, or relative to the current working directory. For example:./cloud-sql-proxy --credentials-file PATH_TO_KEY_FILE \ INSTANCE_CONNECTION_NAME
For detailed instructions about adding IAM roles to a service account, see Granting Roles to Service Accounts.
For more information about the roles Cloud SQL supports, see IAM roles for Cloud SQL.
Credentials supplied by an access token.
Create an access token and invoke thecloud-sql-proxy
command with the--token
flag set to an OAuth 2.0 access token. For example:./cloud-sql-proxy --token ACCESS_TOKEN \ INSTANCE_CONNECTION_NAME
Credentials supplied by an environment variable.
This option is similar to using the--credentials-file
flag, except you specify the JSON credential file you set in theGOOGLE_APPLICATION_CREDENTIALS
environment variable instead of using the--credentials-file
command-line argument.Credentials from an authenticated gcloud CLI client.
If you have installed the gcloud CLI and have authenticated with your personal account, the Cloud SQL Auth Proxy can use the same account credentials. This method is especially helpful for getting a development environment up and running.
To enable the Cloud SQL Auth Proxy to use your gcloud CLI credentials, use the following command to authenticate the gcloud CLI:
gcloud auth application-default login
Credentials associated with the Compute Engine instance.
If you are connecting to Cloud SQL from a Compute Engine instance, the Cloud SQL Auth Proxy can use the service account associated with the Compute Engine instance. If the service account has the required permissions for the Cloud SQL instance, the Cloud SQL Auth Proxy authenticates successfully. If the Compute Engine instance is in the same project as the Cloud SQL instance, the default service account for the Compute Engine instance has the necessary permissions for authenticating the Cloud SQL Auth Proxy. If the two instances are in different projects, you must add the Compute Engine instance's service account to the project containing the Cloud SQL instance.Environment's default service account
If the Cloud SQL Auth Proxy cannot find credentials in any of the places covered earlier, it follows the logic documented in Setting Up Authentication for Server to Server Production Applications. Some environment (such as Compute Engine, App Engine, and others) provide a default service account that your application can use to authenticate by default. If you use a default service account, it must have the permissions outlined in roles and permissions For more information about Google Cloud's approach to authentication, see Authentication overview.
Create a service account
- In the Google Cloud console, go to the Service accounts page.
- Select the project that contains your Cloud SQL instance.
- Click Create service account.
- In the Service account name field, enter a descriptive name for the service account.
- Change the Service account ID to a unique, recognizable value and then click Create and continue.
-
Click the Select a role field and select one of the following roles:
- Cloud SQL > Cloud SQL Client
- Cloud SQL > Cloud SQL Editor
- Cloud SQL > Cloud SQL Admin
- Click Done to finish creating the service account.
- Click the action menu for your new service account and then select Manage keys.
- Click the Add key drop-down menu and then click Create new key.
-
Confirm that the key type is JSON and then click Create.
The private key file is downloaded to your machine. You can move it to another location. Keep the key file secure.
Use the Cloud SQL Auth Proxy with private IP
To connect to a Cloud SQL instance using private IP, the Cloud SQL Auth Proxy must be on a resource with access to the same VPC network as the instance.
The Cloud SQL Auth Proxy uses IP to establish a connection with your Cloud SQL instance. By default, the Cloud SQL Auth Proxy attempts to connect using a public IPv4 address.
If your Cloud SQL instance has only private IP or the instance has both public and private IP configured, and you want the Cloud SQL Auth Proxy to use the private IP address, then you must provide the following option when you start the Cloud SQL Auth Proxy:
--private-ip
Use the Cloud SQL Auth Proxy with instances that have Private Service Connect enabled
You can use the Cloud SQL Auth Proxy to connect to a Cloud SQL instance with Private Service Connect enabled.
The Cloud SQL Auth Proxy is a connector that provides secure access to this instance without a need for authorized networks or for configuring SSL.
To allow Cloud SQL Auth Proxy client connections, you must set up a DNS record which matches the recommended DNS name that's provided for the instance. The DNS record is a mapping between a DNS resource and a domain name.
For more information about using the Cloud SQL Auth Proxy to connect to instances with Private Service Connect enabled, see Connect using the Cloud SQL Auth Proxy.
Create a database user account for the Cloud SQL Auth Proxy
When you connect to your instance using the Cloud SQL Auth Proxy, you provide a user account to log in to the instance. You can use any database user account for this purpose. However, because the Cloud SQL Auth Proxy always connects from a hostname that cannot be accessed except by the Cloud SQL Auth Proxy, you can create a user account that can be used only by the Cloud SQL Auth Proxy. The advantage of doing this is that you can specify this account without a password without compromising the security of your instance or your data.
To create a user account that can only be used with the Cloud SQL Auth Proxy, specify the
hostname as 'cloudsqlproxy~[IP_ADDRESS]'
. You can also use the IP address
wildcard, which would result in 'cloudsqlproxy~%'
. The full user account name
would be:
'[USER_NAME]'@'cloudsqlproxy~%'
or
'[USER_NAME]'@'cloudsqlproxy~[IP_ADDRESS]'
For help with creating a user, see Creating and Managing Users. For information about how Cloud SQL works with user accounts, see Users.
Run the Cloud SQL Auth Proxy in a separate process
Running the Cloud SQL Auth Proxy in a separate Cloud Shell terminal process can be useful, to avoid mixing its console output with output from other programs. Use the syntax shown below to invoke the Cloud SQL Auth Proxy in a separate process.
Linux
On Linux or macOS, use a trailing &
on the command line to
launch the Cloud SQL Auth Proxy in a separate process:
./cloud-sql-proxy INSTANCE_CONNECTION_NAME
--credentials-file PATH_TO_KEY_FILE &
Windows
In Windows PowerShell, use the Start-Process
command to launch
the Cloud SQL Auth Proxy in a separate process:
Start-Process --filepath "cloud-sql-proxy.exe"
--ArgumentList "
--credentials-file PATH_TO_KEY_FILEINSTANCE_CONNECTION_NAME"
Run the Cloud SQL Auth Proxy in a Docker container
To run the Cloud SQL Auth Proxy in a Docker container, use the Cloud SQL Auth Proxy Docker
image available from the
Google Container Registry.
You can install the Cloud SQL Auth Proxy Docker image with this gcloud
command:
docker pull gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0
You can start the Cloud SQL Auth Proxy using either TCP sockets or Unix sockets, with the commands shown below.
TCP sockets
docker run -d \ -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \ -p 127.0.0.1:3306:3306 \ gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0 \ --address 0.0.0.0 \ --credentials-file /path/to/service-account-key.json \ INSTANCE_CONNECTION_NAME
Unix sockets
docker run -d \ -v /PATH_TO_HOST_TARGET:/PATH_TO_GUEST_TARGET \ -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \ gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.14.0 --unix-socket /cloudsql \ --credentials-file /path/to/service-account-key.json/PATH_TO_KEY_FILE \ INSTANCE_CONNECTION_NAME
If you are using a container optimized image, use a writeable directory
in place of /cloudsql
, for example:
v /mnt/stateful_partition/cloudsql:/cloudsql
If you are using the credentials provided by your Compute Engine instance,
do not include the credential_file
parameter and the
-v PATH_TO_KEY_FILE:/path/to/service-account-key.json
line.
Running the Cloud SQL Auth Proxy as a service
Running the Cloud SQL Auth Proxy as a background service is an option for local development and production workloads. In development, when you need to access your Cloud SQL instance, you can start the service in the background and stop it when you're finished.
For production workloads, the Cloud SQL Auth Proxy doesn't currently provide built-in support for running as a Windows service, but third-party service managers can be used to run it as a service. For example, you can use NSSM to configure the Cloud SQL Auth Proxy as a Windows service, and NSSM monitors the Cloud SQL Auth Proxy and restarts it automatically if it stops responding. See the NSSM documentation for more information.
Enforce the use of the Cloud SQL Auth Proxy
Enable the use of the Cloud SQL Auth Proxy in Cloud SQL using ConnectorEnforcement.
If you're using a Private Service Connect-enabled instance, then there's a limitation. If the instance has connector enforcement enabled, then you can't create read replicas for the instance. Similarly, if the instance has read replicas, then you can't enable connector enforcement for the instance.
gcloud
The following command enforces the use of Cloud SQL connectors.
gcloud sql instances patch INSTANCE_NAME \ --connector-enforcement REQUIRED
To disable the enforcement, use the following line of code:
--connector-enforcement NOT_REQUIRED
The update doesn't trigger a restart.
REST v1
The following command enforces the use of Cloud SQL connectors
Before using any of the request data, make the following replacements:
- project-id: The project ID.
- instance-id: The instance ID.
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
Request JSON body:
{ "settings": { "connectorEnforcement": "REQUIRED" } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id", "status": "PENDING", "user": "user@example.com", "insertTime": "2020-01-16T02:32:12.281Z", "operationType": "UPDATE", "name": "operation-id", "targetId": "instance-id", "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id", "targetProject": "project-id" }
To disable the enforcement, use "connectorEnforcement": "NOT_REQUIRED"
instead. The update does not trigger a restart.
REST v1beta4
The following command enforces the use of Cloud SQL connectors.
Before using any of the request data, make the following replacements:
- project-id: The project ID.
- instance-id: The instance ID.
HTTP method and URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Request JSON body:
{ "settings": { "connectorEnforcement": "REQUIRED" } }
To send your request, expand one of these options:
You should receive a JSON response similar to the following:
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id", "status": "PENDING", "user": "user@example.com", "insertTime": "2020-01-16T02:32:12.281Z", "operationType": "UPDATE", "name": "operation-id", "targetId": "instance-id", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id", "targetProject": "project-id" }
To disable the enforcement, use "connectorEnforcement": "NOT_REQUIRED"
instead. The update does not trigger a restart.
Tips for working with Cloud SQL Auth Proxy
Invoke the Cloud SQL Auth Proxy
All of the sample proxy invocations start the Cloud SQL Auth Proxy in the background, so a prompt is returned. Reserve that Cloud Shell terminal for the Cloud SQL Auth Proxy, to avoid having its output mixed with the output from other programs. Also, the output from the Cloud SQL Auth Proxy can help you diagnose connection problems, so it can be helpful to capture in a log file. If you do not start the Cloud SQL Auth Proxy in the background, the output goes to stdout unless redirected.
You do not have to use /cloudsql
as the directory for the Cloud SQL Auth Proxy sockets. (That
directory name was chosen to minimize differences with App Engine
connection strings.) If you change the directory name, however, keep the overall
length to a minimum; it is incorporated in a longer string that has a length
limit imposed by the operating system. It depends on the system, but it's usually
between 91-108 characters. On Linux, the length is usually defined as 108, and
you can use the following command to check:
cat /usr/include/linux/un.h | grep "define UNIX_PATH_MAX"
Use the Cloud SQL Auth Proxy to connect to multiple instances
You can use one local Cloud SQL Auth Proxy client to connect to multiple Cloud SQL instances. The way you do this depends on whether you are using Unix sockets or TCP.
Unix sockets
To connect the Cloud SQL Auth Proxy to multiple instances, you provide each instance connection name as an argument to the Cloud SQL Auth Proxy, in a space-separated list. The Cloud SQL Auth Proxy connects to each instance when it starts.
You connect to each instance using its socket, in the specified directory.
For example:
./cloud-sql-proxy --unix-socket /cloudsql \ myProject:us-central1:myInstance myProject:us-central1:myInstance2 & mysql -u myUser -S /cloudsql/myProject:us-central1:myInstance2
TCP sockets
When you connect using TCP, you specify a port on your machine for the Cloud SQL Auth Proxy to listen on for each Cloud SQL instance. When connecting to multiple Cloud SQL instances, each port specified must be unique and available for use on your machine.
For example:
# Start the Cloud SQL Auth Proxy to connect to two different Cloud SQL instances. # Give the Cloud SQL Auth Proxy a unique port on your machine to use for each Cloud SQL instance. ./cloud-sql-proxy "myProject:us-central1:myInstance?port=3306" \ "myProject:us-central1:myInstance2?port=1234" # Connect to "myInstance" using port 3306 on your machine: mysql -u myInstanceUser --host 127.0.0.1 --port 3306 # Connect to "myInstance2" using port 1234 on your machine: mysql -u myInstance2User --host 127.0.0.1 --port 1234
Troubleshoot Cloud SQL Auth Proxy connections
The Cloud SQL Auth Proxy Docker image is based on a specific version of the Cloud SQL Auth Proxy. When a new version of the Cloud SQL Auth Proxy becomes available, pull the new version of the Cloud SQL Auth Proxy Docker image to keep your environment up to date. You can see the current version of the Cloud SQL Auth Proxy by checking the Cloud SQL Auth Proxy GitHub releases page.
If you are having trouble connecting to your Cloud SQL instance using the Cloud SQL Auth Proxy, here are a few things to try to find what's causing the problem.
Verify that you're using the IP address to connect to the instance, and not the write endpoint.
Check the Cloud SQL Auth Proxy output.
Often, the Cloud SQL Auth Proxy output can help you determine the source of the problem and how to solve it. Pipe the output to a file, or watch the Cloud Shell terminal where you started the Cloud SQL Auth Proxy.
If you are getting a
403 notAuthorized
error, and you are using a service account to authenticate the Cloud SQL Auth Proxy, make sure the service account has the correct permissions.You can check the service account by searching for its ID on the IAM page. It must have the
cloudsql.instances.connect
permission. TheCloud SQL Admin
,Client
andEditor
predefined roles have this permission.If you are connecting from App Engine and are getting a
403 notAuthorized
error, check theapp.yaml
valuecloud_sql_instances
for a misspelled or incorrect instance connection name. Instance connection names are always in the formatPROJECT:REGION:INSTANCE
.Also, check that the App Engine service account (for example, $PROJECT_ID@appspot.gserviceaccount.com) has the Cloud SQL Client IAM role.
If the App Engine service lives in one project (project A) and the database lives in another (project B), this error means the App Engine service account has not been given the Cloud SQL Client IAM role in the project with the database (project B).
Make sure to enable the Cloud SQL Admin API.
If it is not, you see output like
Error 403: Access Not Configured
in your Cloud SQL Auth Proxy logs.If you are including multiple instances in your instances list, make sure you are using a comma as a delimiter, with no spaces. If you are using TCP, make sure you are specifying different ports for each instance.
If you are connecting using UNIX sockets, confirm that the sockets were created by listing the directory you provided when you started the Cloud SQL Auth Proxy.
If you have an outbound firewall policy, make sure it allows connections to port 3307 on the target Cloud SQL instance.
You can confirm that the Cloud SQL Auth Proxy started correctly by looking in the logs under the Operations > Logging > Logs explorer section of the Google Cloud console. A successful operation looks like the following:
2021/06/14 15:47:56 Listening on /cloudsql/$PROJECT_ID:$REGION:$INSTANCE_NAME/3306 for $PROJECT_ID:$REGION:$INSTANCE_NAME 2021/06/14 15:47:56 Ready for new connections
Quota issues: When the Cloud SQL Admin API quota is breached, the Cloud SQL Auth Proxy starts up with the following error message:
There was a problem when parsing a instance configuration but ignoring due to the configuration. Error: googleapi: Error 429: Quota exceeded for quota metric 'Queries' and limit 'Queries per minute per user' of service 'sqladmin.googleapis.com' for consumer 'project_number:$PROJECT_ID., rateLimitExceeded
Once an application connects to the proxy, the proxy reports the following error:
failed to refresh the ephemeral certificate for $INSTANCE_CONNECTION_NAME: googleapi: Error 429: Quota exceeded for quota metric 'Queries' and limit 'Queries per minute per user' of service 'sqladmin.googleapis.com' for consumer 'project_number:$PROJECT_ID., rateLimitExceeded
Solution: Either identify the source of the quota problem, for example, an application is misusing the connector and unnecessarily creating new connections, or contact support to request an increase to the Cloud SQL Admin API quota. If the quota error appears on startup, you must re-deploy the application to restart the proxy. If the quota error appears after startup, a re-deploy is unnecessary.
What's next
- Learn more about the Cloud SQL Auth Proxy.
- Learn more about Identity and Access Management (IAM).
- Learn more about Service Accounts.
- Learn about the two levels of access control for Cloud SQL instances.
- Create users and databases.
- Learn about connecting to your instance from your application.
- Learn about MySQL Client.
- Learn about options for support.