Google Cloud SQL: after an upgrade SQL from the first generation to second MySQL workbench can’t connect my instance in Cloud. Why?
Maybe you need to do instance 5.7 ?
Google application Engine: after upgrade SQL from the first generation to second MySQL opening a new WEB application and connect to my project in Cloud, it can’t see my instance. Why?
Any of these three configurations might eventually prevent the connection from GAE:
a) If you haven't assigned any public IP address to the instance;
the only option to connect would be: Configuring Serverless VPC Access.
b) Confirm and complete the upgrade reads:
If your applications are connecting using the First Generation instance connection name:
<project_id>:<instance_id>
update them to use the Second Generation instance connection name:
<project_id>:<region>:<instance_id>
c) Another possible culprit would be the service-account used - and it's assigned roles:
App Engine uses a service account to authorize your connections to Cloud SQL. This service account must have the correct IAM permissions to successfully connect. Unless otherwise configured, the default service account is in the format service-PROJECT_NUMBER#gae-api-prod.google.com.iam.gserviceaccount.com.
Authorization with authorized networks is usually not required when connecting from GAE.
Related
I am trying to reach our Postgres SQL server running as a GCP Cloud SQL instance from the PgAdmin 4 tool on desktop. For that you have to whitelist your IP address. Until this point it was working fine, the whole team used IPV4 addresses, but I moved to a new country where my new ISP assigned an IPV6 address to me, and it seems like GCP doesn't allow IPV6 addesses to be whitelisted, thus you can't use them to connect.
Here's a picture of the Connections/Allowed Networks tab:
Is there any kind of solution to this?
Or do they expect me to only have ISPs who assign IPV4 addesses to me?
Thank you.
Alternatively, you could just use the Cloud SQL Auth Proxy directly. You'll have to run an instance of it on your local machine and then PgAdmin can connect to the proxy on localhost.
Yes, there is a workaround for this but not using the UI, instead you need to use the Cloud SDK.
This has recently been added to cloud SDK beta. So as you can see in the documentation for gcloud sql connect:
If you're connecting from an IPv6 address, or are constrained by certain organization policies (restrictPublicIP, restrictAuthorizedNetworks), consider running the beta version of this command to avoid error by connecting through the Cloud SQL proxy: gcloud beta sql connect.
I couldn't find any Feature Requests for this being implemented into the UI at the moment, so if you'd like to have this changed I would suggest you to open one in Google's Issue Tracker system.
I am trying to create a AWS RDS Sql Server database and connect to it from a local machine using SSMS. Later I'll be connecting from a web application (locally, then hosted somewhere eventually.) I am currently failing to connect to my instance (the instance is configured and running.) The error I'm getting is the network/instance related (not login.) Tried telnet and I can't even hit it that way.
Looking on the web, there seems to be a setup for network connections but it talks about EC2, VPC and things I don't think I need (or do I?)
Tried (nothing worked so far): Using the IP instead of hostname, explicitly specifying the port (1433), changing user/password, crying.
Speaking of things I hope I don't need to configure, there's also IAM authentication - didn't touch that yet.
Any input is appreciated before I open a ticket with Amazon.
UPDATE:
My scenario: Scenario
Solution - add the Inbound Rule to default Security Group: Security Groups
When you work with RDS, you need to set inbound rules; otherwise, you are unable to connect to the database. This concept is covered in this AWS tutorial. In this AWS tutorial, the database is MySQL and the app is a Java web app. However, the same concepts apply with respect to inbound rules:
Creating the Amazon Relational Database Service item tracker
One tip -- when you set an inbound rule to let your development machine connect, you can select MyIP...
Also - when you host your app (for example Elastic Beanstalk), you need to set an inbound rule for that as well (as discussed in that tutorial)
We have a GCE VM with MySQL server. Firewall rules deny incoming connections from external IP. Our cloud build process requires to perform DB migrations so it needs to connect to MySQL from Cloud Build. I want to add a Firewall rule to allow only cloud builder to connect through 3306 from the external IP address.
Cloud Build does not run on internal network so there is no way to connect from the internal IP.
I tried adding a rule for service account scope but I can't see cloud build service account in the list.
Currently, as mentioned by #guillaume blaquiere, there is a Feature Request. I recommend you to follow it (star) to receive all the updates there. Seems that the FR has been sent to the Cloud Build engineering team and they will evaluate it. Also note that there is not yet an ETA of the implementation.
I've created a new SQL Server instance and database on GCP. The "Overview" tab shows the following info:
Connect to this instance
Public IP address: 35.223.145.123
Instance connection name: my-quest-263123:us-central1:my-instance-1
The connections tab has "Public IP" checked. I was able to "Add Network" on this tab with my public ip address. An instruction next to the Network input says "Use CIDR notation." I wasn't able to figure out how to do this offhand but this input accepted my standard public IP address. SSL is not enabled/required for this connection.
I updated the password for the SQL Server user on the Users tab and attempted to login to this SS instance via SSMS with:
Server name = my-quest-263123:us-central1:my-instance-1
Authentication = "SQL Server Authentication"
Login = sqlserver
Password = (sqlserver password)
However, I wasn't able to connect to the instance using this approach. I also created a new User for my GCP SQL instance but I wasn't able to connect to the instance with this new user either. Any idea what I might be missing here?
Any idea what I might be missing here?
Please bear in mind that Cloud SQL with SQL server is still in beta and it may cause unexpected behaviors. If you have the option, you could always change to use MySQL or PostgreSQL.
As for your actual set up, I highly recommend you to follow the next tutorials since you will find out how to connect to your SQL server instance with SSMS and with the command-line through the Cloud Shell:
If you would like to do local testing, you could use the Cloud SQL proxy and refer to this documentation.
If you would like to use SSMS you can always follow the next documentation.
Following either of those tutorials you should be able to connect successfully to your SQL server instance.
I hope it helps.
For connecting SSMS to a Cloud SQL for SQL Server instance, the recommended approach is to use the Cloud SQL Proxy, which gives you a secure SSL connection to the database. Here's a blog post that covers how to do that, let me know if you have any questions: Managing SQL Server instances in Cloud SQL.
I have a project with Cloud Composer and Cloud SQL.
I am able to connect to Cloud SQL because i edited the yaml of airflow-sqlproxy-service and added my Cloud SQL instance on cloud proxy used for the airflow-db, mapping to port 3307.
The workers can connect to airflow-sqlproxy-service on port 3307 but i think the webserver can't connect to this.
Do i need to add some firewall rule to map the 3307 port so the webserver or the UI can connect to airflow-sqlproxy-service?
https://i.stack.imgur.com/LwKQK.png
https://i.stack.imgur.com/CJf7Q.png
https://i.stack.imgur.com/oC2dJ.png
Best regards.
Composer does not currently support configuring additional sql proxies from the webserver. One workaround for cases like this is to have a separate DAG which loads Airflow Variables with the information needed from the other database (via the workers which do have access), then generate a DAG based on the Variable which the webserver can access.
https://github.com/apache/incubator-airflow/pull/4170 recently got merged (not currently available in Composer), which defines a CloudSQL connection type. This might work for these use cases in the future.