Disable MySQL general logging without restarting? - mysql

Can I disable general logging completely without restarting the server?
Because, per the documentation:
SET sql_log_bin = {0|1}
Disables or enables binary logging for the current connection (sql_log_bin is a session variable) if the client has the SUPER privilege. The statement is refused with an error if the client does not have that privilege.
Can I enable/disable general log without restarting MySQL?

For anyone using 5.1 now, you can use these commands (had to look them up and this Q&A came up)
SET GLOBAL log_output='TABLE'; #or FILE
SET GLOBAL general_log='OFF'; #or ON
SET GLOBAL slow_query_log='ON'; #or OFF
TABLE will store them in the mysql.general_log and mysql.slow_log tables instead of files which is nice in development for reviewing and truncating.

For MySQL 5.0 "The session sql_log_off variable can be set to ON or OFF to disable or enable general query logging for the current connection." [MySQL Doc, Log file]

Related

How to use init_connect in azure database server for mysql

Have created a mysql server which has somehow log_bin set to ON and enforce_gtid_consistency is also set to ON. Now this is causing few issues in my case and i want to turn OFF those variables.
Process i have tried
1. Create a .my.cnf file in user root (~/.my.cnf) and added
[mysqld]
enforce_gtid_consistency=OFF
Result: No changes. It doesnt take effect.
2. In azure portal in init_connect variable i have set "SET enforce_gtid_consistency=OFF;" (because there is no mention of this variable in server parameters).
Result: Cant connect to mysql after setting up value in this parameter.
Is there any way we can fix this?
May be the following doc is helpful:
https://learn.microsoft.com/en-us/azure/mysql/concepts-read-replicas#global-transaction-identifier-gtid
Once GTID is enabled, you cannot turn it back off. If you need to turn GTID OFF, please contact support.

Mysql 5.7.21 inconsistent only_full_group_by behavior with EF6 and Mysql Connector 6.9.9

We just upgraded our Mysql db from 5.6 to 5.7.21.
Then all the sql statements that are written against sql_mode:only_full_group_by gave error. That's the normal behavior of Mysql 5.7.21 because sql_mode parameter in my.ini was set to "ONLY_FULL_GROUP_BY".
Then we set this parameter to empty string ("") in my.ini and restarted server again. Everything seemed normal for just a 1 or 2 minutes , then the same queries began to give only_full_group_by error again.
We are still trying to find a solution without touching our codebase bu we couldn't yet.
You can see a live exmaple in this link
Please refreseh the page 10 times or more to get the page work.
http://www.karoltekstil.com.tr/atlet-ust-giyim/k/10-42?page=1
Each MySQL session (database connection) has its own setting for sql_mode.
When a new session is started (a new connection is made to the database), the sql_mode session variable inherits the setting of the global sql_mode setting.
While a session is running, it can change the setting of its own sql_mode, for example by issuing a statement like this:
SET ##session.sql_mode = 'ONLY_FULL_GROUP_BY' ;
The new value of sql_mode remains in effect for that session, until it is changed again, or until the session ends.
A user with sufficient privilege can also change the global setting of sql_mode, with a statement like this for example:
SET ##global.sql_mode = 'ONLY_FULL_GROUP_BY' ;
Any change made the global setting only affects new sessions (connections started after the change is applied.) Changes to the global setting don't influence sessions that are already started. The existing sessions already have their "copy" of sql_mode that was inherited when the connection was started.
Note that ONLY_FULL_GROUP_BY can be explicit in sql_mode, or it can be included implicitly in a combination setting. For example, sql_mode='ANSI' includes ONLY_FULL_GROUP_BY.
MySQL startup has a variety of locations that it reads configuration information from, whether that's my.ini, my.cnf, or options provided on the command line of the startup.
Next steps in debugging this is to determine if sql_mode is being set properly when the database starts, and then determine if there are statements being executed in individual sessions that change the setting of sql_mode.
Is the application churning database connections, starting and ending discrete sessions?
Or is the application using a connection pool, persistent connections that are borrowed and returned from the pool?

How to enable --general-log without restarting the MYSQL server?

According to the mysql documentation this flag is possible to change dynamically.
Property Value
Command-Line Format --general-log
System Variable general_log
Scope Global
Dynamic Yes
SET_VAR Hint Applies No
Type Boolean
Default Value OFF
But by default this option is disabled. But I need to enable this flag in order to see the logs without restarting the server. What is the way to enable this without restarting the server.
MySQL provides a System variable general_log, which specifies whether the general query log is enabled or not. You will just need to execute the following queries to enable GLOBAL logging (for all the other client sessions as well):
SET GLOBAL general_log = 'ON';
You can also specify the log file path:
SET GLOBAL general_log_file = '/var/log/mysql/all.log';
Remember that when you restart the server, these settings will be lost. To make the changes persistent, you will have to make changes in the configuration file.
If you want to disable the general query logging, you can do the following:
SET GLOBAL general_log = 'OFF'

