I tried to change the status of userstat variable by going to mysql on server by ssh.
Here are my steps:
Open PuTTY
Connect by SSH
command lines:
mysql
SET GLOBAL userstat=on;
Response: ERROR 1193 (HY000): Unknown system variable 'userstat'
After that, I run this command to see all variables: SHOW VARIABLES;
As reported, there is no variable named USERSTAT.
You may be confusing VARIABLES with STATUS after reviewing the content of your question.
Both are always ON in MySQL.
Then you can
SHOW GLOBAL VARIABLES or SHOW SESSION VARIABLES that would include any 'overrides' for this 'SESSION'.
Status has available SHOW GLOBAL STATUS or SHOW SESSION STATUS that will report NUMBER of times various events have been counted.
SHOW GLOBAL STATUS reports counts since startup.
SHOW SESSION STATUS reports counts of this SESSION.
Caution, for very ACTIVE systems, counts reported by innodb_buffer_pool_read_requests ROLLOVER above ~ 4,200,000,000 and the only reliable count is recorded in information_schema.innodb_metrics row with buffer_pool_read_requests. There may be other counters from STATUS with ROLLOVER problems depending on your version of MySQL. This was true in 5.6.17 when running 64 bit version.
The VARIABLE userstat_running existed in Percona 5.1.
It was renamed to userstat in Percona 5.5.10 and MariaDB.
MySQL does not have either.
Related
Have 2 events scheduled on MySQL running on my Pi4, set as recurring neither has ever executed. They are both designed to truncate records older than xxx in two separate tables.
Server type: MariaDB
Server version: 10.3.27-MariaDB-0+deb10u1 - Raspbian 10
PHP version: 7.3.19-1~deb10u1
Have event scheduler set to always start and have verified that it is running via check. Also show process list verifies that it is running. Results of show processlist is:
6
event_scheduler
localhost
NULL
Daemon
107784
Waiting for next activation
NULL
0.000
Checked that the event_scheduler user has proper global permissions to Select, Update, Insert, and Delete.
The event is Enabled and set to recurring.
Have also verified proper SQL via query simulation which would result in proper record deletion, and have checked that the event_scheduler user has the proper permissions for the tables that I am attempting to delete records from. Have done exhaustive reading, but still no luck. Any ideas welcome and appreciated!
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?
I'm trying to move from a ISAM mysql database to an InnoDB mysql database (10's of millions of records/rows). So, I'm trying to use mysqldbexport to export just the data from the tables so that we don't need to adjust the sql files once exported. I'm trying to use the following command and it doesn't actually exclude the required tables.
mysqldbexport --server=username:password#localhost db_name --export=data --bulk-insert --exclude=db_name.table_name --output-file=full_db_name_export.sql
Originally started on version:
MySQL Utilities mysqldbexport version 1.5.6
This failed to exclude the table. It also fails to complete the export anyway, presumably due to resource (memory) limitations.
I then updated to:
MySQL Utilities mysqldbexport version 1.6.5
I now get the error:
Source on localhost: ... connected. ERROR: Query failed. 1238 (HY000): Variable 'foreign_key_checks' is a SESSION variable
I have tried using the command SET GLOBAL FOREIGN_KEY_CHECKS=0; on the mysql command line and it just complains saying that it's a SESSION variable.
Can anyone help with either fixing the issue with the first version not excluding or, help me with getting around the issue with the second version? Or better yet, give me a "lmgtfy" link that works :)
I also got this error using mysqldbcopy,you could solve it by 2 ways:
1.upgrade destination MySQL to a higher version that supporting syntax--SET GLOBAL FOREIGN_KEY_CHECKS=0
2.comemnt out this line destination.disable_foreign_key_checks(True) in source file .../site-packages/mysql/utilities/command/dbexport.py
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.
How to find mysql DB is slave with out using "show slave status" by query?
Here are 3 options you have to detect if Replication is running
OPTION #1 : Check Status Variable 'Slave_running'
Using MySQL 5.1/5.5
select variable_value from information_schema.global_status
where variable_name = 'Slave_running';
Using MySQL 5.0 and back
SHOW VARIABLES LIKE 'Slave_running';
OPTION #2 : Check the Process List
Using MySQL 5.1+/5.5
select COUNT(1) SlaveThreads
from information_schema.processlist
where user = 'system user';
If SlaveThreads = 2, Replication is Running
If SlaveThreads = 1, Replication is Broken
If SlaveThreads = 0, Replication is Stopped or Disabled
Using MySQL 5.0 and back
SHOW PROCESSLIST;
Look for 2 DB Conenctions thaty have 'system user' in the user column.
OPTION #3 : Check for presence of master.info
If replication is setup on a DB Server, look for master.info. By default, master.info is usually in /var/lib/mysql or wherever datadir is defined.
Simply run 'cat master.info' multiple times (For Windows community, type master.info). If the log position is moving, replication is on. If the log position is not moving, it could mean that replication is either broken (SQL Error in SQL Thread), stopped (due to STOP SLAVE;), or disabled (by running CHANGE MASTER TO MASTER_HOST='';).
According to MySQL doc - Checking Replication Status:
Slave_IO_Running: Whether the I/O
thread for reading the master's binary
log is running. Normally, you want
this to be Yes unless you have not yet
started replication or have explicitly
stopped it with STOP SLAVE.
Slave_SQL_Running: Whether the SQL
thread for executing events in the
relay log is running. As with the I/O
thread, this should normally be Yes.
Prior to MySQL 5.7, you can check the 'slave_running' variable by executing the following query:
SHOW GLOBAL STATUS LIKE 'slave_running';
Since MySQL 5.7, the slave_running has been removed and the above query returns an empty set
You can enable "show_compatibility_56" to get the value but “show_compatibility_56” is deprecated and will be removed soon. The reason for this is because MySQL is moving away from the information_schema GLOBAL_STATUS and SESSION_STATUS tables in preference for performance_schema.
The correct way to get the status of the slave running in MySQL 5.7 outside of SHOW SLAVE STATUS is to use the new replication-based performance_schema tables.
You can execute the following query to get the status of the replication service:
SELECT SERVICE_STATE FROM performance_schema.replication_connection_status;