I have installed MySQL 5.6.17 on my Ubuntu 14.04 following the instructions at http://dev.mysql.com/doc/refman/5.0/en/binary-installation.html.
The instructions says to use the optional command :
shell> cp support-files/my-medium.cnf /etc/my.cnf
But I do not see any "my-medium.cnf" file in the folder.
The instructions also mentions :
shell> cp support-files/mysql.server /etc/init.d/mysql.server
What exactly is the purpose of copying this file to the destination?
You can replace my-medium.cnf with my.cnf ,Because you use data directory and base directory at some where.MySQL need a path to access those directories.So inorder to make this changes you have to work with .cnf files.So it is understandable that you can make a copy of it.Before you edit.
Related
I have to "insert" a lot of files into an owncloud server (8.2).
A user give me a USB key with the files and tell me to copy of all them into his owncloud data files repository.
Do you know if is it possible ?
Is it possible to synchronyze the ownCloud data fileSystem with the ownCloud database?
My environment is Linux CentOS7 (Apache 2.4, mySQL 5.6, php 5.6)
Thanks,
owncloud brings a command line utility that allows to manually trigger some tasks. Among those is the files:scan function which re-scans a users file system.
So you can import those files by following these steps:
1. you copy the files into the physical file system of the user(s) inside ownclouds data folder
2. you fire the command line utility to re-scan the files. That takes care to update the database according to the files found.
This is an example for the manual trigger:
sudo -u www-data php occ files:scan <user name>
Here <user name> obviously has to be replaced. Also the account name the sudo command switches to depends on the linux distribution and its setup. The command has to be started inside ownclouds base folder. THe command can be called in a loop with different user names, that can be done by means of standard scripting.
Here is a documentation of the utility: https://doc.owncloud.org/server/8.0/admin_manual/configuration_server/occ_command.html
I just made a try myself using an owncloud-8.2 installation and succeeded.
Before I could sucessfully scan my files again as arkascha explained, I needed to change the ownder and the group of the new folder to www-data (for Debian OS - others see OC-Docu 1) and set rights of the new directory to 755
Change ownder:
sudo chown -R www-data:www-data <path>
Change rights:
sudo chmod 755 <path>
whwere is the path to the newly added directory and could for example look like this example: /media/hdd/owncloud/data/<username>/files/<newFolderName>
OC-Docu:
https://doc.owncloud.org/server/9.0/admin_manual/configuration_server/occ_command.html
I am new to the database world and I ran into some problems....
My hard disk on my Mac says I have less than 8gb left of free space. For this reason, I would like to move my MySQL data directory to an external network drive called ls-xld4c.
I have been trying to follow the rules to do so via http://mailsteward.com/nickstek/?p=22
As noted from step 3 from the link above:
I copied the /usr/local/mysql/data directory and all of its files and subdirectories to the
new location at /Volumes/share/MYSQL
So here is what i typed in my terminal:
cd /Volumes/share/MYSQL
cp -R /usr/local/mysql/data
which returns the following: ( i do not know what this means)
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory
Here is some info that might be handy:
1) Server version: 5.6.17 MySQL Community Server (GPL)
2) Where my external drive is located: /Volumes/share
-The network drive is called ls-xld4c and is 1TB in size(I don't know if that is relevant)
The specific folder I want to put the directory reads that it is found in...
Server : smb://ls-xld4c/share/MYSQL , however /Volumes/share/MYSQL shows that it is a valid directory
3) I do not have a password and the user is root
You have almost done it. The error is flagged because you have not specified the destination directory which should be your current working directory. Please use CO command as:
cp -R /usr/local/mysql/data .
The ending dot means current directory which you have already set by using:
cd /Volumes/share/MYSQL
By the way, the following steps are required:
Stop MySQL service.
Copy data files from the directory as specified in "my.cnf" or "my.inf" (in case of windows).
Paste data to destination dir.
Change "my.cnf" or "my.inf" such as the "datadir" entry specifies the destination path.
Restart MySQL.
1. Stop MySQL
sudo /etc/init.d/mysql stop
2. Change Data Directory
sudo cp -R -p /var/lib/mysql /newlocation
3. Edit MySQL default configuration file
sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
change 'datadir' to /newlocation
sudo vim /etc/apparmor.d/usr.sbin.mysqld
change '/var/lib/mysql' two-entries to /newlocation
4. Start MySQL
sudo /etc/init.d/mysql restart
On macOS Big Sur, MySQL installer used to install MySQL:
Go to System Preferences > MySQL > click on Stop MySQL Server
In configuration tab, you can see current Data Directory
Copy data folder to your destination directory
Change "Data Directory" address to your destination address > then Apply
Go to System Preferences > Security & Privacy > Privacy > Full Disk Access and make sure "mysqld" is checked here
Go to System Preferences > MySQL > click on Start MySQL Server
if you do not do step 5, the service won't start back.
hope it helps for those with permission issues
I recently upgraded my Mac to Mavericks and am having trouble getting MySQL to work.
I removed my previous MySQL installation per instructions found on the web, then downloaded the DMG file and ran the installer - after which, I was able to get it running, but was not able to log in.
I noticed the installer created a /usr/local/mysql/ directory which points to /usr/local/mysql-5.6.19-osx10.7-x86_64
I then replaced the /usr/local/mysql-5.6.19-osx10.7-x86_64/data directory with the old data directory, and now I can't start MySQL.
I get the error: "warning the /usr/local/mysql/data directory is not owned by the 'mysql' or '_mysql' user" and can no longer start MySQL.
I tried to change permissions of the directory with the following without luck:
sudo chmod -R 777 /usr/local/mysql/
sudo chmod -R 777 /usr/local/mysql-5.6.19-osx10.7-x86_64
sudo chown -R mysql:mysql /usr/local/mysql/data
sudo chown -R mysql:mysql /usr/local/mysql/data
sudo chown -R _mysql /usr/local/var/mysql
chown: /usr/local/var/mysql: No such file or directory
sudo chmod -R o+rwx /usr/local/var/mysql
chmod: /usr/local/var/mysql: No such file or directory
I did modify the plist file and cnf files as described here:
https://community.jboss.org/blogs/tedjones/2014/05/02/getting-mysql-up-and-running-after-upgrading-to-mavericks?_sscc=t
Not sure what else to do.
I was able to solve this problem. You just have to be meticulous when you run the install.
Please note that upgrading from Mac OS 10.8 or older to Mavericks will cause MySQL to no longer run (in other words, "Are you sure you want to upgrade to Mavericks?")
With MySQL non-functional, I decided to reinstall MySQL and upgrade to the newest version.
I followed the instructions in the link above with the following words of advice:
Backup your MySQL data directory before doing anything.
The MySQL data file is located in the /usr/local/mysql-5.6.19-osx10.7-x86_64/data directory (or similar, depending on what version you have installed).
BACK IT UP!
Make sure you stop MySQL before installing the upgraded version.
If your plist file has keepalive set to True, every time you try to quit MySQL, it will quit (or will appear to quit) but then immediately restart.
If you want to use the Preference Pane to start and stop MySQL, make sure you set keepalive in the .plist file to false, otherwise the Preference Pane won't work.
I tried to kill the plist process after making the change, but it wouldn't work. I just restarted my Mac and from that point on, I was able to start and stop MySQL from Terminal or the Preference Pane when needed.
Occasionally, the Preference Pane failed to start/stop MySQL. In that case, I would enter the start/stop command in Terminal and it worked.
Start MySQL:
sudo /usr/local/mysql/support-files/mysql.server start
Stop MySQL:
sudo /usr/local/mysql/support-files/mysql.server stop
Download the .dmg file from MySQL and run the installer.
I did try downloading the .tar file, and it may have worked - but on my second try, I chose the .dmg file and everything went smoothly.
If you try to start MySQL at this point, it should run without a problem.
Remember, since at this point you have a clean install of MySQL, you can log in with the username 'root' and password 'no password' (leave password blank).
Please note that if you start MySQL from the terminal, you will get more information than trying from the Preference Pane, so if you are having difficulty, make sure you stop and start MySQL from Terminal. You will get some error messages that you use to troubleshoot the problem.
You can modify the .cnf and .plist files as mentioned in the installer instructions above (as long as you stop MySQL before making any changes).
Typically you would copy and paste the information from the web page (mentioned above) into the .cnf file. It is pretty straight forward, but double and triple check that the copy and paste did not miss a character or two. This happened to me while pasting the code into the .cnf file (the first two characters were missing) and it took me hours to figure this out - which prevented MySQL from starting.
If the changes to the .cnf or .plist file don't seem to take effect, restart the Mac (easier than restarting the process).
Moving your data.
My install created a /usr/local/mysql/ alias or symbolic link to the /usr/local/mysql/mysql-5.6.19-osx10.7-x86_64 directory.
The /usr/local/mysql/data directory (which is actually the /usr/local/mysql/mysql-5.6.19-osx10.7-x86_64/data directory - remember, it's a symbolic link) is where your data resides.
You want a backup of your previous data directory. If you forgot to back that up before running the installer, and you have a Time Machine backup, you can retrieve it.
The easiest way to do this is to open the /usr/local/ directory (From the Finder and choose "Go to Folder" from the Go menu) and with the /usr/local/ directory open in the Finder, choose Enter Time Machine from the Time Machine menu. Go back to the last known date that has your previous MySQL installation. Find the folder of your previous MySQL install and open the data directory.
You have to choose all the files from the exact same point in time. You can't choose one data folder from one day and one data folder from another (I actually did this and spent a lot of time trying to figure out why one of my data tables were visible in Sequel Pro but wouldn't work). After a while, I finally figured out that everything absolutely has to be from the exact same point in time.
You can copy files while in Time Machine by right-clicking on them. Choose all your data folders (with the .ibd and .frm files in them) PLUS all the ib_logfiles (ib_logfile0, ib_logfile1), auto.cnf, and the .pid file. Basically copy everything in the mysql data folder EXCEPT the mysql, performance_schema, and test directories.
Exit Time Machine.
Make sure MySQL is stopped and then paste the data files into the /usr/local/mysql/data directory.
Set the privileges to the data directory.
In Terminal, enter:
sudo chown -R mysql:mysql /usr/local/mysql/data
Make sure NOT to use the chmod 777 command as some people online said it can damage things.
Now, start MySQL and you should have your data files from your previous MySQL install intact and functional. In addition, I did not have to reset any passwords for Sequel Pro. The Sequel Pro settings saved before the Mavericks upgrade worked.
How do I know which configuration file is used by MySQL currently? Is there any command or something to find it out?
The information you want can be found by running
mysql --help
or
mysqld --help --verbose
I tried this command on my machine:
mysql --help | grep "Default options" -A 1
And it printed out:
Default options are read from the following files in the given order:
/etc/my.cnf /usr/local/etc/my.cnf ~/.my.cnf
See if that works for you.
mysqld --help --verbose will find only location of default configuration file. What if you use 2 MySQL instances on the same server? It's not going to help.
Good article about figuring it out:
"How to find MySQL configuration file?"
If you are using terminal just type the following:
locate my.cnf
You can use the report process status ps command:
ps ax | grep '[m]ysqld'
You should find them by default in a folder like /etc/my.cnf, maybe also depends on versions. From MySQL Configuration File:
Interestingly, the scope of this file
can be set according to its location.
The settings will be considered global
to all MySQL servers if stored in
/etc/my.cnf. It will be global to a
specific server if located in the
directory where the MySQL databases
are stored (/usr/local/mysql/data for
a binary installation, or
/usr/local/var for a source
installation). Finally, its scope
could be limited to a specific user if
located in the home directory of the
MySQL user (~/.my.cnf). Keep in mind
that even if MySQL does locate a
my.cnf file in /etc/my.cnf (global to
all MySQL servers on that machine), it
will continue its search for a
server-specific file, and then a
user-specific file. You can think of
the final configuration settings as
being the result of the /etc/my.cnf,
mysql-data-dir/my.cnf, and ~/.my.cnf
files.
There are a few switches to package managers to list specific files.
RPM Sytems:
There are switches to rpm command, -q for query, and -c or --configfiles to list config files. There is also -l or --list
The --configfiles one didn't quiet work for me, but --list did list a few .cnf files held by mysql-server
rpm -q --list mysql-server
DEB Systems:
Also with limited success: dpkg --listfiles mysql-server
you can find it by running the following command
mysql --help
it will give you the mysql installed directory and all commands for mysql.
login to mysql with proper credential and used mysql>SHOW VARIABLES LIKE 'datadir'; that will give you path of where mysql stored
I am trying to dump the contents of a table to a csv file using a MySQL SELECT INTO OUTFILE statement. If I do:
SELECT column1, column2
INTO OUTFILE 'outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;
outfile.csv will be created on the server in the same directory this database's files are stored in.
However, when I change my query to:
SELECT column1, column2
INTO OUTFILE '/data/outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;
I get:
ERROR 1 (HY000): Can't create/write to file '/data/outfile.csv' (Errcode: 13)
Errcode 13 is a permissions error, but I get it even if I change ownership of /data to mysql:mysql and give it 777 permissions. MySQL is running as user "mysql".
Strangely I can create the file in /tmp, just not in any other directory I've tried, even with permissions set such that user mysql should be able to write to the directory.
This is MySQL 5.0.75 running on Ubuntu.
Which particular version of Ubuntu is this and is this Ubuntu Server Edition?
Recent Ubuntu Server Editions (such as 10.04) ship with AppArmor and MySQL's profile might be in enforcing mode by default. You can check this by executing sudo aa-status like so:
# sudo aa-status
5 profiles are loaded.
5 profiles are in enforce mode.
/usr/lib/connman/scripts/dhclient-script
/sbin/dhclient3
/usr/sbin/tcpdump
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/sbin/mysqld
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
/usr/sbin/mysqld (1089)
0 processes are in complain mode.
If mysqld is included in enforce mode, then it is the one probably denying the write. Entries would also be written in /var/log/messages when AppArmor blocks the writes/accesses. What you can do is edit /etc/apparmor.d/usr.sbin.mysqld and add /data/ and /data/* near the bottom like so:
...
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
**/data/ r,
/data/* rw,**
}
And then make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: the change above will allow MySQL to read and write to the /data directory. We hope you've already considered the security implications of this.
Ubuntu uses AppArmor and that is whats preventing you from accessing /data/. Fedora uses selinux and that would prevent this on a RHEL/Fedora/CentOS machine.
To modify AppArmor to allow MySQL to access /data/ do the follow:
sudo gedit /etc/apparmor.d/usr.sbin.mysqld
add this line anywhere in the list of directories:
/data/ rw,
then do a :
sudo /etc/init.d/apparmor restart
Another option is to disable AppArmor for mysql altogether, this is NOT RECOMMENDED:
sudo mv /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
Don't forget to restart apparmor:
sudo /etc/init.d/apparmor restart
I know you said that you tried already setting permissions to 777, but as I have an evidence that for me it was a permission issue I'm posting what I exactly run hoping it can help. Here is my experience:
tmp $ pwd
/Users/username/tmp
tmp $ mkdir bkptest
tmp $ mysqldump -u root -T bkptest bkptest
mysqldump: Got error: 1: Can't create/write to file '/Users/username/tmp/bkptest/people.txt' (Errcode: 13) when executing 'SELECT INTO OUTFILE'
tmp $ chmod a+rwx bkptest/
tmp $ mysqldump -u root -T bkptest bkptest
tmp $ ls bkptest/
people.sql people.txt
tmp $
MySQL is getting stupid here. It tries to create files under /tmp/data/.... So what you can do is the following:
mkdir /tmp/data
mount --bind /data /tmp/data
Then try your query. This worked for me after hours of debugging the issue.
You can do this :
mysql -u USERNAME --password=PASSWORD --database=DATABASE --execute='SELECT `FIELD`, `FIELD` FROM `TABLE` LIMIT 0, 10000 ' -X > file.xml
This problem has been bothering me for a long time. I noticed that this discussion does not point out the solution on RHEL/Fecora. I am using RHEL and I do not find the configuration files corresponding to AppArmer on Ubuntu, but I solved my problem by making EVERY directory in the directory PATH readable and accessible by mysql. For example, if you create a directory /tmp, the following two commands make SELECT INTO OUTFILE able to output the .sql AND .sql file
chown mysql:mysql /tmp
chmod a+rx /tmp
If you create a directory in your home directory /home/tom, you must do this for both /home and /home/tom.
Some things to try:
is the secure_file_priv system variable set? If it is, all files must be written to that directory.
ensure that the file does not exist - MySQL will only create new files, not overwrite existing ones.
I have same problem and I fixed this issue by following steps:
Operating system : ubuntu 12.04
lamp installed
suppose your directory to save output file is : /var/www/csv/
Execute following command on terminal and edit this file using gedit editor to add your directory to output file.
sudo gedit /etc/apparmor.d/usr.sbin.mysqld
now file would be opened in editor please add your directory there
/var/www/csv/* rw,
likewise I have added in my file, as following given image :
Execute next command to restart services :
sudo /etc/init.d/apparmor restart
For example I execute following query into phpmyadmin query builder to output data in csv file
SELECT colName1, colName2,colName3
INTO OUTFILE '/var/www/csv/OUTFILE.csv'
FIELDS TERMINATED BY ','
FROM tableName;
It successfully done and write all rows with selected columns into OUTPUT.csv file...
In my case, the solution was to make every directory in the directory path readable and accessible by mysql (chmod a+rx). The directory was still specified by its relative path in the command line.
chmod a+rx /tmp
chmod a+rx /tmp/migration
etc.
I just ran into this same problem. My issue was the directory that I was trying to dump into didn't have write permission for the mysqld process. The initial sql dump would write out but the write of the csv/txt file would fail. Looks like the sql dump runs as the current user and the conversion to csv/txt is run as the user that is running mysqld. So the directory needs write permissions for both users.
You need to provide an absolute path, not a relative path.
Provide the full path to the /data directory you are trying to write to.
Does Ubuntu use SELinux? Check to see if it's enabled and enforcing. /var/log/audit/audit.log may be helpul (if that's where Ubuntu sticks it -- that's the RHEL/Fedora location).
I had the same problem on a CentOs 6.7
In my case all permissions were set and still the error occured. The problem was that the SE Linux was in the mode "enforcing".
I switched it to "permissive" using the command sudo setenforce 0
Then everything worked out for me.