Marko Mäkelä added a comment - 2024-11-22 06:31 MariaDB Server 10.11.3 was released in May 2023. Since then, there have been many bug fixes. One of them is MDEV-32511 , which was a regression due to MDEV-26827 . That bug alone could explain basically any corruption. It is somewhat hard to repeat; you would need to execute mariadb-backup --backup or kill the server just at the right moment, while a log checkpoint is in progress. That is just one example; there could be other bugs that could explain this. Can you reproduce this corruption with a more recent version of MariaDB Server, such as 10.11.10?

baek seung ho added a comment - 2024-11-25 06:57 We didn't run backup and insert that table at the same time. The `message` table is batch table and batch is running at 02:00 and mariabackup is running at 20:00. Is there other reasons that table is corrupted?

baek seung ho added a comment - 2024-12-09 08:51 - edited After the index was corrupted on 2024-11-20, the index was corrupted again. It is the same table as last time, and it is a table used only in batches. 2024 - 12 - 07 1 : 57 : 45 11642302 [ERROR] mariadbd: Index for table 'message' is corrupt; try to repair it 2024 - 12 - 07 1 : 57 : 45 11642301 [ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace. If the mariadbd server crashes after the startup or when you dump the tables. Please refer to https: //mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. I've attached the table creation syntax and query syntax. The number of variables used in the query is 320, the time required is less than 0.1 seconds, and it is performed a total of 5 times. For reference, in another service environment that uses the same table, 870 variables are used, but the index has not been corrupted yet.