I have followed the procedure on this tutorial:
https://www.youtube.com/watch?v=Bz-4wTGD2_Q
but for some reason I get an error when I reach minute 5:03. See attached error. Could it be due to security groups? In the video it only says 'wide open'
Related
I'm getting the following error for a DB I have.
“1226 (42000): User ‘?????????’ has exceeded the ‘max_connections_per_hour’ resource (current value: 85)”
I did create a simple script that opens and closes the database connection to try and troubleshoot, which I was able to replicate.
What can I do to increase max connections per hour?
The DB is managed through AWS RDS. Most of the solutions that I read about include upgrading the instance.
85 connections in an hour doesn't seem like much so there has to be another solution.
I have created an RDS on AWS which initially shows the status of 'available' but when I use my sql client to connect to it I receive the error:
Status : Failure -Test failed: IO Error: Connection reset by peer, Authentication lapse 0 ms
Then when I check the status of the RDS online (AWS dashboard) it says 'stopping'.
When I try to start the RDS again it's status will go from 'starting' to 'stopping' after a couple of minutes and then eventually 'stopped'. I can't find anything online referring to an RDS automatically stopping and I am somewhat a novice to AWS.
Based on the comments.
The solution was found by checking CloudTrial Event history. Based on the search it was identified that StopDBInstance was issued by HIPComplianceWorker user.
This probably means that there is an automation that checks the db instances launched and verifies if they comply with your companies policies. Your instance could be violating such policies, and it was automatically stopped.
You would have to contact your admins to check with them what kind of RDS you can use.
I am receiving a lot of error reports from my Django server throwing:
(2005, "Unknown MySQL server host 'my-address.us-east-1.rds.amazonaws.com' (0)").
The server has been connecting to this database for more than a year without any issue. But this morning I suddenly started to receive this error, even though I didn't do any changes to the code.
Furthermore, when I connect to my website, it actually loads data from the database fine.
Apparently there is a random chance that it won't manage to connect?
Any idea what can cause that and how to fix it?
I am on Amazon lightsail.
There is an active AWS DNS resolving incident in us-east-1 region. Seems like it will be mitigated soon.
https://status.aws.amazon.com/
UPDATE: The issue is now resolved as updated by AWS.
I've been successfully using the Google cloud_sql_proxy on multiple Compute Engine instances for some time, until today, one instance at a time, the proxy started to show the following error pattern:
2017/05/30 13:28:07 New connection for "project-id-1234:us-central1:sql_instance"
2017/05/30 13:28:07 couldn't connect to "project-id-1234:us-central1:sql_instance": Post https://www.googleapis.com/sql/v1beta4/projects/project-id-1234/instances/sql_instance/createEphemeral?alt=json: stream error: stream ID 1; PROTOCOL_ERROR
2017/05/30 13:28:41 New connection for "project-id-1234:us-central1:sql_instance"
2017/05/30 13:28:41 Thottling refreshCfg(project-id-1234:us-central1:sql_instance): it was only called 33.490705951s ago
2017/05/30 13:28:41 couldn't connect to "project-id-1234:us-central1:sql_instance": Post https://www.googleapis.com/sql/v1beta4/projects/project-id-1234/instances/sql_instance/createEphemeral?alt=json: stream error: stream ID 1; PROTOCOL_ERROR
When trying to connect directly to MySQL (while using the proxy) I get error 2013 (HY000):
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 "Internal error/check (Not system error)"
What I've tried
Restarting the cloud_sql_proxy yielded a temporary fix until finally both my Compute Engine instances are unable to connect to my Cloud SQL instance and the proxies show only this result.
Restarting the Cloud SQL instance and both Compute Engine instances.
Eliminating the proxy: I added the appropriate networks to my SQL instance's Authorized Networks, and updated all applications to use the public IP. This restored functionality to my production apps, but now I'm using a public connection instead of local/proxy.
Some research
I came across a similar issue relating to Google Cloud SQL that yielded the same MySQL error above, but it appears to have only affected connecting to Cloud SQL from external, non GCE/GKE networks.
A few others have reported the same issue also started for them this morning on the Google Cloud SQL Discuss group.
My team started seeing the same issue appear today, with GKE managed servers. Same as you saw: restarts of servers and DB did nothing.
We tried doing an update of the version of Google Cloud Proxy we were using from v1.05 to v1.09 and the problem went away (for now).
I know that's not much of an explanation but give it a try to see if that helps you.
I have an RDS instance that I was able to connect to remotely fine for months now. However, tonight I downsized the DB because we we're paying for a lot of unused CPU. After the change from m3.medium to the t2.small I can't connect to it anymore. I have terminal shortcuts setup so I can't be typoing it. I double checked the security groups and thats still applied and the host is the same and everything. I'm not sure what else to try. I just get:
ERROR 2003 (HY000): Can't connect to MySQL server on '<my-host>.us-east-1.rds.amazonaws.com' (60)
I encountered the same problem today. After upsizing the RDS instance, I am unable to connect to it using SSMS which I was able to do just a few hours earlier. It has suddenly stopped working on two PCs so I could not have accidentally changed some parameters. However the web server accessing the RDS within the VPC works fine
sorry for silly question: are you sure my-host didn't change after resizing? Given the error message, it's not credentials. So, it is either address, or security groups, or VPC-based networking.