So, it appears Chewett wasn't aware that the DB backup was causing an issue like this. Working under the assumption that MD is non-responsive due to the SQL server being slammed by the dump, I was instructed to look into the details and present my findings.
My proposed solution is to add the --single-transaction option to the invocation of mysqldump. The --single-transaction parameter is to ensure a single, consistent, state is backed up. It also means that every table doesn't have to be locked while the backup is occurring. It should be noted that MyISAM tables, as they don't support transactions, will be accessed in whatever state they are at the time. As hinted in the first answer to this StackOverflow question, it might be necessary to add --skip-lock-tables to the options list, however I believe it would be redundant.
It may also be worth looking into using --result-file rather than piping the console output to disk. I doubt this will have any impact on dump speed, but it's worth mentioning.
My initial response included adding the --quick option, but, upon further reading, it is enabled by default, and specifying it manually is not needed.
I was going to suggest mysqlhotcopy if MD contained solely MyISAM and ARCHIVE tables, however it was deprecated in MySQL 5.6.20 and removed in MySQL 5.7.
An initial alternative idea was to have the dump occur via a user that had a resource limitation of the number of queries a second, but, as the only query limitation available is a per-hour limit, and, as the result of too many queries is that the server will return an error, rather than waiting until the user is allowed to make more queries, this is not a viable way to limit the resource usage of the DB backup process.