Slave replication terribly slow after upgrading to 10.1 with a 10.0 master
We run mariadb 10.0.30 servers.
Recently we reinstalled a slave (which also had 10.0.30) with Ubuntu18, and copied the /mysql and /mysqllog folders from another slave to this new 10.1.43 Ubuntu18 slave.
After a lot of complaints in the error logs upgrade the the databases with a 'mysql_upgrade'and left us with :
[Warning] InnoDB: Cannot open table mysql/engine_cost from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem. 2020-02-04 11:35:27 140608938985216 [Warning] InnoDB: Cannot open table mysql/gtid_executed from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem. 2020-02-04 11:35:27 140608938985216 [Warning] InnoDB: Cannot open table mysql/server_cost from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem. 2020-02-04 11:35:27 140608938985216 [Warning] InnoDB: Cannot open table mysql/slave_master_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem. 2020-02-04 11:35:27 140608938985216 [Warning] InnoDB: Cannot open table mysql/slave_relay_log_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem. 2020-02-04 11:35:27 140608938985216 [Warning] InnoDB: Cannot open table mysql/slave_worker_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
After ignoring these warning we started the slave, and it would never catch up! And only starts lagging behind more and more....
We separate disks for /mysqllog and /mysql and i noticed the io-utilization on the /mysqllog disk is near 100%. The disk layout is the same as it was on Ubuntu14 and mariadb 10.0.30.
This breaks our planned upgrade.
Answer Answered by Ian Gilfillan in this comment.
I suggest following the steps on Upgrading from MariaDB 10.0 to MariaDB 10.1 to reduce the chances of problems when upgrading.
