After reading the answers on MYSQLDUMP without the password prompt I was wondering :
Is it possible to store multiple credentials, to different db accounts, in one ~/.my.cnf file? If so, what is the syntax?
N.B.: I reckon that could rise security issues but that's strictly for local/dev environment.
Asking on IRC #mysql here is what I got:
MrAmmon | not really, no. You can, if you like, have multiple files
and reference them, though MrAmmon | example - mysql
--defaults-file=~/.my.cnf-bobby
Solution
Create a credentials file for your project ;
Reference it when doing the dump (--defaults-file= must be the first option):
mysqldump --defaults-file="$HOME/.my.project.cnf" -u projectUser --no-create-db --no-create-info projectDb
Others options
There is several argument to control options:
--no-defaults: Don't read default options from any option file.
--defaults-file=#: Only read default options from the given file #.
--defaults-extra-file=#: Read this file after the global files are read.
Related
I have a bash script that connects to a mysql server and pulls information. I have my .my.cnf file in my home directory. I want to change the location of the .cnf file to ~myname/.my.cnf
My question is how do I reference this new location in my script or in my mysql call to the database?
Thanks
Here's the doc reference for how MySQL looks at Options Files:
https://dev.mysql.com/doc/refman/5.7/en/option-files.html
File Name Purpose
/etc/my.cnf Global options
/etc/mysql/my.cnf Global options
SYSCONFDIR/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options (server only)
defaults-extra-file The file specified with --defaults-extra-file, if any
~/.my.cnf User-specific options
~/.mylogin.cnf User-specific login path options (clients only)
Note: you want to use defaults-extra-file option when connecting with mysql client. mysql --defaults-extra-file=~/path/to/file/.filename < script
You should consider using --login-path as an alternative. Login path reference. The file is not plain text. You use mysql_config_editor to create your login paths, which stores username, password, host, etc.
I don't know what you mean by "~myname/.my.cnf". This would expand to a directory made of a concatenation of your username and "myname" which doesn't make any sense. I guess you might mean "~/something/.my.cnf"
The '~' expands to $HOME hence simply redefining $HOME before invoking mysql should suffice (although this will confuse further references to '~'.
HOME=$HOME/myname
mysql <somescript.sql
It's no full support and not flexible(WORKBENCH), still no solution....
I want to create dump scripts of each table in my database....
workbench 5.2.47 CE version i am using...
I checked
My database and all tables
And options like dump stored routines, dump events
in advanced options i checked.......
add-locks,
complete-insert,
replace,
hex-blob,
disable-keys,
order-by-primary,
create-options,
allow-keywords,
quote-names
Problems.
How I save the configuration setting or all above setting I did..and second time I want to add just my setting file if I save.. And create a dump
CREATE DATABASE IF NOT EXISTS mydatabase /*!40100 DEFAULT CHARACTER SET latin1 */;
USE mydatabase;
..................This one I want to skip or exclude form dump scripts but there are no options in workbench as in mysql command is there --no-create-db, -n and for remove USE mydatabase remove option as --databases
All mysqldump options are not available which I need.............
Any solution for above questions or any custom create options in workbench...
Thanks..
I have just met similar problems and found the following way to add options.
My environment is:
Windows 8/64bit
MySQL Workbench 6.08
(you may adjust the step according to your system such as Linux)
First, close MySQL Workbench
In the folder:
C:\Program Files (x86)\MySQL\MySQL Workbench CE 6.0.8\modules
there are many python files, there is a file called
wb_admin_export_options.py which is Python source code and there is
another file with same name
wb_admin_export_options.pyc which is a compiled Python file.
Step to Edit
rename 2 into wb_admin_export_options.pyc-org to avoid the program
read the old option list and make a copy of 1 in case there is any
problem
run your code editor in Administrator mode if in Window for UAC reason.
Open wb_admin_export_options.py
Note: You will see the option list for mysqldump which is appear in
Workbench->Administration[Tab]->Advanced Options...[button on the top right]
Note on editing the file
Add the option you need in the list similar to the source code, eg:
The true of false near the closing bracket means default value (check or uncheck by default)
"create-options":["Include all MySQL-specific table options in CREATE TABLE statements.","TRUE"],
Open the MySQL Workbench again and it will read the updated option list and let you choose from.
Hope this help.
I am trying to import zipped database files into Mysql using command prompt using the following command
7z < backup.sql.7z | mysql -u root test
The root user don't have any password associated with it.
test is my target blank database.
I use 7zip for unzipping purpose.
The zipped database i.e. backup.sql.7z is located in D drive.
But it's giving the following error
So, instead I used the following command
7z < backup.7z | mysql -u root test
Note: This time I am using backup.7z instead of backup.sql.7z
But then I get the following error
Clearly there's something wrong with my SQL syntax.
What will be the correct syntax to use then ?
I needed to import from a compressed file as well, and stumbled upon your question.
After a bit of messing around, I found that this worked for me:
7z x -so backup.7z | mysql -u root test
x is the extraction command
-so makes 7-zip write to stdout
Nothing wrong with your syntax, it's just a limitation with 7zip. It's better to use xz in this case, which doesn't put extraneous junk in stdout, or directly call the 7z.dll with your favorite programming language. 7z.exe is really meant for archive management, rather than unix-style piping, and Igor is very reluctant to change that.
If you try a plain 7z < somefile.7z you'll immediately see that all you get back is a usage list.
My main MySQL user's /home//my.cnf file looks like this (Linux system):
[client]
host=localhost
user=<user>
password=********
database=h2o_amr
I want to point mysqldump to this config file, which is in the directory where the mysqldump file will be written:
[client]
host=localhost
user=<user>
password=********
How do I point mysqldump to this config file? I have searched for an answer to this in the man pages and the Internet before posting this question.
There are three options to change the default behavior:
--no-defaults: Don't read default options from any option file.
--defaults-file=#: Only read default options from the given file #.
--defaults-extra-file=#: Read this file after the global files are read.
This information was copied from the integrated manual, i.e.mysqldump --help | grep -A7 'Default options'.
Note: The parameter needs to be in first position if you add others parameters, if not it will not be recognized.
According to the documentation, there is a --defaults-file=PATH option that does exactly what you need. I tried it myself with mysqldump and it appears to have worked.
There are also other ways to have MySQL read option files without using that argument: using the default paths MySQL clients search through to compile the list of options (1st and 2nd table).
When I want to execute an update query on my table I got an error saying:
1036 - Table data is read only.
How can I fix that?
Table attributes in /var/db/mysql are set to 777.
'Repair Table' function doesnt seems to help.
Is there anything I can do with that?
In my case, mysql config file had innodb_force_recovery = 1. Commenting that out solved the issue. Hope it helps someone.
who owns /var/db/mysql and what group are they in, should be mysql:mysql. you'll also need to restart mysql for changes to take affect
also check that the currently logged in user had GRANT access to update
(This answer is related to the headline, but not to the original question.)
In case you (like me) are trying to temporarily alter data via the MySQL Workbench interface:
If the table does not have a primary key, MySQL Workbench has no way of identifying the row you are trying to alter, so therefore you cannot alter it.
Solution in that case is to either alter the data via another route, or simply to add a primary key to the table.
In any case, I hope it helps someone :)
You should change owner to MYSQL:MYSQL.
Use this command: chown -Rf mysql:mysql /var/lib/mysql/DBNAME
My situation is everytime I needed to edit "innodb_force_recovery = 1" in my.ini to force mysql to start, and the error log showed some error said:
Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: .\mysql\innodb_table_stats.ibd. Cannot open tablespace profile/profile_commentmeta which uses space ID: 1 at filepath: .\profile\profile_commentmeta.ibd
I didn't know why this file was not able to open and it caused so many other"table read only" problems to other databases too.
So here is how I fixed this problem in a simple way without hurting other files.
1
First of all, make sure if you add innodb_force_recovery = 1
below [mysqld] in my.ini file, and it is working, under path: X:\xampp\mysql\bin\my.ini
2
Then next step, export all the databases through localhost/phpmyadmin under the export tab, and store them somewhere, like this:
3 comment out the data filefolder to data-bak, then create a new data filefolder,
4 Next step, import all .sql database back from phpmyadmin panel, please also copy phpmyadmin filefolder from the old data-bak filefolder to the new data filefolder. If any file is necessary, go back to data-bak filefolder to copy and paste.
Now all fixed and done, don't need to force mysql to start everytime.
Hope this also works for you.
MySQL doesn't have write access to the database file. Check the permissions and the owner of the file.
On windows I use Xampp server I comment the line in my.ini
innodb_force_recovery = 1 to #innodb_force_recovery = 1 the problem resolved
I solved the same issue by editing app. armour configuration file. Found the answer here: https://stackoverflow.com/a/14563327/31755661
maybe you get read only error from your table storage engine.
Check you Storage Engine, maybe if it is MRG_MYISAM change it to MyISAM and try again.
If you are running selinux in enforcing mode then check your /var/log/messages for audit faults. If you see the tell-tale "****" messages about selinux blocking write access to your table files in / then you need to relabel those files so that they have this label:
system_u:object_r:mysqld_db_t:s0
What you could have is a broken label from copying those files over from a user directory (such as during a recovery attempt).
There's a great resource for selinux here:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
Just remember that you will need to do this for all of those files, which could be many. Then you will want to run the "restorecon -R -v " command to get the recursive (-R) application of the new labels. There is no support for -R in the semanage command, as far as I could tell.
For reference, the semanage command to relabel looks like this:
semanage fcontext -a -t mysqld_db_t 'filename'
The quoting of the file name is critical for the command to work.
In my case there was a table with read-only state set and when I tried to restart mysql service it would not even start again and with no descriptive error.
Solution was to run fsck on the drive (with many fixes), which was advised after Ubuntu reboot.
I'm running Ubuntu in VirtualBox under Windows and it often hangs or is having functionality problems.
One other way to receive this error is to create your table with a "Like" statement and use as source a merged table. That way the newly create table is read-only and can't "receive" any new records.
so
CREATE TABLE ic.icdrs_kw37 LIKE ic.icdrs ... #<- a merged table.
then:
REPLACE INTO ic.icdrs_kw37 ... # -> "Table is read-only"
bug or feature?