I am running a MariaDB server on my Ubuntu machine mysql Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2. When trying to create a new table in a custom datadir with DATA DIRECTORY='/home/myuser/ext', the MySQL error log tells me
7f70acb77700 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
mysqld is running as mysql user:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30450 mysql 20 0 695572 206208 16432 S 0,0 1,3 0:43.48 mysqld
data directory is owned by mysql user:
$ ls -l
drwxr-xr-x 4 mysql mysql 4096 Feb 13 11:16 ext
ownership and permissons on original datadir:
$ ll /var/lib/mysql/
total 1355856
drwxr-xr-x 7 mysql mysql 4096 Feb 13 12:00 ./
apparmor apparently is not intefering. content of /etc/apparmor.d/usr.sbin.mysqld
# This file is intensionally empty to disable apparmor by default for newer
# versions of MariaDB, while providing seamless upgrade from older versions
# and from mysql, where apparmor is used.
#
# By default, we do not want to have any apparmor profile for the MariaDB
# server. It does not provide much useful functionality/security, and causes
# several problems for users who often are not even aware that apparmor
# exists and runs on their system.
#
# Users can modify and maintain their own profile, and in this case it will
# be used.
#
# When upgrading from previous version, users who modified the profile
# will be promptet to keep or discard it, while for default installs
# we will automatically disable the profile.
/etc/apparmor.d/local/usr.sbin.mysqld is nonexistent.
I am out of ideas here... What else could it be?
Related
I updated my Linode server from Debian 8 to 11, and this has caused multiple issues. I'm aware this was a very silly thing to do, and I didn't even have any real backup strategy.
But anyway, I'm setting up a new Linode and trying to migrate everything over. I need to get a backup of my MySQL database, but when I try to access MySQL, I get the following error:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
This command:
sudo find / -type s | grep mysql
returns nothing. So it looks like there is no socket file present. I have confirmed that MySQL is in fact running, by entering:
systemctl status mysql
The output is:
? mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql; generated)
Active: active (exited) since Thu 2021-12-02 14:25:19 GMT; 18min ago
Docs: man:systemd-sysv-generator(8)
Process: 2643 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCC>
CPU: 2ms
Dec 02 14:25:19 odaiba systemd[1]: Starting LSB: Start and stop the mysql datab>
Dec 02 14:25:19 odaiba systemd[1]: Started LSB: Start and stop the mysql databa>
lines 1-9/9 (END)
I ran this command:
cat /etc/mysql/my.cnf
which returned the following output:
# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 0. "/etc/mysql/my.cnf" symlinks to this file, reason why all the rest is read.
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# If you are new to MariaDB, check out https://mariadb.com/kb/en/basic-mariadb-/
#
# This group is read both by the client and the server
# use it for options that affect everything
#
[client-server]
# Port or socket location where to connect
# port = 3306
socket = /run/mysqld/mysqld.sock
# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
There is no /run/mysqld directory. I created it, and restarted MySQL, but this seemed to make no difference. I'm not sure how to set this my.cnf file to properly define or create the socket.
I'm also a little confused about all the references to MariaDB. Could that be something to do with the issue?
Any help at all is hugely appreciated!!
I've successfully configured my Ubuntu server so MySQL can use hugepages. Problem is when I want to enable memlock option in my.cnf and /proc/sys/vm/hugetlb_shm_group is set to another group (MySQL is a member of this group).
# uname -a
Linux hostname 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:51:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# mysqld --version
mysqld Ver 5.5.53-0ubuntu0.12.04.1 for debian-linux-gnu on x86_64 ((Ubuntu))
# egrep ^Huge /proc/meminfo
HugePages_Total: 15000
HugePages_Free: 15000
HugePages_Rsvd: 0
HugePages_Surp: 0
# id mysql
uid=107(mysql) gid=113(mysql) groups=113(mysql),117(hugetlb)
If /proc/sys/vm/hugetlb_shm_group is set to 113 everything goes well no matter of memlock option.
But if I set /proc/sys/vm/hugetlb_shm_group to 117 it works only without the memlock option. If I enable it I get this error when MySQL starts:
InnoDB: HugeTLB: Warning: Failed to allocate 21978152960 bytes. errno 1
InnoDB HugeTLB: Warning: Using conventional memory pool
Any idea what can be wrong?
Turned out to be a problem with ulimit. Settings in /etc/security/limits.conf are ignored so I got it working with simple edit in /etc/init/mysql.conf:
exec /usr/bin/mysqld
changed to
script
ulimit -l unlimited
/usr/bin/mysqld
end script
I am able to connect to mysql database and query it. But, I am NOT able to find the socket file.
$ps -ef|grep mysql
mysql 31408 30874 0 18:46 pts/1 00:00:00 /bin/sh /usr/bin/mysqld_safe --defaults-file=/mysql/admin/ofile/TEST1.cnf
mysql 31959 31408 0 18:46 pts/1 00:00:01 /usr/sbin/mysqld --defaults- file=/mysql/admin/ofile/TEST1.cnf --basedir=/usr -- datadir=/mysql01data/TEST1/data --plugin-dir=/usr/lib64/mysql/plugin --log- error=/mysql/admin/TEST1/errors/mysqld_safe.err --pid- file=/mysql/admin/TEST1/run/mysqld_safe.pid
Here is my socket file entry in TEST1.cnf:
$ cat /mysql/admin/ofile/TEST1.cnf|grep sock
socket = /mysql/admin/TEST1/run/TEST1.sock
The corresponding directory only contains pid file. There is no socket file.
-sh-4.1$ cd /mysql/admin/TEST1/run
-sh-4.1$ ls -lrt
total 4
-rw-rw---- 1 mysql mysql 6 Apr 29 18:46 mysqld_safe.pid
This is the MySQL 5.6 version I installed through RPM's on RHEL 6.5. I have my old custom scripts which uses socket file to connect to the database.
So, I am wondering how I can use the socket file to connect to the database? Why the socket file is not created by default?
The socket file for a running instance of MySQL Server should be something that can be found with this shell command:
sudo lsof -a -U -p $(pgrep -d, -f /path/to/your/running/mysqld)
One possible cause of being unable to find the socket file would be if it had been deleted after the server was started. In that case the above command should work, and show something like (deleted) after the path.
That was my original assumption on this question... but here the issue was a configuration oversight. The "defaults file," commonly called my.cnf contains multiple sections. The [client] section configures client utilities, like mysql and mysqldump, while the [mysqld] section configures the server daemon. If the socket directive isn't in the appropriate section, the server (and/or client utilities) will look in the location compiled in by default, with /tmp/mysql.sock or /var/lib/mysql/mysql.sock being a couple of examples of common default locations.
Trying backup with Percona Xtrabackup
I tried to use Percona Xtrabackup to backup all InnoDB databases in my MySQL data directory.
After executing the following command:
innobackupex --host=127.0.0.1 --port=3306 --user root --password PASSWD --defaults-file=/path/to/my.cnf --slave-info /backup/xtrabackup
The process seemed to be completed with the following log:
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.
...
innobackupex: Using mysql server version 5.6.12
innobackupex: Created backup directory /nobackup/xtrabackup/2014-02-24_00-04-21
...
[01] Copying /var/lib/mysql/ibdata1 to /nobackup/xtrabackup/2014-02-24_00-04-21/ibdata1
>> log scanned up to (178807644573)
....
140224 00:05:34 innobackupex: completed OK!
Result
However, the result is too small compared to original database files:
# Source database
# du -sm /var/lib/mysql/
19G /var/lib/mysql/
# Xtrabackup result
# du -sm /nobackup/xtrabackup
455M /nobackup/xtrabackup
Can Xtrabackup handle databases with innodb_file_per_table?
My InnoDB configuration (in /path/to/my.cnf) are as following:
innodb_file_per_table
innodb_file_format=Barracuda
Looking at the execution log, it shows the program only copied ibdata1 but not other many *.idb files.
I wonder if Xtrabackup cannot handle databases stored with innodb_file_per_table. I couldn’t find any hints in its documentation.
Is that true, or any solutions/ideas?
edit 1: The result seems not to be compressed
# find /nobackup/xtrabackup
/nobackup/xtrabackup
/nobackup/xtrabackup/2014-02-24_00-04-21
/nobackup/xtrabackup/2014-02-24_00-04-21/xtrabackup_logfile
/nobackup/xtrabackup/2014-02-24_00-04-21/ibdata1
/nobackup/xtrabackup/2014-02-24_00-04-21/xtrabackup_checkpoints
/nobackup/xtrabackup/2014-02-24_00-04-21/backup-my.cnf
/nobackup/xtrabackup/2014-02-24_00-04-21/2014-02-24_00-04-21
/nobackup/xtrabackup/2014-02-24_00-04-21/xtrabackup_binary
I found it.
my.cnf file did not contain datadir= configuration directive. I had passed --datadir option to the mysqld program instead of putting it on my.cnf.
This issue has been solved by just adding datadir= configuration to my.cnf.
I've installed MySQL on my personal/development machine using the .dmg package, according to the instructions here: http://dev.mysql.com/doc/refman/5.5/en/macosx-installation-pkg.html including installing the startup item and the preferences pane. And yet, I can't seem to use MySQL at all.
running:
/Library/StartupItems/MySQLCOM/MySQLCOM start
or
/Library/StartupItems/MySQLCOM/MySQLCOM restart
"appears" to work -- in that, it gives me a message like "Starting MySQL database server" -- but afterward, I still can't go into mysql at the command-line, or connect to it in a Rails 2.3.8 application running in script/server. I get the error denoted in the question title.
Also, the MySQL preferences pane doesn't seem to work either. If I click the "Start MySQL Server" button, I'm asked for my password, but then nothing happens -- the pane continues to say that the server is stopped.
(I believe I had a MacPorts version of MySQL installed previously, and it's also possible that there was one built from source at some time in the past -- but I'm reasonably sure I've uninstalled these and deleted all the files having to do with it that I could find.)
I'm also trying mysqld start in terminal. here's the output:
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110127 15:40:28 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
110127 15:40:28 InnoDB: Initializing buffer pool, size = 128.0M
110127 15:40:28 InnoDB: Completed initialization of buffer pool
110127 15:40:28 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Tried following the message about running mysql_upgrade but that just gives me my original error again.
UPDATE:
OK I've been pursuing the theory that it's a permissions problem. Seeing that the datadir was owned by root, I chown -R it to _mysql. In response to Mike, here's where that now stands:
$ ls -al /usr/local/mysql-5.5.8-osx10.6-x86_64
total 296
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 .
drwxrwxr-x 12 root staff 408 Jan 27 14:38 ..
-rw-r--r-- 1 root wheel 17987 Dec 3 11:58 COPYING
-rw-r--r-- 1 root wheel 12388 Dec 3 11:58 INSTALL-BINARY
-rw-r--r-- 1 root wheel 113534 Dec 3 11:58 README
drwxr-xr-x 44 root wheel 1496 Dec 3 12:53 bin
drwxr-xr-x 9 _mysql wheel 306 Jan 27 16:46 data
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 docs
drwxr-xr-x 47 root wheel 1598 Dec 3 12:53 include
drwxr-xr-x 12 root wheel 408 Jan 27 14:38 lib
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 man
drwxr-xr-x 19 root wheel 646 Jan 27 14:38 mysql-test
drwxr-xr-x 3 root wheel 102 Dec 3 12:53 scripts
drwxr-xr-x 32 root wheel 1088 Dec 3 12:53 share
drwxr-xr-x 28 root wheel 952 Dec 3 12:53 sql-bench
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 support-files
I was trying to do mysqld start in the Terminal because it was the only thing giving me anything that seemed like meaningful error message output (see https://gist.github.com/799436) but I'm told by folks in #mysql that that's not intended to be run directly (and if I try sudo mysqld start i get a message bitching me out for trying to run mysql as root).
I seem to have something working now: mysqld_safe & successfully gets a MySQL server running. What still doesn't work is the "normal" method of starting up the server (the Startup Item or Preferences Pane)
... leading someone in #mysql to tell me that apparently MySQL is fine, it's the startup item that's borked.
Ok there were several things, mostly having to do with permissions/ownership, that were tried to make the binary-installed MySQL work nicely.
You may need to make sure that the startup item is owned by root:
sudo chown -R root:wheel /Library/StartupItems/MySQLCOM
Maybe you need a /etc/my.cnf file with this in it:
[mysqld]
socket=/tmp/mysql.sock
datadir=/usr/local/mysql/data
You might need to fill in these variables in /usr/local/mysql/support-files/mysql.server (the line will be there with blank values):
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
(see can't start MySql in Mac OS 10.6 Snow Leopard regarding the above)
That may be enough to do it, but if not, try making sure the mysql user (_mysql) can write to the data directory (owns it and has write permissions to everything in it).
Anyway, now the Preferences Panel and Startup Item actually seem to work for me.
After going over this a second time on another machine, I've made some edits and removed some unnecessary bit from what I answered yesterday.
Overall here's what I suggest you do to get the binary-installed MySQL working nice in OSX 10.6. Warning, you might end up deleting any databases you already had in the first couple steps, but as this is intended to be for your development machine, that shouldn't be any big deal. Back stuff up with mysqldump first if you must.
Make sure you don't have a mysql server running right now: ps aux | grep mysql will show you their processes. Stop it with mysqladmin shutdown or if that won't work because something is borked, sudo kill the process numbers.
Remove any prior installed versions of mysql -- check port list installed, check for a homebrew-installed one, sudo find / -name mysql looking for compiled-from-source ones and delete them, whatever it takes. You could even remove the startup item by deleting the /Library/StartupItems/MySQLCOM directory if you want.
Run the mysql-whatever-version.pkg install package
Test it by typing sudo mysqld_safe & at the terminal. If you get "command not found," add /usr/local/mysql/bin to your path and try again. If you get any scary error messages, check for a /etc/my.cnf file as described above and try again. If it still doesn't work, then maybe try recursively chowning and chmoding the /usr/local/mysql/data directory to make sure _mysql can write to it. Once you get it to appear to start up OK, enter mysql at terminal. If you get a MySQL command prompt, all is well (enter exit to get out of it) -- in fact, if you get anything other than the ol' "Can't connect to local MySQL server through socket" then you can conclude that the MySQL server works -- shut down or kill the server and move on.
Next we'll install the startup item. Run MySQLStartupItem.pkg
Test the startup item at the terminal by entering sudo /Library/StartupItems/MySQLCOM/MySQLCOM start. It will give you a message claiming that it is starting up the server, but if it's unsuccessful it won't give you any indication, so try going into mysql again to test that the server is running. If so, enter sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop to stop the server (and to test that the startup item can stop the server as well as start it :D) If it didn't work, try making the settings described above in /usr/local/mysql/support-files/mysql.server. If that still doesn't do it, try the bit up at the top about sudo chown -R root:wheel /Library/StartupItems/MySQLCOM.
Once that works, run/install the MySQL.prefPane. This should give you a MySQL item in your System Preferences near the bottom, and if you go in there, you should see a button that you can click which will stop/start the MySQL server. Try it, and if it doesn't work by now, I'm not sure what else I can tell you.
I had experienced the same error after removing my old mac ports and installing mysql in a new mac ports directory ( a new /opt/local ).
I fixed it by setting the correct permissions for the mysql directories in the ports tree:
chown -R _mysql:_mysql /opt/local/var/db/mysql5
chown -R _mysql:_mysql /opt/local/var/run/mysql5/
chmod -R 755 /opt/local/var/run/mysql5
I'm not sure if the chmod was needed. Of course ports had already done the job of creating the _mysql user and group.