I used XtraBackup to do a partial backup, a single database from MariaDB 5.5 to MariaDB 10.1. I performed “alter table db.table discard tablespace;” moved .ibd file in place and “alter table db.table import tablespace;” I then start MariaDB and it starts fine. I am able to connect, perform queries etc. When I look at TOP I see the MySQLd process pegged at 100%. I go look at SHOW FULL PROCESSLIST and there no queries. In fact I don’t even have the firewall ports open to allow incoming traffic to the database from the application over port 3306. If I stop mysql and then start it back to 100% CPU. No DISK IO, NO memory delta, just straight 100% CPU.
I have performed these steps in the past and been both successful and have seen this error before. I do not know I how fixed the issue. I could be wrong about this but I seem to remember it having to do with a TIME sync or TIME ZONE issue. Where the innodb position was in the future from the original database source. I am trying jog anyone’s memory.
I found the problem is related something with ibdata1 file. The strange thing is everything is fine in terms of being able to see data in the databases. Maybe ibdata1 is corrupt? What is the best way to repair ibdata1 file?
I was able to rebuild ibdata1 by removing that file and doing a series, “alter table db.table discard tablespace;” “alter table db.table import tablespace;”. After that CPU was holding around 0.1% activity. I proceeded bring back online my secondary MariaDB server back into the cluster. Everything looked fine when I was completed. This morning I reviewed the cluster to make sure everything was working as it should be. Now the primary server is back to 100% CPU usage while the secondary server is looking fine I am at a loss as to why the CPU is going back to 100% without any activity. Before I started this endevour both servers were running 100% CPU, this is something different. I have copied out the mysql log data to trace back the events from evening. Nothing stands out at the moment but still investigating.