We have configured website over linux server and over MYSQL database,
and we have removed only_full_group_by variable from sql mode, but it again reset back to sql mode after specific period time.
Can anyone have idea behind this for possible reason
https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html
Setting the SQL Mode
The default SQL mode in MySQL 8.0 includes these modes: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, and NO_ENGINE_SUBSTITUTION.
To set the SQL mode at server startup, use the --sql-mode="modes" option on the command line, or sql-mode="modes" in an option file such as my.cnf (Unix operating systems) or my.ini (Windows). modes is a list of different modes separated by commas. To clear the SQL mode explicitly, set it to an empty string using --sql-mode="" on the command line, or sql-mode="" in an option file.
Related
I have researched a lot and what I understand to make database tables name sensitive, you have to set the variable lower_case_table_names=0.
Im on osX. I did this change in my.cnf.
After that, if I run
select * from users
I get results. While if I run:
select * from Users
I get error saying table doesn't exist.
However, for a particular database, the case sensitivity doesnt affect. I can use any case I will never receive errors. Why? I could have a look at the big sql-file used to import the database and try to find out if there are specific directives to ignore case sensitivity (?).
Anyway, why you think the case sensitivity applies for all database but not the one Im interested in? One of those that does case sensitivity is InnoDB. While the one that doesnt care about this is MyIsam. Could it be the reason? Any work around in that case?
Tables and Columns are Case Sensitive in Linux! To make them case insensitive, follow this:
Open terminal and edit /etc/mysql/my.cnf
sudo nano /etc/mysql/my.cnf
Underneath the [mysqld] section, add:
lower_case_table_names = 1
Restart mysql
sudo /etc/init.d/mysql restart
Then check it here:
mysqladmin -u root -p variables
Just altering the lower_case_table_names setting isn't enough. It needs to be done before you import your database(s).
The MySQL 5.7 documentation lists a procedure for moving between Windows and Linux/UNIX. A note about Mac OSX from that reference:
One notable exception is OS X, which is Unix-based but uses a default
file system type (HFS+) that is not case sensitive. However, OS X also
supports UFS volumes, which are case sensitive just as on any Unix.
Review the manual page to ensure that your desired rules for enforcing case sensitivity are followed. Take a look and verify that you did these steps in the correct order:
To convert one or more entire databases, dump them before setting
lower_case_table_names, then drop the databases, and reload them after
setting lower_case_table_names:
1 - Use mysqldump to dump each database:
mysqldump --databases db1 > db1.sql
mysqldump --databases db2 >
db2.sql
... Do this for each database that must be recreated.
2 - Use DROP DATABASE to drop each database.
3 - Stop the server, set lower_case_table_names in the [mysqld] section of your \etc\mysql\my.cnf file, and restart the server.
4 - Reload the dump file for each database. Because lower_case_table_names
is set, each database and table name will be converted to lowercase as
it is recreated:
mysql < db1.sql
mysql < db2.sql
Concerning the MySQL System Variable lower_case_table_names Server Variable (or setting):
Additional References:
MySQL case sensitive table names on Linux
How to make MySQL table name case insensitive in Ubuntu?
MacOsx 10.13, docker 3.0.1.
Changing lower_case_table_names to 0 did not help me. Mysql gave error
[ERROR] The server option ‘lower_case_table_names’ is configured to use case sensitive table names but the data directory is on a case-insensitive file system which is an unsupported combination. Please consider either using a case sensitive file system for your data directory or switching to a case-insensitive table name mode.
Turning this setting Use gRPC FUSE for file sharing off in docker settings helped:
The case sensitivity of database and table names depends on the underlying OS and file system.
On Windows they are not case sensitive. On Linux they are case sensitive.
OSX is somewhere in the middle; the HFS file system supports both case-sensitive and case-insensitive file names (not on the same time though). It depends on how it was formatted.
By default, table aliases are case-sensitive on Unix, but not so on Windows or macOS. And you can't force this on OSX.
The MySql documentation gives the following recommendation:
To avoid problems caused by such differences, it is best to adopt a consistent convention, such as always creating and referring to databases and tables using lowercase names. This convention is recommended for maximum portability and ease of use.
In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database, table, and trigger names. This means such names are not case-sensitive in Windows but are case-sensitive in most varieties of Unix. One notable exception is macOS, which is Unix-based but uses a default file system type (HFS+) that is not case-sensitive. However, macOS also supports UFS volumes, which are case-sensitive just as on any Unix. See Section 1.7.1, “MySQL Extensions to Standard SQL”. The lower_case_table_names system variable also affects how the server handles identifier case sensitivity, as described later in this section.
The recommended is use lower_case_table_names=1 on all systems, but the disadvantage with this is that when you use SHOW TABLES or SHOW DATABASES, you don't see the names in the original case.
the variable lower_case_table_names is 0 by default, which means table names are stored as specified and comparisons are case-sensitive.
that is the possible values:
0: table names are stored as specified and comparisons are case-sensitive.
1: table names are stored in lowercase on disk and comparisons are not case-sensitive.
2: table names are stored as given but compared in lowercase. This option also applies to database names and table aliases.
On Windows the default value is 1. On macOS, the default value is 2. On Linux, a value of 2 is not supported; the server forces the value to 0 instead.
and here are your answer
You should not set lower_case_table_names to 0 if you are running MySQL on a system where the data directory resides on a case-insensitive file system (such as on Windows or macOS). It is an unsupported combination that could result in a hang condition when running an INSERT INTO ... SELECT ... FROM tbl_name operation with the wrong tbl_name lettercase. With MyISAM, accessing table names using different lettercases could cause index corruption.
An error message is printed and the server exits if you attempt to start the server with --lower_case_table_names=0 on a case-insensitive file system.
you can change this in my.cnf file, and you can find it using following command (if you are using unix-based system)
mysql --help | grep cnf
References:
MySQL 5.7 Reference Manual Identifier Case Sensitivity
MySQL 5.7 Reference Manual 5.1.7 Server System Variables
However, for a particular database, the case sensitivity doesnt
affect. I can use any case I will never receive errors. Why?
This is because this database is simply created with option of case-insensitivity (by default). You need first to put case-sensitive option in the top of sql create script before the database creation, so the DBMS takes care.
Locate file at /etc/mysql/my.cnf
Edit the file by adding the following lines:
[mysqld]
lower_case_table_names=1
sudo /etc/init.d/mysql restart
You might need to re-create these tables to make it work
mysql manual states:
If you plan to set the lower_case_table_names system variable to 1 on Unix, you must first convert your old database and table names to lowercase before stopping mysqld and restarting it with the new variable setting.
In any new APFS based Mac you can do this which appears to be working. The following will create a new volume that which is case-sensitive (APFSX) that you can use for your volume data. Note: You should do this in a fresh directory.
mkdir <docker volume directory>
sudo diskutil apfs addVolume disk1 APFSX docker -mountpoint <docker volume directory>
sudo chown -R $(id -u):$(id -g) <docker volume directory>
Ref: Feature to opt-in into a case sensitive file-system (osxfs) on a volume mount
Only solution on MacOS goes neither over lower_case_table_names nor else settings of MySQL DBMS.
You need a case sensitive file system (volume). But fortunately it's easy to create it under MacOS:
start the 'Disk Utility'
Unter a main APFS-Container add a new APFS volume with case sensitivity (assume, we name it 'MysqlData', you can also define the size quota for this volume)
move all the database binary data to this volume (in a directory in this volume i.e. /Volumes/MysqlData/data)
make a symbolic link (assume our mysql data directory is /usr/local/mysql/data) to this volume:
i.e.
/usr/local/mysql/data -> /Volumes/MysqlData/data
DO A BACKUP OF /usr/local/mysql/data BEFORE!!!
start MySQL DBMS and load/import a DB (maybe you have to remove these DBs before) with uppercase tables
voila: you will finally see these tables with uppercase
I have installed MySql Workbench 6.2 with MySql version 5.6 on my Windows 7 64-bit.
I would like to use Capital letters in my database name and table names. So I need to set the variable lower_case_table_names to 2. When I look at my Options file's General tab, it looks like the following:
Clicking Apply opens a dialog that says "There Are No Changes".
Regardless, when I try to create a database with a Capital letter, I get the warning:
The server is configured with lower_case_table_names=1 which only
allows lowercase characters in schema and table names.
I have a feeling the my.ini file on the server differs from the one mentioned in the Options File configuration. When I try to add this variable manually
inside my my.ini file, I see the text below:
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
This is how I have been stuck in creating my schema for a few days now.
In Windows, table naming is case-insensitive. That is, your Customer table and your customer table will always be the same on Windows. That's a limitation of the NT File System. This applies when your MySQL server is running on a Windows platform. It doesn't matter where your workbench client is running.
(You can use mixed-case table names for different tables on Linux, BSD, and the like, but it's considered very bad practice: only do that if you want to drive your colleagues crazy. So be careful.)
If you leave this lower_case_table_names setting alone, you can use mixed case in your table names without problems.
The my.ini file the server actually uses when it starts is usually found in the data directory. The installation procedure can copy a preloaded version of that file, like my_large.ini on top of my.ini depending on what you are trying to do.
You can't even start mysqld after changing the lower_case_table_names setting other to anything other than 1, which is the default.
0 => You should not set lower_case_table_names to 0 if you are running MySQL on a system where the data directory resides on a case-insensitive file system (such as on Windows or macOS). It is an unsupported combination that could result in a hang condition.
But let's try changing it to 2:
# Specifies the on how table names are stored in the metadata.
# If set to 0, will throw an error on case-insensitive operative systems
# If set to 1, table names are stored in lowercase on disk and comparisons are not case sensitive.
# If set to 2, table names are stored as given but compared in lowercase.
# This option also applies to database names and table aliases.
# NOTE: Modify this value after Server initialization won't take effect.
lower_case_table_names=2
C:\Program Files\MySQL\MySQL Server 8.0\bin>mysqld
--defaults-file="C:\Program Files\MySQL\MySQL Server 8.0\my.ini"
ERROR [MY-011087] [Server, Different lower_case_table_names settings for server ('2') and data dictionary ('1').
ERROR [MY-010020] [Server, Data Dictionary initialization failed.
After initialization, it is not allowed to change this setting.
So lower_case_table_names needs to be set together with --initialize.
It is prohibited to start the server with a lower_case_table_names setting that is different from the setting used when the server was initialized. The restriction is necessary because collations used by various data dictionary table fields are based on the setting defined when the server is initialized, and restarting the server with a different setting would introduce inconsistencies with respect to how identifiers are ordered and compared.
mysqld --initialize --console --lower_case_table_names=2
Then you will get following error in workbench after initilizing the server again with lower_case_table_names=2:
A server configuration problem was detected. The server is in a system that does not properly support the selected lower_case_table_names option value. Some problems may occur.
show variables like lower_case_table_names;
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_table_names | 2 |
So conclusion: on Windows leave the setting to 1 because 0 or 2 won't work or as they put it: some problems may occur.
I do however now have my database and table names showing up with Capital letters.
Which doesnt really do much because comparison will always be :
# If set to 1, table names are stored in lowercase on disk and comparisons are not case sensitive.
# If set to 2, table names are stored as given but compared in lowercase.
Nicholas
If your data files are on a drive different than the C: drive, you may actually have 2 "my.ini" files, one will be on the C: drive and when you edit the Options in Workbench, that is the file that gets changed while the "My.ini" your system is actually working from is left alone.
Check C:\Program Data\MySQL\MySQL(server version), to see if there is an .ini file there. If so, you will probably find it has the changes at the bottom of the file that need to be written to the actual working .ini on the drive your data is really stored on.
In workbench go to : management panel > Options File > General > System >
Check the "lower_case_table_names", put value 2.
Close Workbench.
Restart Service MYSQL56
See img here How to enable
Edit this file at /etc/mysql/my.cnf
Add following lines:
[mysqld]
lower_case_table_names=1
Restart mysql sudo /etc/init.d/mysql restart
I use MySql 5.6 on Ubuntu 12.04.
I try to add a user defined global variable, that will be accessible across multiple sessions:
in ~/.my.cnf I have:
[mysqld]
lower_case_table_names=2
set-variable=my_global_variable=my_string_value
Then I restarted MySql.
When I do show variables, I do not see any variable called "my_global_variable".
What might I be missing here?
http://dev.mysql.com/doc/refman/4.1/en/option-files.html
Set the program variable var_name to the given value. This is
equivalent to --set-variable=var_name=value on the command line.
Spaces are permitted around the first “=” character but not around the
second. This syntax is deprecated as of MySQL 4.0. See Section
4.2.3.4, “Using Options to Set Program Variables”, for more information on setting program variables.
Read the MySQl 5.6 docs about the options file.
I am very new to servers in general and even cmd prompt. Anyways I downloaded MySQL and I am watching this video to set up MySQL at 8:21 in the video is my problem https://www.youtube.com/watch?v=O4xXzTIcnDE. When I type in -intmysql -u root -p i get a warning like this.
[WARNING] TIMESTAMP with implicit DEAULT value is deprecated
I found a few other post that i had to add some timestamp setting to a file. I am running 64 bit so none of these worked. Any ideas on how i can get past this timestamp issue? Thanks.
I don't think that's an error. That's just a warning. You could "turn off" that warning with a startup option (the message lines following the warning at startup tell the setting that needs to be changed...
Those nonstandard behaviors remain the default for TIMESTAMP but as of MySQL 5.6.6 are deprecated and this warning appears at startup:
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).
As indicated by the warning, to turn off the nonstandard behaviors, enable the new explicit_defaults_for_timestamp system variable at server startup. With this variable enabled, the server handles TIMESTAMP as follows instead:
http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
The options file is typically named my.cnf file, but on Windows, it may be named my.ini. (So, first, you need to know where the options file is for your installation, and then modify it,
Under the [mysql] section, add explicit_defaults_for_timestamp
[mysql]
explicit_defaults_for_timestamp
That change will become effective the next time MySQL server is started.
If you are loading scripts for tables from older versions of MySQL, those scripts may be dependent on the older, deprecated behavior.
Is there a way to enable STRICT_ALL_TABLES for a single MySQL database?
set sql_mode = 'STRICT_ALL_TABLES'; will do it.
You can set the default SQL mode by starting mysqld with the --sql-mode="modes" option, or by using sql-mode="modes" in my.cnf (Unix operating systems) or my.ini (Windows). modes is a list of different modes separated by comma (“,”) characters. The default value is empty (no modes set). The modes value also can be empty (--sql-mode="" on the command line, or sql-mode="" in my.cnf on Unix systems or in my.ini on Windows) if you want to clear it explicitly.
ref MySql Website
Don't think you can do this directly but you might get close with setting Strict for the current session when working on a particular database. Could do this in the config files of specific users.