Copyright © 2019 MariaDB. All rights reserved.
A reminder to set `innodb_fast_shutdown` to `0` would be helpful. Otherwise the upgrade may result in the following situation:
[ERROR] InnoDB: Upgrade after a crash is not supported. This redo log was created before MariaDB 10.2.2, and we did not find a valid checkpoint. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading.html
I was only able to complete the upgrade from 10.1 by moving the old binary logs ( `/var/lib/mysql/ib_logfile*`) out of the way, thus letting MariaDB 10.2 create new ones.
A shutdown with the default setting innodb_fast_shutdown=1 is sufficient before an upgrade. It will create a redo log checkpoint, so that the redo log will be logically empty.
If there is a bug in MariaDB 10.2 or later that causes it to incorrectly refuse an upgrade from 10.1 (failing to detect the redo log as logically empty), please file a bug for it.
The InnoDB redo log (ib_logfile0) works at a lower level than the binary logs (binlog).
Last, a slow shutdown before upgrading MariaDB is not necessary. It is necessary when upgrading to MySQL 5.7 or 8.0, because in both versions, the undo log format was changed in an incompatible way. In MariaDB, the InnoDB undo log format is compatible with earlier versions. MDEV-12289 in MariaDB 10.2 guarantees a smooth upgrade from earlier MariaDB versions, but creates an undo log format incompatibility with Oracle MySQL 5.7 and Percona XtraBackup 2.4.
Alas, due to bugs, MySQL would not always empty all undo logs as part of a slow shutdown. In MariaDB Server 10.3, MDEV-13603 was fixed. In earlier versions, various shutdown hangs have been fixed. (Maybe your 10.1 server hung during shutdown, and it was forcibly killed, so that crash recovery would have been needed?)