Yesterday, my website crashed. Or, what appears to be a crash.
My host (JustHost) have disclosed that it was a SAN problem and have been rebuilding it. It's hard to get anymore information out of them because they are playing their cards very close to their chest for some reason.
I have suffered almost 24 hours downtime in 2 days and I'm getting fed up.
The error I am receiving on the frontend of the website is:
Database connection error (2): Could not connect to MySQL.Database connection error (2): Could not connect to MySQL.
Trying to access my phpMyadmin from cPanel gives me the following error:
Accessing SSH and trying to start the mysql service via putty I get:
Starting MySQL. ERROR! The server quit without updating PID file (/var/lib/mysql /mysqld.pid).
Can anyone please help me resolve this issue as my host is rather useless!
Thanks!
Yep, mysqld is down. Did you try running "mysqld_safe&"?
For anyone who wishes to know the conclusion of this issue.
I have been left with 2 choices:
1) Be patient and wait for Just Host to fix the issue and potentially lose my Google search rankings and a lot more future revenue
2) Set up a new hosting account, transfer my data over and wait for the domain to propagate.
I have chosen the latter of the two. My confidence in Just Host as a customer service hub and web hosting provider has thoroughly diminished to the point where all of my hosting accounts will now be switched over to another provider.
They have let me down by not fixing the issue in good time and have passed me from pillar to post in live chat, email support and phone support. The final nail in the coffin was my request for them to backup my databases and send them to me via email being met with the resoundingly passive "sorry, we do not provide that service" response.
I would do it myself if only I had access to phpMyadmin, which I do not have because of a server error that they have been incapable of fixing for the past 72 hours.
Goodbye Just Host.
Related
I have a running instance of VerneMQ (cluster of 2 nodes) on Google kubernets and using MySQL (CloudSQL) for Auth. Server accepts connections over TLS
It works fine, but after a few days i start seeing this message on the log:
can't authenticate client {[],<<"Client-id">>} from X.X.X.X:16609 due to plugin_chain_exhausted
The client app (paho) complains that the server refused the connection for being "not authorized (code=5 in paho error)"
after a few retry it finally connects. but every time it get's harder and harder until it just won't connect anymore
If i restart VerneMQ everything get's back to normal
I have only 3 clients currently connected at most, at the same time.
clients already connected have no issues in pub/sub.
In my configuration i have (among other things):
log.console.level=debug
plugins.vmq_diversity=on
vmq_diversity.mysql.* = all of them set
allow_anonymous=off
vmq_diversity.auth_mysql.enabled=on
it's like the server degrades over time. the status webpage reports no problem
My verne server was build from the git repository about a month ago and runs on a docker container
what could be the cause?
what else could i check to find posibles causes? maybe a diversity missconfiguration?
Tks
To quickly explain the plugin_chain_exhausted log: with Verne you can run multiple authentication/authorization plugins, and they will be checked in a chain. If one plugin allows the client, it will be in. If no plugin allows the client, you'll see the log above.
This does not explain the behaviour you describe, though. I don't think I have seen that.
In any case, the first thing to check is whether you actually run multiple plugins. For instance: have you disabled the vmq.passwd and the vmq.acl plugins?
I have a MySQL server that is hosting my website. Yesterday, after trying to empty a certain database, I started receiving the following error when attempting to connect to my site :
PDOException: SQLSTATE[HY000] [1040] Too many connections in lock_may_be_available()
(line 167 of /home/vksappc/public_html/prod/includes/lock.inc).
After searching online for a possible solution, I restarted the server and everything was okay. Today, however, I've noticed that the number of active connections is constantly and slowly rising until it reaches the limit of 151 :
Screenshot of thread count
At which point the server then seems to timeout those connections and everything resets, only to start its gradual climb all over again:
Screenshot of new thread count
This is really becoming a big problem and as I am quite new to managing a server, I am not too sure what could be causing this or what to do next.
Any ideas?
Turns out there was a specific connection that was stuck in a loop of sending a request unsuccessfully and trying over and over again. Once we found which connection it was, we were able to kill all its processes and fix the issue. Thanks to #WilsonHauck for the tip in the comments.
I have a Google Cloud SQL Instance that I have been using for some time now and connecting successfully from MySQL Workbench. However as of yesterday I can't connect using MySQL Workbench (or the command line on my laptop) and get the error:
ERROR 2003 (HY000): Can't connect to MySQL server on '207.xxx.xxx.xx' (10060)
I have done the following already:
Authorised my laptop's IP address (found using whatismyip.com) in the Google Console.
Assigned an IPv4 address to the database in the Google Console.
Created new users and passwords to see if it was a user issue. But that didn't help.
Restarted the instance, restarted my home network/laptop and got new IP addresses (and updated the authorised IP address accordingly).
Upgraded to the latest MySQL workbench 6.3 CE but still have the issue.
The database works as my app can connect to it and accesses the data, I just can't get a remote connection from my laptop.
I am new to this and am out of ideas on how to fix it. Any help would be greatly appreciated.
Thanks everyone for your help. After trying all of your suggestions I found a Google group and logged the issue. Google have responded to it as follows:
David Newgas: For now try connecting from a GCE instance (including cloud shell) or using a GCE instance to proxy connections from your laptop.
I have updated the dashboard with some more information (although it may take a while for you to see it due to caching)
To be clear, this issue will only be affecting first generation instances.
I did not have enough 'points' to comment, so I'll have my say here.
I am having about exactly the same issue. About 10 days ago I connected fine to the Cloud SQL instance, and synced my db up. Yesterday I was going to push some updates etc. But I could not connect, even though I have changed nothing in respect to the database connection, except for the given IPv4.
I figured the issue was with my Django project, based on the App Engine Skeleton, so I created an issue on that project.
https://github.com/GoogleCloudPlatform/appengine-django-skeleton/issues/16
Maybe/Hopefully some we get some information from there.
I had the same problem.
By pure luck I said "Let's try to connect with my local MySQL client while the gcloud command was saying
"Whitelisting your IP for incoming connection for 5 minutes..."
and (mysql local client) worked.
I have multiple hosts that connect with a database on an Amazon RDS server. The normal webservers have no trouble connecting with the database, but today I discovered that my development server couldn't connect.
The error I get is
'ERROR 2003 (HY000): Can't connect to MySQL server on
'endpoint.blabla.rds.amazonaws.com' (113)'
Trying to connect via my home laptop gives no problems. It's only the devserver.
When I initiate a connection from the devserver via nc, it gives 'No route to host'. As far as I know, I didn't change anything on the devserver. The databaseserver however has been resized last Thursday, but I'm not sure when the problems have started. I know that it still worked two weeks ago, that's all.
Anyone any experienced this before with Amazon RDS? I really don't know where to look at the moment. The VPC security groups haven't changed, and other servers with the same security groups on the same VPC have no trouble connecting to the database.
Ok it is solved after a couple of hours searching. There was a route in my route table that caused the trouble. I have no idea how it got there, but it is solved now, I can reach the server again. :)
I am getting intermittent 'Connection Timed Out' errors when a php script on my web server connects to the MySQL database server over the private network. However, if I tell the script to use the public network to connect, these errors do not appear.
My connection script is setup so that whenever I try to connect to mysql, it checks for errors, if there is an error, it sends me an email then automatically switches to the public network to try that connection. If the public connection fails, it sends me another email and displays a custom web page to the user.
I get about 5 to 10 connection errors every hour. There are hundreds of successful connections every minute.
These machines are dedicated machines. I contacted our hosting company and they tested the routers and cables and said everything is fine. I tried pinging the servers both ways and there are no errors at all for test periods over an hour.
I am using the latest Nginx with the latest PHP and PHP-FPM. Mysql is 5.5.27. These are Centos 6 64bit systems with that latest updates.
I've tried many network configuration options, adjustments to php-fpm & mysql config file and no matter what I do or change, nothing fixes it.
The weird thing is, everything works great over the public network and pings and file transfer work great over the private network between both machines.
Any ideas?
** UPDATE **
I made some changes to the PHP-FPM config file and to the MySQL config file and the errors are now about 2 to 3 per hour but still unresolved.
I'm not sure this is your case but still worth mentioning as it helped me in a similar situation. Basically, there is a cap on max number of connections in linux kernel: https://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server
Not sure if it is shared between all the networks, but if you think it's worth checking I'd just raise those variable values say twice and see if it had any effect on how frequently the error happens.