I'm trying to connect to a MySQL server running on my Raspberry Pi 3 remotely (though on the same LAN).
Attempting to do so through HeidiSQL returns an error coded 10061. A bit of research suggests I have to edit the config to allow remote connections.
The config, however, does not contain a bind-adress x.x.x.x line (/etc/mysql/my.cnf) for my to comment out. Added it myself breaks the service, causing errors when trying to restart it.
Checking other possible config file locations resulted in only empty files.
Additionally, comparing to the "default" config file, mine is a lot shorter, and has no actual statements, other than a few includes for other config files (it seems). These included files are all empty as well.
I'm now lost, and cannot figure out how to allow remote connections to my server. Any help is much appreciated :)
Thanks to #PetervanderWal, I suspected that the lack of a bind-address statement in the config was no freak coincidence. Therefore, I did a grep search for any files containing "bind-address", and found the correct configuration file: /etc/mysql/mariadb.conf.d/50-server.cnf. This file had the ´bind-address´ statement, which - after commenting it out - fixed the problem.
The takeaway here (if you ask me) is, if none of your config files contain the bind-address statement, widen your search for the correct config file.
Thanks Peter, hope this helps others.
Related
So I am going crazy with this. I have MAMP installed and it's MySQL is working fine. I now installed MySQL 5.7.19 from the official dmg from their site and installed.
From the pref panel I am not getting status updates and as such I cannot stop it even though it is running. Trivial though as I can launctl unload it.
However, the big issue I am facing is that although the server starts correctly (from pref panel) and I can see the process running and the respective /tmp/mysql.sock file when I try to run mysql in terminal (or any other mysql command) I get an error stating it cant find the sock file and it pipes out the Applications/MAMP path.
I looked everywhere for a my.cnf that might be setting this and there are none (apart from the one used by MAMP). No environment variables set to override it, nothing. In fact, there are no other my.cnf files but for some reason it still thinks it should be using /Applications/MAMP path.
my_print_defaults client confirms this as it pipes out
--socket=/Applications/MAMP/tmp/mysql/mysql.sock
but I have absolutely no idea where and how this is being set and I need to be able to run on this instance terminal commands. Driving me crazy for hours now.
No files at
/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf
No environment variable MYSQL_UNIX_PORT as described here: https://dev.mysql.com/doc/refman/5.7/en/problems-with-mysql-sock.html
So how the heck is it getting this value?
Also checked at DATA_DIR and BASE_DIR, no my.cnf there either.
Obviously Ive done which mysql to confirm I am calling the correct binary.
Any help much appreciated!
UPDATE Running my_print_defaults client --verbose --no-defaults pipes the same exact output, so I am guessing it is somehow set elsewhere. Where can this variable be set otherwise?
Ok so I found the answer after all and sharing it for anyone having the same issue.
In essence, the --socket parameter is added via the ~/.mylogin.cnf file!
I am not sure if I ever added it there but I am pretty sure it wasn't me, so I am guessing MAMP did it.
This is an encrypted file so you can't edit it directly by you can change it via mysql_config_editor:
mysql_config_editor remove --socket
And problem solved!
I have a set of executables (specifically BOINC server executables, but I don't think it matters) that I am trying to run on an Ubuntu 16.04 system. These executables were built on a different machine and use a version of the MySQL client library that was built on a RHEL 6.6 box (the release plan is to build everything on the RHEL 6.6 box and deploy it together, but the current executables were not built there).
The RHEL 6.6 box is configured to put its MySQL socket file at /var/lib/mysql/mysql.sock.
The Ubuntu 16.04 box is configured to put its MySQL socket file at /var/run/mysqld/mysqld.sock.
When I try to run one of the executables that connects to the database on the Ubuntu 16.04 box, I get the following error:
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'
The error comes straight out of the mysql_real_connect function. Only these executables give me that error. The mysql commend works fine. mysql_config --socket returns /var/run/mysqld/mysqld.sock, just as I expect it to.
I have tried all the suggestions I could find about editing the config files. I have added both a ~/.my.cnf file and a /etc/mysql/mysql.conf.d/client_socket.cnf file that specify the socket file location in a [client] section, per all the other sources for dealing with socket file locations. None of it changed the behavior of the executables; they always look for /var/lib/mysql/mysql.sock as if something were hard-coded to do it. I can't find anything that is, though.
I have been beating my head against this problem for a while, and I cannot figure out what is going on. I ended up opening up the permissions on /var/lib/mysql and symlinking the real socket file to the expected location, but that feels like a hack. What is going on here? Why are my executables seemingly ignoring all MySQL system configuration? What is the proper way to fix this? Could this actually be hard-coded somewhere?
I just searched the BOINC source tree and tend to think that it is not hard code in the literal sense of the word but it is fixed at compilation time. See
https://github.com/BOINC/boinc/search?utf8=%E2%9C%93&q=mysql&type=
The proper fix to me is to either compile the BOINC source tree yourself on your machine, to use the cloud images prepared by the BOINC developers https://boinc.berkeley.edu/trac/wiki/CloudServer or to look at the instructions on wiki.debian.org/BOINC, of which I am unsure about how well this adapts to Ubuntu.
I'm running a Windows 2008 Server with IIS, PHP and MySQL. MySQL is installed as a service. There's software on the server that uses a database that I need good backups of, including transaction logging. I've turned on Binary Logging via setting log-bin= and expire_logs_days= in the my.ini file. This saves those logs in the MySQL data folder on that drive. If I lose the drive, I lose my logs and they've done me no good as a backup.
I've found all kinds of advice for relocating these logs on a Linux box, but trying to use the same idea of including a path in the log-bin statement is not working. I've tried "flipping" the slashes, adding quotes and the common other attempts when "translating" Linux to Windows.
I created a mapped drive to the external location to make this easier, and I've tried using \server\folder path statements as well as z:\ path statements.
Any help would be greatly appreciated.
If you made your changes in the [mysqld] section in the my.ini file then you should be good. The correct path naming convention, should look something like this log-bin="C:/yourfilepathname/logs". Since you are still experiencing issues, Please check to make sure that mysql has permission to write to the directory that you are specify the logs files to be written to.
Another way you can check if this is the issue, go to your .err log file when you try to stop and start mysql server it will tell you something along the lines of not having permission to write to that directory.
Also, I would note that log bin files in it of themselves are not a backup. You need to be taking mysqldumps or snapshots of the entire directory from your server, preferably from a slave of your master production server.
You are missing a trailing slash.
Here is what's in my my.ini (I'm using MariaDB 10.1, but I believe this will work for you also):
[mysqld]
datadir=D:/mysql-data
log-bin=E:/mysql-bin/
When I left out the trailing slash in the log-bin setting, I also got the same error in logs, and the service failed to start. After adding the slash, no errors, and the service started successfully.
I now see files getting created in E:\mysql-bin, such as .index, .000001.
make sure you are ending with filename. see below.
log-bin=C:/Program Files/MySQL/MySQL Server 5.6/data/bin.log
Actually it's due to using the normal windows backslashes. Instead of z:\ use z:/ (forward slash). Also if you don't end with a forward slash then it will use the last part as the file name. Exp:
z:/bin-logs/ (this will have files named .index and .000001)
z:/bin-logs/log (this will have files named log.index and log.000001)
I am having trouble connecting MySQL Workbench to MAMP. I am using version MySQL Workbench version 6.0 and MAMP version 3.0.3.
I have followed the instructions on this link: http://www.rubberneckdesigns.com/mamp/how-to-set-up-mysql-workbench-for-a-mamp-server/comment-page-1/#comment-6539 (this is just basic instructions to setting up MySQL Workbench with MAMP so no need to look through if you are familiar with the set up steps)
It all goes okay until the step were I have to select the Configuration File as:
/Applications/MAMP/tmp/mysql/mysql.sock
This file does not appear to be in this location or anywhere else on my computer.
In the answer to this link: Database connection "Mysql" is missing and mysql.sock is missing, he says he managed to figure out that his mysql.sock file was actually hidden, however I have my Mac set to display hidden files and I can see all my other hidden files, but still no sign of this file. He said after finding it was hidden he went to his database configuration file and added the following:
'unix_socket' => '/Applications/MAMP/tmp/mysql/mysql.sock'
Does anyone know what file he is referring to when he says database configuration file? I have tried figuring it out using Google but no luck. I am new to MAMP and new to MySQL Workbench.
This problem with the mysql.sock file, seems to be a problem for a lot of people. If anyone has a better solution than adding the above command to the database configuration file or can shed some light on this problem I would love to hear it.
Thanks
I have not been able to figure out where the mysql.sock file is, Mike Lischke has left a comment saying the socket file is created dynamically when you open a connection, which could be the case, but I do not know much about MySQL and the files so I can not confirm if this is correct, however, I have found the solution to my problem.
The overall problem was that I could not connect MySQLWorkbench to my Local Server (MAMP) as I could not find the mysql.sock file. When I tried to connect I was getting an error message saying it could not find the mysql.sock file.
The solution to my problem was to instead of setting the 'Hostname' in the MySQLWorkbench set up window as 'localhost', which is suggested in the guide I followed, I instead set it to the IP '127.0.0.1'. I then set the 'Connection Method' to 'Standard (TCP/IP)' instead of 'Local Socket/Pipe'. I believe what this is doing is setting it up to connect through the IP rather than the Socket, meaning the mysql.sock file is no long necessary.
This is a very simple solution and in hindsight it makes sense and I probably should have known this from the start, however because I am new to MySQL I didn't. If anyone else is having a similar problem connecting, I hope this helps.
This is a Duplicate to this question. But the given answer did not solved my problem. I have mysql installed which is accessed from other computers in the network with my ipaddress/phpmyadmin.
I also added line skip_name_resolve=1 to my my.ini file but this also din't worked. I cannot even take backup now.
I installed mysql on another pc and copied the databases from xampp/mysql/data from previous mysql folder. But the database does not has all the tables. Plz suggest something to resolve the problem or if there is any way i can take backup.
The error you are getting is a problem with resolving the hostname given for the MySQL connection string. Check your DNS entry for the host in question, modify your /etc/hosts to statically point to it, etc
Also this isn't a question of programming, rather of system, so...