I use JDBC to connect to MySQL. When it’s at localhost:3306, everything is OK.
But when I move my application to another computer in the intranet, and use <Intranet-IP>:3306 to connect to the MySQL database, it takes about 1 minute to connect to MySQL successfully. What’s up with this?
Well it could be a DNS problem. You can disable DNS host name lookups by starting mysqld with the --skip-name-resolve option in the configuration file.
Read here for more details: http://dev.mysql.com/doc/refman/5.0/en/host-cache.html
The --skip-name-resolve worked great for me.
To make it permanent, I just add this line at the end of file my.ini in the [mysql] section:
skip-name-resolve
And voilá! Transactions now fly!
For me it was this solution I found here, If IP6 connectivity is enabled, connection to "localhost" may be slow, instead use the ip address, 127.0.0.1. This worked for me.
my mysql slow to connect problem was solved by this solution
firewalls, Internet, routing etc etc slows down your connection.
You should put your database on a intra net instead. Keep it local and behind your big firewall. You can of course have firewall and security between computers. I'd recommend that you didn't expose your mysql database connection to the Internet unfiltered that way.
comment / finding to a really REALLY old question.
background - typical: connecting from windows (various) to sql server on win or linux server slow ... multiple seconds (even from win client on VBox to server on same host)
skip-name-resolve, dns-bind - tried all sorts, regardless no effect.
Looked at the manual - connection string options - no time to learn what they mean, one-by-one set-and-try - as long as nothing breaks.
adding sslmode=none; to connection string ... connecting in literally less than 1/10th the time. sub-second connections, milliseconds!
Note:
It's in a small office private LAN so don't GAS any security FUD
... It works ... I'll take it.
Related
I'm facing an issue that i'm stuck...
We've MySQL version 5.5.21 and we've detected recently some "unauthenticated users" appears and disappears in the processlist. The DNS server is well and responding fastly. Even that, we use IP address to set privileges for MySQL users.
To be sure, i've enabled skip-name-resolve option in the my.cnf file and restart the service. But, these requests still appear so i conclude there's something else to check but i don't know what after many investigations.
I've read that these requests can paralyzed all the TCP pool of MySQL, but in my case there's not this issue at the moment.
So, is it a beggining of dysfunctions in my MySQL server or is it just a normal behavior ?
Thanks for your help
Right now I am connecting to a cluster endpoint that I have set up for an Aurora DB-MySQL compatible cluster, and after I do a "failover" from the AWS console, my web application is unable to properly connect to the DB that should be writable.
My setup is like this:
Java Web App (tomcat8) with HikariCP as the connection pool, with ConnecterJ as the driver for MySQL. I am evaluating Aurora-MySQL to see if it will satisfy some of the needs the application has. The web app sits in an EC2 instance that is in the same VPC and SG as the Aurora-MySQL cluster. I am connecting through the cluster endpoint to get to the database.
After a failover, I would expect HikariCP to break connections (it does), and then attempt to reconnect (it does), however, the application must be connecting to the wrong server, because anytime a write is hit to the database, a SQL Exception is thrown that says:
The MySQL server is running with the --read-only option so it cannot execute this statement
What is the solution here? Should I rework my code to flush DNS after all connections go down, or after I start receiving this error, and then try to re-initiate connections after that? That doesn't seem right...
I don't know why I keep asking questions if I just answer them (I should really be more patient), but here's an answer in case anyone stumbles upon this in a Google search:
RDS uses DNS changes when working with the cluster endpoint to make it looks "seamless". Since the IP behind the hostname can change, if there is any sort of caching going on, then you can see pretty quickly how a change won't be reflected. Here's a page from AWS' docs that go into it a bit more: https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html
To resolve my issue, I went into the jvm's security file and then changed it to be 0 just to verify if what was happening was correct. Seems correct. Now I just need to figure out how to do it properly...
I'm running into a little trouble with MySQL Workbench.
This is the situation, I'm developing a database to query it remotely from Android devices. This is the first time I use MySQL Workbench, so I've followed this tutorial:
http://net.tutsplus.com/tutorials/databases/visual-database-creation-with-mysql-workbench/
I have no problem creating the EER diagram and generating the SQL script. The problem comes when I try to connect to a MySQL server. I get this error:
"Failed to Connect to MySQL at 127.0.0.1:3306 with user root. Lost connection to MySQL server at 'reading initial communication packet', system error: 61"
http://img101.imageshack.us/i/capturadepantalla201104i.png/ (if the link stops working tell me)
I've also tried using the Local Socket/Pipe connection method with the MAMP Socket in '/Applications/MAMP/tmp/mysql/mysql.sock', but it gives the same error. And I've also tried using MAMP port 8889 but still nothing.
So anyone knows how to fix it? And another question, can I connect from my Android device to my laptop(where the database is placed) without using MAMP? MySQL needs MAMP to serve queries? And the last thing, am I going into the right way? Or should I do it other way?
Thanks for reading.
I had the same issue, but part of your question is what fixed it for me:
Set connection = Local Socket/Pipe
Set socket path = "/Applications/MAMP/tmp/mysql/mysql.sock" (for me - I got the path from my MySQL log upon initialisation)
Running: MBP, OSX 10.8.3 (Mountain Lion), MAMP Pro
Can't really fathom any further what your issue may be, but perhaps double check your DB is properly initialised. But, perhaps this helps someone else :)
I typed: sudo /usr/local/mysql/support-files/mysql.server start
into the terminal and it started the MySQL server successfully and I was able to connect to MYSQL workbench.
You need to sure that Mysql process is running in your system. not sure in MAC but in windows it'called mysqld.exe
well take a look
http://lists.mysql.com/mysql/124371
Most commonly happens when database/server is not running. You need to check your server, or restart it. You can do so if you have mysql workbench under server administration. Check your manual for restarting or starting the server.
On osx 10.6 using mamp pro I solved this by allowing network access in the MySQL tab from the home window. Hope it saves someone the pain too
When trying to use the MySQL Workbench and connect through an SSH tunnel, you will get this error when your SSH connection does not complete successfully (e.g. improper host, password, key file, etc)
A good way to trouble shoot this is to separately test the the ssh connection from the machine you are trying to connect from and establish that you can do so successfully.
Try closing MySQL and running it as the admin. This worked for me.
After making above improvement such as checking if mysql service is running or not, you just need to give a small password while creating connection, it is ' ' or 1 time press on space-bar in case of GUI or workbench.
After which you just need to validate your machine with server (validated HOST).
For that purpose click on 'New Server Instance' and it will configure server/HOST on your behalf itself.
I have done this successfully just a few couple of minutes ago. My workbench software is able to show all pre-installed databases etc now.
Thanks!!!
I solved it! On a mac just go to spotlight search on the top right of the screen and type Mysql. Turn it on.
Having a bit of a problem with mysql...
Mysql 5.1 on windows 2008 server iis7
Site on windows 2003 server iis6
[sorry but can't move to linux kids! ;)]
In the process of shifting a site to a new server so I have moved the database 1st and connected the site to the new database. I tested the connection before moving but now the site is connecting to the new database I am having problems....
connecting via PDO the page hangs for an age before getting 'too many connections' error. Monitoring the server I see MANY threads of: 'unathenticated user' from the ip address of the host the site runs on.
I also see a thread for the connection with the correct user name in my config file and I am a total loss as to what is going on.
Any help would be very much appreciated
'unathenticated user' from the ip address of the host the site runs on
A stab in the dark, but this could be some script or process trying to connect to the database server with wrong or empty credentials.
Also, here's a report from somebody who had similar problems - in that case, it was the DNS lookup that caused the problem.
I had a similar situation on my setup where the database lived on a different host than
the webserver. I found the "unauthenticated users" were connections from the webserver
that were hanging on DNS lookups. Don't know if this is a mysql bug or a bug with my
firewall / other setup, but a couple of fixes I found were...
1) start mysql with --skip-name-resolve (you may have to change your mysql permission
tables to have the host's IP instead of hostname, including localhost)
or 2) add the connecting host to your /etc/hosts file.
I am facing connection failure to MySQL problem when I run my program for more than couple of days.MySQL Error Code is 2013 while connecting to Database. MySQL server and client programs are both on same machine. I am using FC5 as my OS and MySQL version is 5.0.18. Can anybody throw some light on this?
I am getting mysql error 2013 while calling mysql_real_connect()...
Any help is appreciated.
Try using localhost, instead of your own IP.
I don't know why, but this immediately fixed the problem for me.
I would be very grateful if someone could clarify
why this worked, all of a sudden.
Sounds like a firewall issue. Have you tried disabling the firewall temporarily?
Another possible solution involves edition the startup script as mentioned here and commenting out the following line:
SKIP=skip-networking
A third possible solution is mentioned here. The user tried to access an InnoDB database and InnoDB support was accidentially deactivated for the MySQL server.
(new) I found this official MySQL article which has lots of approaches to solve the problem. Did you modify the wait_timeout system variable?
Here's an answer you might not expect. I had encountered the same problem. MySQL Error 2013. Here are the symptoms:
PHPMyAdmin fired off 2013 and error 95.
I could shell into the MySQL monitor, but it took an inordinately long time to start. I could view tables and everything worked once the command line utility started
The server took a LONG time to stop and restart.
No errors in the MySQL error log.
I work with a good sysadmin who checked netstat -tn, which yielded the answer:
tcp 0 0 [my.srv.ip]:3306 184.73.87.215:59271 ESTABLISHED
tcp 0 1 [my.srv.ip]:38138 184.73.87.215:113 SYN_SENT
The IP resolves to Amazon Web Services. Some prick was leeching onto my 3306, even though everything but port 80 is allow-only. It's time to review my firewall rules.
There were no new tables, and mtop didn't show any activity, but I found a ton of these in the auth log:
Apr 19 15:14:52 magic2 mysqld[18953]: refused connect from ec2-184-73-87-215.compute-1.amazonaws.com
Apr 19 15:18:02 magic2 mysqld[18953]: refused connect from ec2-184-73-87-215.compute-1.amazonaws.com
After blocking the offending IP in iptables, the problem suddenly went away. Sneaky Bastards. The moral of this story is: What looks like bug, might be a hacker.
bz
Check your my.cnf. Set your bind-address to the server's IP address. Solved the issue for me. NO ONE seemed to know the answer to that one!
My fix was - change 'localhost' to '127.0.0.1'
It could be a network error that caused the TCP/IP connection to drop, or the wait_timeout was exceeded on the server; the latter can actually be useful in keeping the # of open connections down, but the app will then need to handle errorcode 2013 correctly!!