Slave replication terribly slow after upgrading to 10.1 with a 10.0 master - Source

Revision: 93370
User: Martijn van Buijtene
Date: 2020-02-19 15:45

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

Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.

Slave replication terribly slow after upgrading to 10.1 with a 10.0 master - Source

Answer

Products

Services

Pricing

Resources

About Us

Download MariaDB