Hi I am facing issues regarding adding mysql events in mysql
even switched on event scheduler status
it shows event created but nothing is been added
i am using mysql phpmyadmin
Events are run by the scheduler, it's not started by default. Using SHOW PROCESSLIST command it is possible to check whether it started or not. if its not started then run the command before your query in phpmyadmin.
SET GLOBAL event_scheduler = ON;
or you can check mysql.cnf file set event_schedler = ON for permanent solution
[mysqld]
event_scheduler = ON
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.
We have 8 phusion passengers with 20 connections each. should be 160 max connection. Today our Mysql connection crossed 300 and our server stopped responding.
What would happen if the thread dies unnaturally ? how do db connections associated with it get cleaned-up?
How to debug this type of scenario ?
What would happen if the thread dies unnaturally ?
If you are using your statements under transaction then all statements under un-successful transactions will be rolled back but if you are executing your statements individually then how many have been executed will be saved in db but other un-successful will not and data can be in-consistant.
how do db connections associated with it get cleaned-up?
As per my assumption your application is opening connections more than required and also not closing properly. In this case if you check connections in mysql admininstrator then you will get so many connections in sleep mode. So you can kill all sleep connections to clean them.
How to debug this type of scenario ?
Step1: Enable general logs on your server:
Step2: execute below command in any gui tool like sqlyog etc.
show full processlist;
Step3: Take first sleep process from above command:
Step3: find/grep above process id (suppose it is 235798) in your general log. You can use below command.
$ cat /var/log/mysqldquery.log | grep 235798
Note: there can be different file name and path for your general log file.
Above command will show you few lines, check if you are closing connection at the end, should show "quite" statement at the end of line. In this way you need to check few processes those are in sleep mode and you can jugde which type statements/from which module opening extra connectiions and not closing and accordingly you can take action.
I have added the following simple test event on my mysql database via phpmyadmin:
CREATE DEFINER=`root`#`localhost` EVENT `my_event`
ON SCHEDULE EVERY 1 MINUTE STARTS '2013-05-27 00:00:00'
ON COMPLETION NOT PRESERVE ENABLE DO
BEGIN
UPDATE `test` SET `name`="z";
END
My environment is mac + MAMP Pro. I am expecting to change all rows on my 'test' table with name 'z' within a minute. But not happening so.
Do I have to something additional to get my events start working?
Output of "SHOW PROCESSLIST":
Thanks.
Events are run by the scheduler, which is not started by default.
Using SHOW PROCESSLIST is possible to check whether it is started. If not, run the command
SET GLOBAL event_scheduler = ON;
to run it.
Verify if the event_scheduler is On - execute the following command:
SHOW PROCESSLIST;
It'll output a table/entries, you must look for an entry with User event_scheduler, and Command Daemon:
Id User Host db Command Time State Info
22870 event_scheduler localhost \N Daemon 23 Waiting for next activation \N
OR, you can also verify using the following command:
SELECT ##global.event_scheduler;
The result should be ON, otherwise set it off (will get 0 for the command), as stated in the next section.
If you don't have any such entry (as above), you may start the event scheduler using the following command:
SET GLOBAL event_scheduler = ON;
Once done, you can verify if it has been executed properly using the SHOW PROCESSLIST command, as mentioned above.
For those wondering how to enable it by default at startup, add the following to your config file (my.ini, my.cnf):
#Event scheduler can be set to 1 (On), 0 (Off), or Disabled
event_scheduler=1
Restart of the service is required in this case, so if you want minimal disruption, add this to the config file, and then run the SQL:
SET GLOBAL event_scheduler = ON;
That way, it will run for the current process, and if the server is restarted it will still work.
Note that this doesn't work if the event_scheduler was set to disabled. In that case the only option is to restart the service.
If you want your event_scheduler to startup automatically every time mysql server restarts, anywhere under the [mysqld] section of the my.ini or my.cnf file that you find in /etc/mysql you should place
[mysqld]
# turning on event_scheduler
event_scheduler=ON
restart mysql to check if it is running (in command line terminal!)
sudo service mysql restart
then check your processlist
SHOW PROCESSLIST
you can check if your events are running by checking the last time they ran
SELECT * FROM INFORMATION_SCHEMA.events
Temporal
SET GLOBAL event_scheduler = ON;
Will not work if event_scheduler is explicitly DISABLED, see the method below
Permanent (needs restart)
In your config file (In Ubuntu it's /etc/mysql/mysql.cnf):
[mysqld]
event_scheduler = ON
Notes:
The event_scheduler variable can have this possible states:
OFF (or 0) (default)
ON (or 1)
DISABLED: you cannot use the temporal enabling, you can only change state through the config file and restarting the server
WARNING: Keywords ON / OFF are preferred over their numerical equivalents.
And in fact Mysql Workbench doesn't recognize the configuration event_scheduler=1, it shows as OFF in the Options File section.
Tested in Ubuntu with Mysql Workbench 8.0.17 and Mysql Server 5.7.27
Although ON and OFF have numeric equivalents, the value
displayed for event_scheduler by SELECT or SHOW VARIABLES is always
one of OFF, ON, or DISABLED. DISABLED has no numeric
equivalent. For this reason, ON and OFF are usually preferred
over 1 and 0 when setting this variable.
Source: https://dev.mysql.com/doc/refman/5.7/en/events-configuration.html
I just figured out that on MariaDB, after adding an event (in my case, it was the first one), you have to restart the event-scheduler
SET GLOBAL event_scheduler = OFF;
and then
SET GLOBAL event_scheduler = ON;
to make it actually bring the scheduler into "waiting for activation"-state.
I would just like to add to this thread. I dumped my database to another server and as a result the definer of my event had no such grant defined for the user. I updated my definer with
ALTER DEFINER='root'#'localhost' EVENT event.name COMMENT '';
Make sure your definer has the correct PRIVILEGES.
Remember to add in 'Commit', after 'DO BEGIN' or 'DO'. Works for me after that.
Try
SET GLOBAL event_scheduler = ON;
DELIMITER $$
CREATE DEFINER=`root`#`db01` EVENT `PRICEALERT_STATUS`
ON SCHEDULE EVERY 1 DAY STARTS TIMESTAMP(CURRENT_DATE)
DO BEGIN
// Your Query
END $$
DELIMITER ;
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;