How to make mysql_install_db work? - mysql

I am new with MySql please help me out.
First to install MySql 5.5.7-rc i used this command->
sudo ./configure --prefix=/usr/local/mysql --with-plugin-partition --with-tcp-port=3308 --with-unix-socket-path=/tmp/mysql1.sock --with-debug
$sudo make
$sudo make install
Then when i am executing following command i am getting couple of errors.
$sudo ./mysql_install_db --datadir=/usr/local/mysql/data --basedir=/usr/local/mysql/ --user=mysql
ERROR:::
Installing MySQL system tables...
connect: Connection refused
Installation of system tables failed! Examine the logs in
/usr/local/mysql/data for more information.
You can try to start the mysqld daemon with:
shell> /usr/local/mysql//bin/mysqld --skip-grant &
and use the command line tool /usr/local/mysql//bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/mysql//bin/mysql -u root mysql
mysql> show tables
Try 'mysqld --help' if you have problems with paths. Using --log
gives you a log in /usr/local/mysql/data that may be helpful.
Please consult the MySQL manual section
'Problems running mysql_install_db', and the manual section that
describes problems on your OS. Another information source are the
MySQL email archives available at http://lists.mysql.com/.
Please check all of the above before mailing us! And remember, if
you do mail us, you MUST use the /usr/local/mysql//scripts/mysqlbug script!
Then i tried '/usr/local/mysql//bin/mysql -u root mysql' and i found
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
But /tmp/mysql.sock and /var/run/mysqld/mysqld.sock don't exist. I checked it...
Please give some suggestion to overcome this problem.
even mysqld service is not being started..

"connect: Connection refused" means the server's not listening where it's expected to; I understand that an answer a year late might be a bit too late but one should start with what the distribution provides or the official builds and not a self-made source build of an RC of a quite complex product in the first place.
Maybe those hitting this question will find the accepted answer to that one useful: bash:scripts/mysql_install_db: No such file or directory

Related

How do you start a MySQL server on linux?

