Native JSON support wasn't introduced until MySQL 5.7 so you're out of luck if you're still running [the six-year-old] version 5.6.
I have to question why this is being stored as JSON in the first place.
This looks to me like perfectly normal, relational-style Data that could be stored in a conventional table structure:
create table table1
( id int ...
( SELECT @starting_deviation num
SELECT num + @delta_deviation
WHERE num < @final_deviation )
JOIN cte ON invoices.due_date = CURRENT_DATE + INTERVAL cte.num DAY
For the query from the question @starting_deviation := 5, @delta_deviation := 5 and @final_deviation := 15. These ...
The sentence about requiring a checkpoint before the log file rotation/reuse may have been removed from documentation, but the logic hasn't changed in version 5.6 -- you cannot overwrite log records that belong to not-yet-persisted data, so you have to checkpoint still. The fact that it is happening in your environment indicates that flushing of dirty pages ...
When InnoDB add an index it adds a record to I_S.INNODB_SYS_INDEXES. INDEX_ID of a new index will be highest. Analyzing existing records you can get an idea in what order indexes where created, but that's it. INNODB_SYS_INDEXES doesn't contain any time fields.
On other hand, any DML will be logged to a binlog. If it's enabled and it hasn't been rotated yet ...
I created a minimal, complete, and verifiable example for your query.
CREATE TABLE oss_collection_history
, Balance int
, DateFrom date
INSERT INTO oss_collection_history VALUES (1, 1, '2019-01-01');
INSERT INTO oss_collection_history VALUES (1, 2, '2019-01-02');
INSERT INTO oss_collection_history VALUES (2, 1, '2019-01-03');
Since your other slaves are running fine, this is possibly caused by user error. Some row was probably changed on this slave manually, which was meant to be changed on the master. The slave then encounters something like duplicate key constraint 10 times and fails. If the transaction causing this error is slow or it effects a lot of rows combined with ROW ...
This below worked for me:
WHERE table_schema = 'mydatabase'
and COLUMN_NAME = 'mycolumn'
AND table_name = 'mytable' LIMIT 1;
set @query = IF(@exist <= 0, 'ALTER TABLE mydatabase.`mytable` ADD COLUMN `mycolumn` MEDIUMTEXT NULL',
'select \'Column Exists\' status');...
And if you want to avoid a UNION - not certain of performance here, but this might be better (see fiddle here) - you don't have to query the table twice as for @Akina's query! You might want to check with a large dataset.
Create and populate table:
CREATE table pat_dis
INSERT INTO pat_dis VALUES
( 1, 2, 1.1),
( 1, 5, ...
RHEL7 uses systemd.
Using the OOMScoreAdjust as follows:
sudo systemctl edit mysqld.service
Note: I'm not sure of the exact service name
Add the following text:
systemctl restart mysqld.service
Check by looking at the score:
cat /proc/$(pidof mysqld)/oom_score_adj
Do you have INDEX(COMPONENT_NAME, UPDATE_DATE) with the columns in that order? (Please provide SHOW CREATE TABLE.)
What else was running at the same time? (SHOW PROCESSLIST before the DELETE times out.)
Let's see that other query; perhaps it can be optimized to run faster.
What is the value of autocommit? Are you using BEGIN...COMMIT?