MariaDB log_error variable - mysql

In WAMPs MySQL my.ini file you can specify the location of the mysql error log file, but if I try setting this variable in the my.ini of MariaDB it will not start. I assume it is not recognizing the variable, which worked fine in WAMP.
How do I set the MySQL error log file when using MariaDB?

MariaDB uses a separate option called log-basename
--log-basename=name (for example if name is mypc then mypc.err will be created as a error log)
Basename for all log files and the .pid file. This sets all log file names at once (in 'datadir') and is normally the only option you need for specifying log files.
This is especially recommend to be set if you are using replication as it ensures that your log file names are not depending on your host name. Sets names for --log-bin, --log-bin-index,--relay-log, --relay-log-index, --general-log-file, --log-slow-query-log-file, --log-error-file, and --pid-file.

Related

lower_case_table_names set to 2, Workbench still does not allow lowercase database name

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

MySql General Query Log

Does restarting the MySQL service on Linux, disables the already enabled general query logging?
There was a log file getting generated inside the data folder, and it was growing exponentially. The db has 100 requests per minute.
Initially i guessed, some transaction had broken in between, that made the logs to swell.
So i restarted the service, which stopped adding to that log file.
I checked the global variables and got to know the path was assigned for general_log_file. But now it was showing 'OFF'.
Hence my query
It's a common issue that people will set configuration of MySQL through dynamic (global) variables and forget to set the variables in the options file (my.conf). In that case, when the server is restarted, MySQL will revert to default settings.
The default setting for general_log is OFF. To immediately enable the general query log, set the global variable to ON. Then set the value for general-log in your my.conf file to ensure that the setting is applied whenever you restart MySQL server.
No, Restarting the server doesn't make the binary logs to OFF...
It may be the case that you changed the configuration file before and now restart takes that file...
MySQL will start with whatever options are in the file configuration. If you switched any of the global server variables before, they will be reverted to what is set in the file.

com.mysql.jdbc.PacketTooBigException

I am storing images in MYSQL.
I have table as
CREATE TABLE myTable (id INT, myImage BLOB);
When I am trying to insert 4.7MB file, I am getting exception as
com.mysql.jdbc.PacketTooBigException: Packet for query is too large (4996552 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.
I believe this is related to image size only. Is there any other variable type that I can use?
Update 1
As per older SO question, I also tried with MEDIUMBLOB but still I am getting same error.
Adding Image to a database in Java
Update 2
At the start of the project, I execute below query and everything is working now
SET GLOBAL max_allowed_packet = 1024*1024*14;
As the error says, it has nothing to do with variable type but rather the max_allowed_packet variable:
You must increase this value if you are using large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for max_allowed_packet is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.
But, generally speaking, don't store files in your database - store them in your filesystem and record the path to the file in the database.
For Windows users:
mysql_home points to your mysql/mariadb installation folder.
open cmd, cd to %mysql_home%\bin and run mysqladmin > temp.txt This will spit out a lot of information about the usage of the tool. Somewhere among all that output you will find this information:
Default options are read from the following files in the given order:
C:\windows\my.ini C:\windows\my.cnf C:\my.ini C:\my.cnf c:\mariadb-5.5.29-w
inx64\my.ini c:\mariadb-5.5.29-winx64\my.cnf
This shows that you could have, if you don't have it already, a file called my.ini or my.conf in the %mysql_home% directory.
create my.ini and add the lines:
[mysqld]
#allow larger BLOBs to be stored
max_allowed_packet = 10M
make sure to include the settings group which is [mysqld] otherwise it will fail to start (and for me it ended up hanging in limbo).
You will now need to restart the MySQL daemon, this is done either by killing and starting the currently running mysqld process or by restarting the MySQL service (run services.msc, locate MySQL, press the restart button; or from cmd, net stop MySQL followed by net start MySQL).
Following worked for me
edit my.cnf file ( mine was in /etc/mysql )
Then modify the max_allowed_packet value
I set it to
max_allowed_packet=200M
Make sure you restart MySQL for change to take effect
If working with AWS RDS, max_allowed_packet can be modified using DB Parameter Groups
The max_allowed_packet variable has a default value set in the configuration file (my.ini in my case). If your application tries to execute a query whose packet size exceeds this value, this exception is thrown.
My setup is on a Windows 10 machine with MySQL Server 8.0.
I copied the my.ini file with my desired value (64M) for max_allowed_packet to the various possible locations (C:\my.ini, C:\Windows\my.ini). Then restarted the mysql server. It didn't work. When I queried the database for the max_allowed_packet variable, the value remained unchanged.
The following steps worked:
I discovered that there is a my.ini file at a different location.
Open the my.ini file at the following location C:\ProgramData\MySQL\MySQL Server 8.0. This has lots of entries, besides max_allowed_packet.
Locate the entry for max_allowed_packet, and set it to the desired value (for e.g. 64M).
Save and close the my.ini file.
Restart the MySQL80 service.
Log into to the mysql server prompt and run the query
show variables like 'max_allowed_packet';
You should see the value set to your desired value.

WAMP server. Very large data directory in MySQL?

I have problem with wammp server.
In directory "..\WampServer\bin\mysql\mysql5.5.8\data" was created files with very large size.
Full size of this directory is 50GB. What is these files? How can I fix this problem?
The names of files are:
mysql-bin.000001
mysql-bin.000002
................
mysql-bin.000227
The size of all files is 49GB
Thanks in advance!
By default whenever you make a change to a MySQL database it creates a log of the query and stores it in a file simlare to mysql-bin.000001. The MySQL database does this so that you can recover or replicate a database. Most applications this is a good things to have enabled just like doing regular backups.
If you want to disable MySQL from creating these binary logs:
Open my.ini
Search for this line log-bin=mysql-bin
Comment this line out by adding a hash mark: # log-bin=mysql-bin
Save and restart the MySQL database
You can now safely delete these files from that directory.
I did another thing on my wamp...
http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html
Start a command prompt and goto directory wamp\bin\mysql\mysql5.5.16 or whatever version number you got
type:
mysql.exe -u root
SHOW BINARY LOGS;
a list with all the log files will be show up. We need the last one.
In my case was mysql-bin.000412
so i typed
PURGE BINARY LOGS TO 'mysql-bin.000412';
and you are ok!

Moving binary logs in MySQL to a different hard disk

This question is about MySQL binary logs.
We need to move a binary log to a different hard disk.
What is the configuration change required in MySQL?
Currently binary logs go into the same folder as the ibdata and there is a replication slave running which needs the binary logs.
Changing the log-bin works. BUT you need to copy the log-bin files first to the new location and modify the index file. If you dont'do this you will break your remote slave with the error:
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
More info here:
http://freebsd.down-to-details.com/sys-admin/relocating-moving-mysql-binlogs/
From the way I read the doc, you can specify a path on the log-bin config.
To enable the binary log, start the
server with the --log-bin[=base_name]
option. If no base_name value is
given, the default name is the value
of the pid-file option (which by
default is the name of host machine)
followed by -bin. If the basename is
given, the server writes the file in
the data directory unless the basename
is given with a leading absolute path
name to specify a different directory.
It is recommended that you specify a
basename; see Section C.5.8, “Known
Issues in MySQL”, for the reason.