Enable MySQL syslog to log aborted connections and access-denied

What is the command in mysql that is required to that I can implement aborted connections and access-denied logs to be written to the syslog?
The commands are first to see what your settings are:
select ##general_log; -- a 1 indicates it is turned on for capture
select ##general_log_file; -- the file that it logs to
select ##datadir; -- directory location where the log lives
To turn logging on for the General Query Log, use the following:
SET GLOBAL general_log = 'ON'; -- 0 is off, 1 is on
Note that the datadir is read-only and requires a restart of the server after changes. Basically, don't change this. It is the home of your database schemas.
For expanded connection failures perform a
select ##log_warnings; -- make a note of your prior setting
set global log_warnings=2; -- setting above 1 increases output
The immediate above relates to the Error log written out in the same datadir.
See the Percona article Auditing login attempts in MySQL and my prior answer Here.

SET GLOBAL max_allowed_packet doesn't work [duplicate]

This question already has answers here:
How to change max_allowed_packet size
(14 answers)
Closed 1 year ago.
I found out how to change the default value of max_allowed_packet in MySQL using SET GLOBAL. However, each time I used this command, the default value stayed untouched!
I used these commands:
mysql --user=root --password=mypass
mysql> SET GLOBAL max_allowed_packet=32*1024*1024;
Query OK, 0 rows affected (0.00 secs)
mysql> SHOW VARIABLES max_allowed_packet;
And then the result is max_allowed_packet = 1048576. What am I missing?
Hmmmm.. You have hit this NOT-A-BUG it seems. :)
If you change a global system variable, the value is remembered and used for new
connections until the server restarts. (To make a global system variable setting
permanent, you should set it in an option file.) The change is visible to any client that
accesses that global variable. However, the change affects the corresponding session
variable only for clients that connect after the change. The global variable change does
not affect the session variable for any client that is currently connected (not even that
of the client that issues the SET GLOBAL statement).
Refer this too. Read Shane Bester explanation.
You should change from the my.ini/my.cnf file and restart the server for the max_allowed_packet setting to take effect.
After running
set global max_allowed_packet=1000000000;
you have to restart mysql before
SHOW VARIABLES LIKE 'max_allowed_packet'
will show the new value.
I have this issue when restarting mysql through the MAC OSX system preferences and the value hadn't changed. So by logging into mysql via console
mysql -u root -p
changing it and then restarting mySql seemed to work. Might have been a OS X quirk though.
For those with a MariaDb configuration the problem could be that the max_allowed_packet variable is overwritten by a configuration file called later.
In my case I tried to import a database and the server answered me:
ERROR 2006 (HY000) at line 736: MySQL server has gone away
I discovered that the file:
/etc/mysql/mariadb.conf.d/50-server.cnf
is called later
/etc/mysql/conf.d/mysql.cnf
I tried continuously changing in the "mysql.cnf" file but the value was overwritten in "50-server.cnf".
So the solution is to enter the file
/etc/mysql/mariadb.conf.d/50-server.cnf
and instead of
"max_allowed_packet = 16M"
put the desired value as an example
"max_allowed_packet = 64M"
I came across this problem as well and in my case I have multiple versions of MySql installed.
Adding this note for anyone who might have setup MySql using homebrew on mac and are having trouble setting max_allowed_packet value in your my.cnf file.
The most key information that helped was that the my.cnf file can be present in different locations (excerpt from https://github.com/rajivkanaujia/alphaworks/wiki/Install-MySQL-using-Homebrew) -
/usr/local/etc/my.cnf --> Global Access
/usr/local/etc/my.cnf --> Global Access
/usr/local/Cellar/mysql/5.7.18/my.cnf --> Sever Level Access
~/.my.cnf --> User Level Access
Since I installed MySql 5.6 via Home brew I found it at -
/usr/local/Cellar/mysql\#5.6/5.6.43/my.cnf
Steps followed -
Update the /usr/local/Cellar/mysql\#5.6/5.6.43/my.cnf file under [mysqld] group with the necessary max_allowed_packet value -
[mysqld]
max_allowed_packet=5G
Restart mysql using brew services -
brew services restart mysql#5.6
Connect/Reconnect to the mysql shell and verify that the configuration has taken effect using -
show variables like 'max_allowed_packet';
Just a quick way to see the variable for anybody who comes across this. To get the value back you need to run
SHOW VARIABLES LIKE 'max_allowed_packet'