Since the partition table needs to be able to automatically add partitions recently, event events and stored procedures need to be used; encountered some incredible problems, record the process;
event
Events are a new way of storing code introduced in MySQL 5.1. It is similar to the Linux timing task, but it is completely implemented inside MySQL. You can create events to specify that MySQL executes a certain piece of SQL code at a certain time, or executes a piece of MySQL code at regular intervals. Usually, we will encapsulate complex SQL in a stored procedure, so that the event only needs to make a simple call when it is executed.
Events are initialized in a separate event dispatcher thread that has nothing to do with the thread that handles the thread connection. It doesn't take any arguments and doesn't have any return value. You can see the execution log of the command in the MySQL log, and you can also see the status of each event in the table INFORMATION_SCHEMA.EVENTS, such as the last execution time (last_executed) of each event.
The above log can see that the event execution failed; the reason is that the column and value do not match.
The relevant status of the event can be found above; it can be seen that the creation time of the event is at 18:41 on April 4 and the execution time is at 10:42 on April 4. This seems to have not been executed, but it has actually been executed successfully, it seems The time inconsistency caused by the time zone will not have any impact on the event execution (this is what I tested);
Similarly, some of the considerations that apply to stored procedures also apply to events. First, creating events means extra work to the server. The overhead of the event implementation itself is not large, but the event needs to execute SQL, which may have a great impact on performance. Furthermore, events, like other stored procedures, can trigger the same problems when working with statement-based replication. Some typical applications of events include periodic maintenance tasks, rebuilding caches, building summary tables to simulate materialized views, or storing status values for monitoring and diagnostics.
The following example creates an event that runs a stored procedure against a database once a month;
CREATE
EVENT `NewEvent`
ON SCHEDULE EVERY 1 MONTH STARTS '2018-04-04 18:42:00'
ON COMPLETION PRESERVE
ENABLE
DO
CALL proc_add_partition();
You can specify whether the event itself is replicated. As needed, sometimes it needs to be copied, sometimes it doesn't. Sometimes you may want to run a certain SQL statement on all the standby databases, but if it runs on all the standby databases, it may affect the server performance (the table will be shackled);
If the execution of a timed event takes a long time, it may affect the server performance. Before the execution of the previous event is completed, the next event has already started. MYSQL itself does not prevent this concurrency, so we need to write anti-concurrency code in this case ourselves. The GET_LOCK() function can be used to ensure that only one event is currently running.
CREATE
EVENT `NewEvent`
ON SCHEDULE EVERY 1 MONTH STARTS '2018-04-04 18:42:00'
ON COMPLETION PRESERVE
ENABLE
DO
BEGIN
declare continue hanlder for SQLEXCEPLTION
BEGIN END;
IF GET_LOCK('table', 0) THEN
CALL proc_add_partition();
END IF;
DO RELEASE_LOCK('table');
END
The CONTINUE HANLDER here is used to ensure that all locks are still released even when the event execution fails.
Although the execution of the event has nothing to do with the connection, it is still thread-level. There is an event scheduling thread in MySQL, which must be configured in the configuration file, or use the command set global event_scheduler :=1; once the option is set, the thread will execute each segment of SQL code in each user-specified event. You can find out the situation through MySQL's error log.
Although the event dispatcher is a separate thread, the events themselves can be executed concurrently. MySQL will create a new process for event execution. In the event code, if you call the function connection_id(), it will also return a unique value, the same as the normal thread return, although the event has nothing to do with the MySQL connection thread (here connection_id() returns just the thread ID) . The process and thread life cycle here is the execution process of the event. You can view command always connect by show peocesslist;.
Although the event handler needs to create a thread to actually execute the event, the thread will be destroyed after the time execution is over, not placed in the cache, and threads_created will not be incremented.