Eventually managed to solve this (e. g. get Percona to stop so it can be backed up) by doing the following.
1. I set innodb_fast_shutdown to 2 (e. g. execute the fastest shutdown possible.)
Code:
set global innodb_fast_shutdown = 2;
in the MySQL CLI.
2. I set innodb_max_dirty_pages_pct to 0
Code:
set global innodb_max_dirty_pages_pct = 0;
3. Wait until innodb_max_dirty_pages is 0:
Code:
show status like '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 1 |
| Innodb_buffer_pool_bytes_dirty | 16384 |
+--------------------------------+-------+
2 rows in set (0.15 sec)
mysql>
and wait until the dirty pages reach 0.
4. Then, stop the server:
Code:
# systemctl disable mysqld
# systemctl stop mysqld
# systemctl enable mysqld
5. Now copy /var/lib/mysql to backup location:
Code:
# rsync -avh --progress --no-whole-file --partial /var/lib/mysql/* /mnt/backup/mysql_backup_2020_02_19/.
6. Restart Percona:
Code:
# systemctl start mysqld
7. MySQL will now do a recovery due to it being shutdown uncleanly using innodb_fast_shutdown = 2.
However, this recovery is guaranteed to work as it was requested to do a fast shutdown by setting innodb_fast_shutdown = 2 before requesting it to stop itself.
8. Similarly, I then tested the backed-up database on another server by copying it into that server's /var/lib/mysql directory (after removing the old databasse), and then trying to start the same version of Percona / MySQL on it.
That worked as well, and the recovery there was exactly the same as on the live server. It also worked perfectly.
E. g. it is not necessary to shut down the Percona / MySQL DB instance cleanly to be able to back it up. It can be shut down with an emergency shutdown which is 1000s of times faster by first setting innodb_fast_shutdown = 2 in the MySQL CLI, then doing a shutdown, and then copying the database directory.
The only problem is that there MUST be a recovery done first if you ever restore that backup in an emergency when your primary server is blown or you lost the database. Apparently the recovery times can get extreme if you have a very large buffer pool or innodb log file, but mine is relatively tine (10GB buffer pool and 680MB log file) so recovery is virtually instantaneous on an SSD with a Core i7.
Hope this helps somebody - you don't NEED to wait possibly hours and hours for MySQL to shut down with innodb_fast_shutdown = 0, you can shut down uncleanly with innodb_fast_shutdown = 2, and the recovery when you restore the emergency-stopped database is very very fast, vs. the hours and hours you might wait (or waiting forever) for the DB to stop cleanly with a innodb_fast_shutdown = 0 shutdown.