I am trying to connect data studio to a MySQL second-generation instance in Google Cloud SQL. I am using a JDBC URL like this:
jdbc:mysql://104.xx.yy.zz/prod
But keep getting this:
The server encountered an internal error and was unable to complete your request.
Has anyone else seen this?
Thanks for any tips or pointers.
Problem solved: the following IP addresses needed to be added as authorized networks in the Access Control section of Cloud SQL. Really wish Google would say something like "connection refused" rather than "internal error".
64.18.0.0/20
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
173.194.0.0/16
207.126.144.0/20
209.85.128.0/17
216.239.32.0/19
I think that previous list is missing a couple IPs. Here is a more comprehensive list:
64.18.0.0/20
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
108.177.8.0/21
173.194.0.0/16
207.126.144.0/20
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19
Related
We are trying to connect to the snowflake instance using snowflake-sqlalchemy library (latest version).
Getting next error:
[2020-09-28 14:47:47,558] {{connection.py:409}} WARNING - Certificate did not match expected hostname: xxxxxxx.europe-west4.snowflakecomputing.com. Certificate: {'subject': ((('commonName', '*.us-west-2.snowflakecomputing.com'),),), 'subjectAltName': [('DNS', '*.us-west-2.snowflakecomputing.com'), ('DNS', '*.snowflakecomputing.com'), ('DNS', '*.global.snowflakecomputing.com'), ('DNS', '*.prod1.us-west-2.aws.snowflakecomputing.com'), ('DNS', '*.prod2.us-west-2.aws.snowflakecomputing.com'), ('DNS', '*.us-west-2.aws.snowflakecomputing.com')]}
Seems like the certificates for the snowflake instance do not match the host.
Is there any way to resolve this issue?
This is on a trial account if that matters.
As noted by #Suzy Lockwood, the domain being generated is wrong. The reason it ends up pointing to *.us-west-2.snowflakecomputing.com is because the target, lacking the gcp or azure ends up getting a redirect to us-west-2, where (of course) the certificate is wrong for what was expected.
The solution (for me) turned out to be that region needs the .azure suffix, not just the region. I'd given it that information under 'account' - I'm not sure if the presence of the region parameter got in the way, or if both are needed. But, it is working now, and I'm loathe to touch it more today. :)
I noticed europe-west4. Is that a GCP account? If so, I think your URL/hostname is supposed to look like this, but you can double-check in the UI:
XXXXX.europe-west4.GCP.snowflakecomputing.com
The airflow snowflake objects are built for AWS, and not compatible for GCP so I will need to find GCP versions or create GCP compatible versions.
I think this is how you would solve the issue. The account name should also contain the gcp. as shown in the article above
{
"account":"xxxxx.us-central1.gcp",
"warehouse":"COMPUTE_WH",
"region":"us-central1",
"database":"CITIBIKE",
"schema":"PUBLIC"
}
I am trying to access Datastore Admin on Google App Engine but I get Unable to resolve the server's DNS address error.
The url that cannot be translated is: [https protocol]ah-builtin-python-bundle-dot-[myapp].gene.com/_ah/datastore_admin/?app_id=s~gene.com:[myapp]&adminconsolecustompage
I tried with adding exceptions to coookies because when I try directly access it with [http protocol][myapp].gene.com/_ah/datastore_admin I get error with redirect loop.
Any idea? Any workarounds are also welcomed - I just need to copy datastore to local environment.
Witek
Thank you, Patrick.
Your guess turned out to be the right one. The domain is not set up properly and this is the reason of problems.
I tried to set up WordPress under Google App Engine earlier tonight (following the instructions here: https://developers.google.com/appengine/articles/wordpress).
It runs fine locally, but when I push to remote I get a database error (visible at https://wp-dot-frontiermediag.appspot.com/). If we throw on a /wp_admin/install.php you get:
This either means that the username and password information in your
wp-config.php file is incorrect or we can't contact the database server
at :/cloudsql/frontiermediag:fmwp. This could mean your host's database
server is down.
Here's the relevant code in wp-config:
/** MySQL hostname */
if(isset($_SERVER['SERVER_SOFTWARE']) && strpos($_SERVER['SERVER_SOFTWARE'],'Google App Engine') !== false) {
define('DB_HOST', ':/cloudsql/frontiermediag:fmwp');
}else{
define('DB_HOST', 'localhost');
}
frontiermediag:fmwp is showing "Status Runnable" in Developers Console > Cloud SQL.
I did this once before and it worked so I'm not sure what I'm missing here. I thought it might have been because I'm using WP 3.8.1. but rolled back to 3.5.1 and same thing's happening.
Any ideas? frontiermediag is listed as an authorized application on the :fmwp ACL.
This situation happened to me earlier.However, I edited my Cloud SQL instance , and set "Preferred Location" as "Follow App Engine App" from Google Developers Console. This database connection problem was solved in my case.
I tried the instructions with wordpress 3.5.1 and the instructions seem to work for me. The code snippet you have above seems right and I am not sure what could be wrong without looking at rest of your code. Can you try the instructions from the beginning one more time with 3.5.1?
I had this issue, because "Follow App Engine App" doesn't seem to be an option for second generation instances in my case, and so the instance connection name includes the region setting.
Look at the instance details, and under properties, find "Instance connection name". That is the text that should follow :cloudsql/.
I built a system running on: http://www.hijgoo.com.tw and all the sudden, there was the following message and it did persist. I am using GAE SDK 1.7.2 with Python 2.7. Can anyone help?
Error: Server Error
The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it.
Looks like you have a session that does not contain the key account, but your code assumes that it does.
The reason for this isn't easy to see without the actual code, but it sounds like a programming error.
I am a DBA, not a developer, so forgive me if this is a silly question. But we are having issues with a SQL Server 2005 Web Service end point. On the local network I am able to add the reference in Visual Studio 2010 with out any issues. It uses digest as the authentication scheme.
However, when anyone tries to add the web reference on another network, such as a developer in New Zealand (we are in Dayton, OH USA) he receives this error:
There was an error downloading
'http://server.domain.net:1280/release-single-address?wsdl'. The
request failed with HTTP status 505: HTTP Version not supported.
Metadata contains a reference that cannot be resolved:
'http://server.domain.net:1280/release-single-address?wsdl'. The
remote server returned an unexpected response: (505) HTTP Version not
supported. The remote server returned an error: (505) Http Version Not
Supported. If the service is defined in the current solution, try
building the solution and adding the service reference again.
Again, this works in Visual Studio as Right Click add Reference -> Advanced -> Add Web Reference when done on the local subnet as the server.
When done on any other network the service does not import. We have tried it w/o any proxy. There is a cross domain trust involved but that does not seem to be the issue as the error occurs using accounts from either domain. When I download the raw XML to my hdd I can use that to create the web reference. I believe firmly this is some sort of transport layer issue, such as a proxy, but captures when the proxy server settings are disabled are not conclusive.
Today, years after I posted this question, we finally found the answer to this question. It was not a Squid proxy server as we had come to believe. We continued experiencing issues like this with various web services/sites. The last straw was when we finally needed to deploy an SVN server that was used by multinational software engineering teams. Every single member of the different Ops teams we spoke to swore to us there was nothing between the sites that could break our services.
By a stroke of luck the company's Chief Information Security Officer was visiting our site and a colleague happened to run into him and asked about the issues we were having and what might be the cause of it. He said immediately that there were Riverbed appliances doing caching and layer 7 inspection on all WAN traffic. We finally managed to catch these devices in the act of attempting to "normalize" HTML and XML and we were able to perform a capture of data coming from a machine in New Zealand. We performed a diff on HTML pages that were served as well as XML coming from a web service to compare how it looked on the local network vs. across the WAN. In the pages/XML that were being served across the WAN the closing tags were inserted that were not needed or that actually made the XML malformed. Some tags were even commented out entirely if the appliance didn't know what to do with them. And the smoking gun? A custom header...
X-RBT-Optimized-By: cch-riverbed-1 (RiOS 6.5.6a) SC
"Optimized" You keep using that word, but I do not think that it means what you think that it means.
I'm not a pro of SOAP with VS but it may be that version of SOAP is incompatible with sql server 2005?
If I recall correctly, there is two versions of SOAP: 1.1 and 1.2.
Check the HTTP GET command format is correct?
HTTP GET http:// mydomain.com HTTP/1.1\
note there is a SPACE between 'http://' and 'mydomain.com'. The server can not match this format. The result is 505
I am not sure but, I think you should check your firewall or your IIS configuration.