MySQL stops in windows VM and shows innodb error log sequence number is in future

2020-08-28 16:46:02 d64 InnoDB: Error: page 1 log sequence number 23113680
InnoDB: is in the future! Current system log sequence number 3181581.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.

I’m using VM and OS is Windows Server 2016 and Uniform Server.
MySQL stops upon this error and doesn’t work until it is restarted.
After restarting, it runs for some hours and stops again.
I have tried moving ib_logfile but still it didn’t help.
How to overcome this?

Go to Source
Author: Anushree Bharadwaj

Is it normal for MySQL to gradually increase memory usage over time?

Is it normal for MySQL to increase memory usage over time? See image below of my server’s memory usage over the last two weeks. After “service mysql restart” it drops to 40%. The database is used by a node.js app.

Server has 4GB of RAM with below additions to mysqld.cnf:

innodb_ft_min_token_size = 1
ft_min_word_len = 1
innodb_buffer_pool_size = 3G
innodb_buffer_pool_instances = 5
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT
max_connections = 300
long_query_time = 1
innodb_ft_enable_stopword = 0

Thank you!

Go to Source
Author: steven

MySQL InnoDB Weird Query Performance

I designed two tables, both using InnoDB.

The first one has columns “Offset, Size, and ColumnToBeIndexed” with BIGINT “Offset” being the primary key, and the second one has columns “OffsetAndSize, and ColumnToBeIndexed” with BIGINT “OffsetAndSize” being the primary key. And there are both 15 millions rows in each table.

I added indexes to both tables on “ColumnToBeIndexed.

My two queries for them are

SELECT Offset, Size 
FROM someTable 
WHERE ColumnToBeIndex BETWEEN 20 AND 10000 
ORDER BY Offset ASC

and

SELECT OffsetAndSize 
FROM someTable 
WHERE ColumnToBeIndex BETWEEN 20 AND 10000 
ORDER BY OffsetAndSize ASC

Because the second query could use the secondary index and does not need to look up the clustered index to find the “size” information, I expected that the second query on the second table performs better than the first query on the first table. However, as the test came out, it turned out that the first query performs better every single time.

Does anybody out there know what seems to be the problem?

Go to Source
Author: Bruce