I've been trying to set up two databases as master & slave.
I followed the famous guide here:
https://dev.mysql.com/doc/refman/5.1/en/replication-howto-existingdata.html
But no luck on my slave server,
The issue I'm having is setting the server-id variable.
No matter where I define it (I looked into all the possible cnf files that might allow me to define the variable)
I tried to define it like so:
[mysqld]
server-id = 2
I also tried setting it by using SET GLOBAL server_id but obviously, it didn't save the setting.
when I do:
SHOW VARIABLES LIKE 'server_id'
It returns
server_id 0
Among the cnf files I've looked into are:
etc/mysql/mysql.conf.d/mysqld.cnf
etc/mysql/mysql.conf.d/mysqld_safe_syslog.cnf
etc/mysql/conf.d/mysql.cnf
etc/mysql/debian.cnf
etc/mysql/mysql.cnf
usr/my.cnf
usr/my-new.cnf
usr/etc/my.cnf
My MySQL server is running on Ubuntu.
And if it matters, I start it by typing:
service mysql start
I'd love to know where else I could look to fix this issue.
Thanks a bunch!
Additional Notes:
MySQL Ignoring the global conf file
I received this warning a couple of times and it disappeared when I returned the chmod to 644 on the etc/mysql folder, although every thing stated above was attempted using both 644 and 777 permissions, with 644 the warning disappears.
I know it's to late, but for those who will make the mistake.
It's server_id and not server-id:
[mysqld]
server_id = 2
For me it worked by renaming the from /etc/mysql/conf.d/my.cnf to /etc/mysql/conf.d/my.ini
I'm not sure of the exact reason for that (feel free to edit this answer and add to it).
I tried out various combinations:
Keeping the variable as: server-id and server_id
Keeping the group/section as: [mysql] and [mysqld]
Renaming the file to: my.cnf , mysqld.cnf, mysql.cnf, my.ini
You can keep trying various combinations out of the above options, it should definitely work. :)
Related
I create a table with auto_increment, and insert into it a lot of data.
My database skip number while I am using auto-increment, i found that i have to change the auto_incremet_lock_mode = 0, but i didn't find, where i have to do this change on Debian system?
I tried to find the my.cnf file in /etc/mysql/ but it contains only 2 rows, so i don't know how i can change it. I read the mysql site too but there isn't any information about it.
It was hard, but i found the answer!
edit the /etc/my.cnf file with
[mysqld]
innodb_autoinc_lock_mode=0
//You have to use autoinc_lock_mode inside this [mysqld] part!
restart/reload configs with sudo /etc/init.d/mysql restart
The default log error verbosity is 3 for mysql 5.7. I'm trying to set this to a level of 2 in the cnf file but I'm not sure of the syntax.
The GLOBAL variable log_warnings sets the level for verbosity which
varies by server version. The following snippet illustrates:
SELECT ##log_warnings; -- make a note of your prior setting
SET GLOBAL log_warnings=2; -- setting above 1 increases output (see server version)
log_warnings as seen above is a dynamic variable.
Configuration file changes in cnf and ini files might look like the
following.
[mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
Please see the MySQL Manual Page entitled [The Error Log][] especially
for Flushing and Renaming the Error Log file, and [Error Log
Verbosity] with versions related to log_warnings. The GLOBAL variable
log_warnings sets the level for verbosity which varies by server
version. The following snippet illustrates:
SELECT ##log_warnings; -- make a note of your prior setting
SET GLOBAL log_warnings=2; -- setting above 1 increases output (see server version)
log_warnings as seen above is a dynamic variable.
Configuration file changes in cnf and ini files might look like
the following.
[mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
Please see the MySQL Manual Page entitled The Error Log
especially for Flushing and Renaming the Error Log file, and Error Log
Verbosity with versions related to log_warnings.
MySQL 5.7.2 expanded the warning level verbosity to 3 and added the GLOBAL log_error_verbosity. Again, it was introduced in 5.7.2. It can be set dynamically and checked as a variable or set via cnf or ini configuration file settings.
As of MySQL 5.7.2:
[mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
log_error_verbosity = 3
Change yours to 2 if you want, above.
You can dynamically set, and check, respectively, with:
SET GLOBAL log_error_verbosity=2; -- set it
SELECT ##log_error_verbosity=2; -- sanity check, view it
yet this will be reset to cnf or ini file settings upon server restart.
I will try to improve our Docs page on that.
How to set the Configuration file (cnf or ini, Linux or Windows, respectively).
The my.cnf and my.ini files reside in the basedir. If they do not exist, you can create them, else they will use defaults baked into the server. Often there is a stubbed out file in basedir, not active, named my-default, as a template. Use that to create the real my.cnf or my.ini. Issue a
SELECT ##basedir;
to find the location where my.ini (Windows) or my.cnf (Linux) should reside. Note, you will need to have sufficient rights to modify these files. In Windows, for instance, I need to run Notepad as Administrator to write such a file.
The following are a few commands issued to confirm a change to my.ini (for Windows, my.cnf for Linux) having set log_error_verbosity to 2. Note this is after a server restart which would have used those ini or cnf changes:
I show the use of basedir because that is where your ini or cnf file must exist depending on your operating system.
I've been unable to get mysql command-line history working for my user, even though it works fine for other users on the same machine (mysql 5.5 on Debian "wheezy" distro.) I'm at wit's end, and am hoping someone here can help me...
Whenever I start mysql, I have no history to scroll back to (it just gives a visual bell alert when I try up-arrow for example).
However, as I'm using it, history works fine (within a single session). I.e., I can go back to earlier commands since I started mysql. But, the second I quit mysql, I lose all my history and have to start over again the next time.
Needless to say, this is extremely frustrating!
To troubleshoot, I did three things, none of which made any difference at all:
(1) I explicitly set the environment variable (using bash):
% MYSQL_HISTFILE=~/.mysql_history
% echo $MYSQL_HISTFILE
/var/home/userx/.mysql_history
... and I double-checked that the permissions were set correctly (both on the file and on the directory -- note, I created an empty file just to be sure it wasn't having trouble creating it itself):
drwxr-xr-x 53 userx userx 4096 Jan 24 15:26 /var/home/userx
-rw------- 1 userx userx 0 Jan 31 04:14 /var/home/userx/.mysql_history
I confirm it is "-rw-------" and the file is owned by the user in question (me), identically to all the other users on the same machine for whom it works fine. Though, the mysql client documentation doesn't say you need to set this environment variable unless you want to change it (so I've of course tried it without setting that variable as well).
(2) I tried setting/tweaking various logging-related configs in /etc/mysql/my.cnf (from looking at the documentation; however, all of the settings seem to truly be about logging, not about command-line history).
None of the settings in /etc/mysql/*.cnf seems to have anything to do with the command-line logging (only with server-level logging, e.g. to /var/log/mysql...).
To be sure, I reverted everything back to how it was in the standard installation (via debian wheezy apt-get install mysql) so any of my mucking around couldn't actually have been the reason. (Note: it works fine for other users on the same exact machine!)
(3) I tried examining/tweaking various variables within mysql itself (based on various things I've seen posted). But these are hard to find good information on, and since it works for other users on the same machine, I'm skeptical whether this will matter. Anyway, here's what I did here:
First, to get a list of all currently-set variables, I did:
% echo "show variables" | mysql > /tmp/vars
Looking through them, I didn't see anything that seemed to be relevant. But here're some examples (it's too long to dump all of them here; let me know if there's one variable or one search I can do that may yield the answer, though):
% grep -i hist /tmp/vars
performance_schema_events_waits_history_long_size 10000
performance_schema_events_waits_history_size 10
profiling_history_size 15
... as well as ...
% grep -i log /tmp/vars (note: irrelevant binlog stuff excerpted)
back_log 50
expire_logs_days 10
general_log OFF
general_log_file /var/lib/mysql/xxx.log
innodb_log_group_home_dir ./
innodb_mirrored_log_groups 1
log OFF
log_error
log_output FILE
log_queries_not_using_indexes OFF
log_slave_updates OFF
log_slow_queries OFF
log_warnings 1
slow_query_log OFF
slow_query_log_file /var/lib/mysql/rimu3-slow.log
None of these seems relevant, nor did anything I did based on various web search relating to changing variables solve my problem -- and, remember: none of the other users on the same machine has this problem. So unless the variables or other server state I haven't found actually specifically refers to my user, or there is some access policy somewhere I haven't discovered that specifically refers to my user (for example), this is just not explainable.
The only documentation I can find anywhere about the mysql_history file is here. But it doesn't tell you how to enable mysql_history! (It only says how to disable it, or to change where it goes, which also doesn't change anything for me.)
To wrap up, I have confirmed that, in the end, my troubleshooting didn't end up leaving anything set incorrectly: I'm back to the standard environment variables, server configs, variables, etc.
I'm really completely stumped here. Any help would be immensely appreciated!
Steve
I found the problem.
There are actually two files used for mysql history: ~/.mysql_history and ~/.mysql_history.TMP. I only discovered the second file using ptrace:
open("/var/home/userx/.mysql_history.TMP", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = -1 EACCES (Permission denied)
Knowing that there are two files, the issue becomes much clearer:
% ls ~/.mysql_history*
-rw------- 1 userx userx 0 Jan 31 04:14 /var/home/userx/.mysql_history
-rw------- 1 root root 279506 May 11 2014 /var/home/userx/.mysql_history.TMP
(And yes, this problem has gone back to May 2014, so that makes it all make so much sense now.)
In my case, I had root access via sudo, so I could easily fix it:
% sudo chown userx:userx /home/userx/.mysql_history.TMP
And the subsequent use of mysql worked perfectly (though all my history in between was still lost forever). :-(
The root problems are:
(a) mysql documentation makes no mention of this file (and in fact, shouldn't really need it), and
(b) mysql client doesn't give any error message to the end user letting them know this file is unmodifiable either at start-up or at exit.
--
So, there you have it, in a nutshell:
(1) The mysql documentation fails to mention anywhere that it uses .mysql_history.TMP that needs the same permissions.
(2) Using a wrapper like rlwrap worked around this (see my comment above) because it apparently doesn't use that .TMP version of the file.
Steve
I an currently using mysql server 5.6 in windows 10. while using mysql, an error keeps appearing that goes as something like this "the following column does not have a default value" i read on the internet that i can solve this problem if i change the sql_mode. It is currently set to
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
I took this from "my-default.ini" file in "mysql server 5.6" folder. I read several other answers that say that if you want to permanently change your sql_mode, you should do it through the "my-default.ini" file. So what i did was, i run my notepad as administrator, then i browsed to open "my-default.ini" file that is found in:
c:\programs files (x86)\mysql\mysql server 5.6\my-default.ini
when i opened the file, i modified the last line:
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
to
sql_mode=
then i saved the file, closed it. then by using task manager i restarted my sql sever:
task manager >> services >> mysql56
This is the whole process that should permanently modify my sql_mode. when i look in my "my-default.ini" file, the last line is still modified. but if i log into mysql through the command line and view my sql_mode with the following code:
select ##sql_mode;
I get that my sql_mode is
STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
I want all this to be removed (permanently) in order for my error to disappear. IF i try to modify the sql_mode from the command line by using:
set ##global.sql_mode="";
It worked, but when i restarted MySQL, everything was back as it was before.
Can someone please tell me what i am doing wrong? and if there is another way to solve this problem.
UPDATE: Sorry, forgot you were using Windows 10. I'm not sure how to deal with this issue in Windows but maybe try copying my-default.ini to my.ini and changing that setting. Sorry for confusion.
Not sure if you can set your sql_mode to nothing but try changing the value in your /etc/mysql/my.cnf file. If that folder/file doesn't exist, create it and try setting sql_mode under [mysqld] like this:
[mysqld]
sql_mode=
I just did this same thing only I set the sql_mode to NO_ENGINE_SUBSTITUTION.
If you have MySQL Workbench installed, check the Server Status for the base directory of your instance. You should find a my.ini file there that keeps your changes.
sql_mode need to add to file /etc/init.d/mysql as a argument to start like:
$bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" --sql-mode="" $other_args >/dev/null 2>&1 &
Restart MySQL database server to apply new config.
In MYSQL 8 and ubuntu server 20.xx I had to add:
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTIO
To file
/etc/mysql/mysql.conf.d/mysqld.cnf
In order that the setting stay persistent after server restart
Disclaimer:
this was the only place it actually worked, I have no idea what's the good practice where to add these custom settings but it 'ain't stupid if it works'. Somebody can tell me.
I tried the other options I found on forums:
my.cnf did not work creating
custom cnf did not work
adding it to mysql.cnf did not work
Using MySQL 5.5.27, in my.cnf I have:
[mysql]
sql_mode=ANSI
Upon starting the mysql console I get:
unknown variable 'sql-mode=TRADITIONAL'
The MySQL doc Server SQL Modes shows that option, so why does it not work?
(If it helps, I am on OSX Lion)
Also, here is a pastebin showing the things another person has tried, with no solution.
sql-mode should be in the [mysqld] section, not in the [mysql] section; if you move sql-mode=ANSI to the [mysqld] section, it should work.
I'm pretty certain the reason it isn't working is because it is an argument for mysqld and not the client. I came up with an alternative way that you could do this instead. Edit your users my.cnf i.e. ~/.my.cnf to be something like this:
[client]
init-command="set sql_mode='TRADITIONAL'"
In config file you should use sql-mode name instead (with dash, not underscore)
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_sql-mode
And as #cogsmos pointed out, you should put it [mysqld] section