We have an issue With Google Cloud SQL (Second Generation).
Most inserts are failing with the following error:
The MySQL server is running with the --read-only option so it cannot execute this statement.
We have made no changes. This suddenly started happening. Tried restarting the Google Cloud SQL instance but it had no effect.
Any suggestions on how we might fix quickly?
Google have fixed the problem. Their response was:
We had a problematic configuration that was directing traffic to both master and replica. The changes should have been reverted and you shouldn't see this issue anymore.
I deleted the failover replica and after a few seconds it works well again. It seems that it was a problem with the replica readonly message.
Unfortunately, this seems to happen from time to time on Google CloudSQL. We've configured an alarm that listens to this error in our logs and after restarting the application it usually starts working again.
Related
Recently MySQL RDS DB instance restarted twice. All I see is it is switched over to a different node. I searched the logs to see if there was any information that would help me understand why it had stopped working. Following the instance restart, the general, audit, and error logs were all emptied out and started over from scratch.
Would someone kindly tell me how to -
Ascertain the cause of its restart? Since it is an automated procedure, I have no knowledge about other nodes.
Configure a cloud-watch alarm or notification before it fails over?
Thanks
I have been using MySQL workbench for years. Recently the previous version 8.0.nnn stopped launching. I decided to try to repair the installation by upgrading. It worked for a few days and now it hangs again.
Uninstalling and reinstalling is not helping.
There are no notifications in event viewer. There is a task (process) in Task Viewer, but the process does not progress to showing a window.
I can connect to, and query, the server on the command line or via the API (not that it is required for launching Workbench).
Any ideas about origin of this rather perplexing problem?
I discovered that the user data (User\AppData\Roaming\MysSQL\Workbench) contained corrupted files.
The error message popup (window) remains hidden, but can be seen when using Alt-Tab to rotate between applications. One cannot bring focus on the error window, but one can see the message among the choices in the Alt-Tab interface. I could see something about corrupt file and that it was in the profile's Roaming.
Deletion of the single file that was indicated (wb_state.xml) was insufficient to get WorkBench to display. Deletion of all files in the Workbench directory restored Workbench.
Hope this is of some use to others.
I recently set up an AWS RDS MySQL instance. I installed MySQL Workbench on my M1 Macbook, successfully connected with my credentials and started working away. The next day, I found that I was no longer connected to the database server, and upon trying to reconnect with the saved credentials - I found that I couldn't.
Unable to connect to localhost
I check the credentials about 8 times, I check the AWS Console to see if everythings okay (status is "Available"). I ended up having to delete my AWS RDS instance, uninstall workbench, and restart everything before it finally worked. I did some more work on this new database.
The next day, I found that the same thing had occurred - I was disconnected from the database server on MySQL workbench, and I could not reconnect.
Why does this keep happening? Please help, as I can't find anything about it on other stackoverflow threads.
I seem to have solved it! I just needed to add my IP address to the AWS RDS instance's "inbound rules", so that it allows traffic coming from me. That step was not described in the documentation here: https://aws.amazon.com/premiumsupport/knowledge-center/connect-rds-mysql-workbench/.
I also noticed that you have the option to allow all traffic to your database, but I figured that would probably pose some kind of security risk so I didn't do it (but perhaps not, since you still need the credentials and endpoint to access it..?).
I have a MySQL database running on AWS RDS. I have a node.js server that queries the MySQL database. Everything is fine for most days but around once a week, my node server says "Unknown database."
I try to query the database with MySQL Workbench and receive the same message. I have checked my instance and it is running fine with the status being "available."
To fix the issue, I have to recreate the database which means I lose all my data.
Has anyone had issues with this? This is very frustrating since I have no idea what would cause this problem.
We‘re running MySQL RDS databases since AWS launch and never had such an issue. Are you sure the created database is really gone? Do you maybe have a job running at an interval that doesn’t work as intended? What do the RDS logs say?
To debug the issue you can
have a look at RDS server logs
enable query logging to table and analyze queries fired at the server
run a small instance which is not touched for the period to proof it’s not a RDS-related isssue
A few years later...lol. I had the same problem and realised you have to be connected to the same domain in AWS as your database. If you know the connection string of your database, find the domain it is in. Then in the top right hand side of the aws console you should see a drop down that shows the current domain you are logged into. My guess is the two are not the same. Change the value of the drop down and you should see your database.
I have been stumped on this for this whole day now. I use MS SQL Server 2008. I have alinked server pointing to a DB2 database using an ODBC connection that has been running fine for years. Today I decided to change the name of the server and now whenever I run an openquery, run a job that connects to this linked server or when I try to see the tables of this linked server the query/job will run permanently and the tables forever say [Expanding...] but they never actually show. When I try to cancel a query that is stuck, it will never finish canceling. The only way I have found to actually stop queries is to log my account out and end my session forcefully (MS SQL server will tell me it cannot shut down but I can log my Windows account out get past it).
We already tried to recreate this exact linked server by scripting it and using a different linked server name but this gave the same result. I also tried recreating this linked server on another actual server and that worked fine. The server where the linked server is "stuck" on, works perfectly fine as long as I don't try to connect/communicate to these broken linked servers.
My question is basically, what in the world happened when I just changed the name of this server and does anyone have any suggestions on resolving this? I have pondered about a complete server restart, but since this concerns a production server this would be my absolute last resort. I however see no other options right now.
Solution was to do a complete server restart and to back up to an earlier date. We have done the exact same thing after that and everything worked fine, so it seemed like it was a one time critical anomaly.