Pretty simple question here. I just want a SQL database on my version of Kali linux so I can practice SQL.
I opened the command line and entered tried to start mysql and get an error.
> mysql -u root
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'
I also made sure it was already installed using apt-get.
What are the steps I need to take to be able to make a database with tables and data that I can query?
I don't know about Kali, but on Ubuntu it would be
$ sudo service mysql start
Once that command returns, the mysqld service has started, so you can use the mysql client to connect to it.
Of course, you also have to make sure you have the mysql-server package installed, not just mysql-client and mysql-common, and that you've initialized the database instance. Complete post-installation instructions can be found in the official documentation, but the short version is
Make sure the installer has created the mysql user account. This is the account that will "own" the server process once it starts.
Change to your data directory. (I used the installer's default of /var/lib/mysql; you can change this by editing my.cnf.)
As root, execute the server daemon with the --initialize switch. Check whereis to determine the correct path, then
$ sudo /path/to/mysqld --initialize --user=mysql
This command will twiddle itself for a while, then display an automatically-generated password and exit. Once the command returns, the database instance has been initialized and the system tables created. You can now start the database instance normally (using service start), then log in as the database user root (which is not the same as the system user root) using the password from above, then change your password, create a new database user, log in as that user, create a user database, and start creating tables.
Again, the official documentation is the place to look for this; if any of the instructions in the official documentation differ from my instructions, you should ignore me and follow the official documentation's instructions.
If sudo service mysql start doesn't work for you, please try running mysqld_safe and don't kill the process. Use another tab to check the status of mysql service. This should solve your mysqld.sock issue.
If it doesn't work out, then please edit your my.cnf file and add the following:
socket=/var/lib/mysql/mysql.sock
And the permissions,
sudo chmod -R 755 /var/lib/mysql/
Hopefully, this should do it.
On my version of kali (2022-rolling), even though it's installed as MySQL, it's run as mariadb. To start it is:
sudo /etc/init.d/mariadb start
Try this
sudo service mysql start

mysql wont start on Oracle Linux

I installed mysql following instructions on this link on my fresh installation of OEL 5. However when I try to start the mysql service with service mysqld start I keep getting
chown: `mysql:mysql': invalid user
chown: `mysql:mysql': invalid user
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
When I try to check user's information with id mysql I get user does not exist and when I try to add user, it says user already exists!
If I try to start mysql or ecen check its version for instance, I get:
[root#localhost ~]# mysql -v
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Worst part is there is no mysql.sock file on my whole file system. I confirmed it by firing find / -name mysql.sock which returned empty result.
AM I missing some configuration step or something? I am absolutely clueless. Can someone please help me with this?
Please, which of the corresponding linux distribution are you using ? have you try to run it in sudo mode: sudo service mysqld start ? To see if mysql user have been created run cat /etc/passwd | grep 'mysql' or cat /etc/passwd; normally; it special user for specific purpose (here mysql administration).

Table 'performance_schema.session_variables' doesn't exist

After upgrading MySQL to 5.7.8-rc
and loging to server I got error:
Table 'performance_schema.session_variables' doesn't exist
I can't find any solution for this. Can you help ?
I was able to log on to the mysql server after running the command #robregonm suggested:
mysql_upgrade -u root -p --force
A MySQL server restart is required.
The mysql_upgrade worked for me as well:
# mysql_upgrade -u root -p --force
# systemctl restart mysqld
Regards,
MSz.
mysql -u app -p
mysql> set ##global.show_compatibility_56=ON;
as per http://bugs.mysql.com/bug.php?id=78159 worked for me.
Since none of the answers above actually explain what happened, I decided to chime in and bring some more details to this issue.
Yes, the solution is to run the MySQL Upgrade command, as follows: mysql_upgrade -u root -p --force, but what happened?
The root cause for this issue is the corruption of performance_schema, which can be caused by:
Organic corruption (volumes going kaboom, engine bug, kernel driver issue etc)
Corruption during mysql Patch (it is not unheard to have this happen during a mysql patch, specially for major version upgrades)
A simple "drop database performance_schema" will obviously cause this issue, and it will present the same symptoms as if it was corrupted
This issue might have been present on your database even before the patch, but what happened on MySQL 5.7.8 specifically is that the flag show_compatibility_56 changed its default value from being turned ON by default, to OFF. This flag controls how the engine behaves on queries for setting and reading variables (session and global) on various MySQL Versions.
Because MySQL 5.7+ started to read and store these variables on performance_schema instead of on information_schema, this flag was introduced as ON for the first releases to reduce the blast radius of this change and to let users know about the change and get used to it.
OK, but why does the connection fail? Because depending on the driver you are using (and its configuration), it may end up running commands for every new connection initiated to the database (like show variables, for instance). Because one of these commands can try to access a corrupted performance_schema, the whole connection aborts before being fully initiated.
So, in summary, you may (it's impossible to tell now) have had performance_schema either missing or corrupted before patching. The patch to 5.7.8 then forced the engine to read your variables out of performance_schema (instead of information_schema, where it was reading it from because of the flag being turned ON). Since performance_schema was corrupted, the connections are failing.
Running MySQL upgrade is the best approach, despite the downtime. Turning the flag on is one option, but it comes with its own set of implications as it was pointed out on this thread already.
Both should work, but weight the consequences and know your choices :)
Follow these steps without -p :
mysql_upgrade -u root
systemctl restart mysqld
I had the same problem and it works!
As sixty4bit question, if your mysql root user looks to be misconfigured, try to install the configurator extension from mysql official source:
https://dev.mysql.com/downloads/repo/apt/
It will help you to set up a new root user password.
Make sure to update your repository (debian/ubuntu) :
apt-get update
If, while using the mysql_upgrade -u root -p --force command You get this error:
Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13
just add the sudo before the command. That worked for me, and I solved my problem. So, it's: sudo mysql_upgrade -u root -p --force :)
For my system the problem ended up being that I still had Mysql 5.6 installed and so the mysql_upgrade.exe from that installation was being called instead of the one for 5.7. Navigate to C:\Program Files\MySQL\MySQL Server 5.7\bin and run .\mysql_upgrade.exe -u root
sometimes mysql_upgrade -u root -p --force is not realy enough,
please refer to this question : Table 'performance_schema.session_variables' doesn't exist
according to it:
open cmd
cd [installation_path]\eds-binaries\dbserver\mysql5711x86x160420141510\bin
mysql_upgrade -u root -p --force

Can't connect to local MySQL server through socket homebrew

I recently tried installing MySQL with homebrew (brew install mysql) and when I try to run it I get the following error:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
There is no /tmp/mysql.sock nor a /var/lib/mysql.sock.
I've searched and haven't found any mysql.sock file.
How can I fix this?
When you got the server running via
mysql.server start
you should see the socket in /tmp/mysql.sock. However, the system seems to expect it in /var/mysql/mysql.sock. To fix this, you have to create a symlink in /var/mysql:
sudo mkdir /var/mysql
sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock
This solved it for me. Now my phpMyAdmin works happily with localhost and 127.0.0.1.
Credit goes to Henry
Warning, this will wipe your databases, take a backup if you wish to keep them
I had some directories left from another mysql(8.0) installation, that were not removed.
I solved this by doing the following:
First uninstall mysql
brew uninstall mysql#5.6
Delete the folders/files that were not removed
rm -rf /usr/local/var/mysql
rm /usr/local/etc/my.cnf
Reinstall mysql and link it
brew install mysql#5.6
brew link --force mysql#5.6
Enable and start the service
brew services start mysql#5.6
Looks like your mysql server is not started. I usually run the stop command and then start it again:
mysqld stop
mysql.server start
Same error, and this works for me.
Try to connect using "127.0.0.1" instead "localhost".
If you are able to see "mysql stopped" when you run below command;
brew services list
and if you are able to start mysql with below command;
mysql server start
this means; mysql is able to start manually, but it doesn't start automatically when the operating system is started. Adding mysql to services will fix this problem. To do so, you can run below command;
brew services start mysql
After that, you may restart your operating system and try connecting to mysql to see if it started automatically. I did the same and stop receiving below error;
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (2)
I hope this helps.
The file /tmp/mysql.sock is probably a Named-Pipe, since it's in a temporary folder. A named pipe is a Special-File that never gets permanently stored.
If we make two programs, and we want one program to send a message to another program, we could create a text file. We have one program write something in the text file and the other program read what our other program wrote. That's what a pipe is, except it doesn't write the file to our computer hard disk, IE doesn't permanently store the file (like we do when we create a file and save it.)
A Socket is the exact same as a Pipe. The difference is that Sockets are usually used over a network -- between computers. A Socket sends information to another computer, or receives information from another computer. Both Pipes and Sockets use a temporary file to share so that they can 'communicate'.
It's difficult to discern which one MySql is using in this case. Doesn't matter though.
The command mysql.server start should get the 'server' (program) running its infinite loop that will create that special-file and wait for changes (listen for writes).
After that, a common issue might be that the MySql program doesn't have permission to create a file on your machine, so you might have to give it root privileges
sudo mysql.server start
Since I spent quite some time trying to solve this and always came back to this page when looking for this error, I'll leave my solution here hoping that somebody saves the time I've lost. Although in my case I am using mariadb rather than MySql, you might still be able to adapt this solution to your needs.
My problem
is the same, but my setup is a bit different (mariadb instead of mysql):
Installed mariadb with homebrew
$ brew install mariadb
Started the daemon
$ brew services start mariadb
Tried to connect and got the above mentioned error
$ mysql -uroot
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
My solution
find out which my.cnf files are used by mysql (as suggested in this comment):
$ mysql --verbose --help | grep my.cnf
/usr/local/etc/my.cnf ~/.my.cnf
order of preference, my.cnf, $MYSQL_TCP_PORT,
check where the Unix socket file is running (almost as described here):
$ netstat -ln | grep mariadb
.... /usr/local/mariadb/data/mariadb.sock
(you might want to grep mysql instead of mariadb)
Add the socket file you found to ~/.my.cnf (create the file if necessary)(assuming ~/.my.cnf was listed when running the mysql --verbose ...-command from above):
[client]
socket = /usr/local/mariadb/data/mariadb.sock
Restart your mariadb:
$ brew services restart mariadb
After this I could run mysql and got:
$ mysql -uroot
ERROR 1698 (28000): Access denied for user 'root'#'localhost'
So I run the command with superuser privileges instead and after entering my password I got:
$ sudo mysql -uroot
MariaDB [(none)]>
Notes:
I'm not quite sure about the groups where you have to add the socket, first I had it [client-server] but then I figured [client] should be enough. So I changed it and it still works.
When running mariadb_config | grep socket I get:
--socket [/tmp/mysql.sock]
which is a bit confusing since it seems that /usr/local/mariadb/data/mariadb.sock is the actual place (at least on my machine)
I wonder where I can configure the /usr/local/mariadb/data/mariadb.sock to actually be /tmp/mysql.sockso I can use the default settings instead of having to edit my .my.cnf (but I'm too tired now to figure that out...)
At some point I also did things mentioned in other answers before coming up with this.
After installing macos mojave, had to wipe mysql folder under /usr/local/var/mysql and then reinstall via brew install mysql otherwise permission related things would come up all over the place.
In my case, the culprit was found in the logfiles:
$ tail /usr/local/var/mysql/<hostname>.lan.err
2019-09-19 7:32:21 0 [ERROR] InnoDB: redo log file './ib_logfile0' exists. Creating system tablespace with existing redo log files is not recommended. Please delete all redo log files before creating new system tablespace.
2019-09-19 7:32:21 0 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again.
So I renamed ib_logfile0 to get rid of the error (I had to do the same with ib_logfile1 afterwards).
mv /usr/local/var/mysql/ib_logfile0 /usr/local/var/mysql/ib_logfile0_bak
mv /usr/local/var/mysql/ib_logfile1 /usr/local/var/mysql/ib_logfile1_bak
brew services restart mariadb
I got the same error and this is what helped me:
$ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents
$launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
$mysql -uroot
mysql>
I faced the same problem on my mac and solved it, by following the following tutorials
https://mariadb.com/resources/blog/installing-mariadb-10116-mac-os-x-homebrew
But don't forget to kill or uninstall the old version before continuing.
Commands:
brew uninstall mariadb
xcode-select --install
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" - See more at: https://mariadb.com/resources/blog/installing-mariadb-10116-mac-os-x-homebrew#sthash.XQoxRoJp.dpuf
brew doctor
brew update
brew info mariadb
brew install mariadb
mysql_install_db
mysql.server start
Just to add to these answers, In my case I had no local mySQL server, it was running inside a docker container. So the socket file does not exist and will not be accessible for the "mysql" client.
The sock file gets created by mysqld and mysql uses this to communicate with it.
However if your mySql server is not running local, it does not require the sock file.
By specifying a host name/ip the sock file is not required e.g.
mysql --host=127.0.0.1 --port=3306 --user=xyz --password=xyz
If "mysqld" IS running, it's possible your data is corrupted. Try running this:
mysqld
Read through the wall of data, and check if mysqld is reporting that the database is corrupted. Corruption can present in many unintuitive ways:
mysql -uroot returns "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)".
mysql.server start returns "ERROR! The server quit without updating PID".
Sequel Pro and MySQL Workbench responds that they can't connect to MySQL on localhost or 127.0.0.1.
To recover your data, open my.cnf and add the following line in the [mysqld] section:
innodb_force_recovery=1
Restart mysqld:
$ brew services restart mysql#5.6
Now you can connect to it, but it’s in limited read-only mode.
If you're using InnoDB, run this to export all your data:
$ mysqldump -u root -p --all-databases --add-drop-database --add-drop-table > data-recovery.sql
The file is created in your ~ dir. It may take some time.
Once finished, remove innodb_force_recovery=1 from my.cnf, then restart mysql in normal mode:
$ brew services restart mysql#5.6
Drop all the databases. I did this using Sequel Pro. This deletes all your original data. Make sure your data-recovery.sql looks good before doing this. Also consider backing up /usr/local/var/mysql to be extra careful.
Then restore the databases, tables, and data with this:
$ mysql -uroot < ~/data-recovery.sql
This can be a long import/restoration process. Once complete, you’re good to go!
Thanks go to https://severalnines.com/database-blog/my-mysql-database-corrupted-what-do-i-do-now for the recovery instructions. The link has further instructions on MyISAM recovery.
You'll need to run mysql_install_db - easiest way is if you're in the install directory:
$ cd /usr/local/Cellar/mysql/<version>/
$ mysql_install_db
Alternatively, you can feed mysql_install_db a basedir parameter like the following:
$ mysql_install_db --basedir="$(brew --prefix mysql)"
After a restart I could not connect with the local mariadb, a search also brought me to this page and I wanted to share my solution with you.
I noticed that the directory my.cnf.d in /usr/local/etc/ is missing.
This is a known bug with homebrew that is described and solved there. https://github.com/Homebrew/homebrew-core/issues/36801
fast way to fix: mkdir /usr/local/etc/my.cnf.d
When running mysql_secure_installation and entering the new password I got:
Error: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (2)
I noticed when trying the following from this answer:
netstat -ln | grep mysql
It didn't return anything, and I took that to mean that there wasn't a .sock file.
So, I added the following to my my.cnf file (either in /etc/my.cnf or in my case, /usr/local/etc/my.cnf).
Under:
[mysqld]
socket=/tmp/mysql.sock
Under:
[client]
socket=/tmp/mysql.sock
This was based on this post.
Then stop/start mysql again and retried mysql_secure_installation which finally let me enter my new root password and continue with other setup preferences.
This works for me:
brew upgrade mysql
If brew does not complete "postinstall"
I only have to use:
sudo chown -R $(whoami) /usr/local/*
then completed postinstall by:
brew postinstall mysql#5.7
next step just start mysql#5.7 service.
It worked for me on MacOS Monterey.
I also ran into this... it seemingly resulted from some leftover artifacts of multiple mysql installs on my dev machine. Every time I attempted to start or restart the mysql service it would crash. Ultimately, working through the err file helped me solve my issue.
Setup:
M1 Macbook Pro running OS 12 (Monterey)
Homebrew install of mysql#5.7
At various points during troubleshooting I tried uninstalling everything mysql in my Homebrew list, deleting /opt/homebrew/var/mysql, and reinstalling mysql#5.7 to no avail. I also tried restarting my machine.
I was able to validate what was happening when the service failed to start by reviewing the err (e.g., MyComputerName.local.err) log that it was spitting out into /opt/homebrew/var/mysql/ when I tried to start/restart the service via Homebrew. In the beginning, I was seeing things like this that pointed to issues with the config:
mysqld: Table 'mysql.plugin' doesn't exist
TIMESTAMPZ 0 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
TIMESTAMPZ 0 [ERROR] unknown variable 'mysqlx-bind-address=127.0.0.1'
TIMESTAMPZ 0 [ERROR] Aborting
I deleted my.cnf and my.cnf.default in /opt/homebrew/etc and attempted to start the service again. Then, the failure changed to this:
TIMESTAMPZ 0 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
TIMESTAMPZ 0 [ERROR] Fatal error: Failed to initialize ACL/grant/time zones structures or failed to remove temporary table files.
TIMESTAMPZ 0 [ERROR] Aborting
At this point I noticed several mysql lock files in /opt/homebrew/var/homebrew/locks/ (mysql.formula.lock, mysql.formula#5.7.lock, mysql.formula#8.0.lock); I deleted those files, as well as anything mysql in /opt/homebrew/var/homebrew/linked.
After that, I was able to start mysql without any issues.
just to complete this thread.
therefore MAMP (PRO) is used pretty often
the path here is
/Applications/MAMP/tmp/mysql/mysql.sock
I manually started mysql in the system preferences pane by initialising the database and then starting it. This solved my problem.
I had same problem. After trying all these methods without success I did the following:
tail -f the-mysql-or-maria-db-error-file.err
in another console:
brew services restart mariadb
I saw the following error:
"MAC HOMEBREW Crash recovery failed. Either correct the problem (if
it's, for example, out of memory error) and restart, or delete tc log
and start mysqld with"
So I changed the tc.log extesion to tc.log.txt and restart mariadb
brew services restart mariadb
and done!
[LINUX]
Though answer is expected to be for MacOS only but in Linux we may face the same Error.
I was facing the same issue in Linux. I ran this command:
sudo /etc/init.d/mysql.server start
and I was able to run the MySQL server
Ref. https://gist.github.com/vinodpandey/1a4b5b8228f9a000ca236820185fc3bc
I just ran into this problem, I did some tricks but for me it didn't work. If you used macOS, here is what I did. We start by uninstalling mysql and then reinstalling it.
brew uninstall mysql
brew install mysql
Note: you must have homebrew installed
This happened to me today 2023-02-23 after a homebrew update.
Homebrew had created a new my.cnf.default file, I backed up my old one and replaced it with this new default and restarted Mariadb and everything worked including the old root password.
For me, I had installed mariadb long time ago, then installed mysql#5.7.
When I executed mysql -uroot, I get the error:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Reading the answers:
I uninstalled mariadb
Deleted the folder /usr/local/var/mysql
Ran the command mysqld --initialize
Then I was able to mysql -uroot -p

Mysql through PHP gives a "Can't create/write to file" error

The full error is:
Message: Mysqli statement execute
error : Can't create/write to file
'/var/www/zendApp/backup/mysql/1268733580_name.sql'
(Errcode: 13)
I have tried several things already with the /var/www/ZendApp/backup/mysql directory
$chmod 777 mysql
$chmod 1777 mysql
$chown root:root mysql
$chown mysql:mysql mysql
But nothing helps. What am I doing wrong here? Do I have to tell mysql somewhere that I can write to that directory?
With the help off Dominik # Super User, I discovered that Ubuntu is running apparmor and my server is running on Ubuntu. I quote from wikipedia:
AppArmor allows the system
administrator to associate with each
program a security profile that
restricts the capabilities of that
program
Sure enough, among those programs was mysqld. So not the user or his privileges are the problem, but the restrictions imposed on the process by apparmor. I then found the solution here
sudo touch /etc/apparmod.d/disable/usr.sbin.mysqld
sudo /etc/init.d/apparmor reload
This makes mysqld a free process which for me, on that server, is no problem. So, after days of searching, problem fixed!