The dump user should have the new grants GRANT SUPER, REPLICATION CLIENT ON *.* TO dump@localhost;, in addition to FILE, RELOAD globally and
GRANT EVENT, LOCK TABLES, SELECT, SHOW VIEW, TRIGGER ON `%wik%`.* TO 'dump'@'localhost'; GRANT EVENT, LOCK TABLES, SELECT, SHOW VIEW, TRIGGER ON `centralauth`.* TO 'dump'@'localhost';
Otherwise, bacula backups will fail:
(without replication client)
mysqldump: Couldn't execute 'SHOW ALL SLAVES STATUS': Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation (1227) mysqldump: Couldn't execute 'SHOW ALL SLAVES STATUS': Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation (1227)
(without super)
mysqldump: Couldn't execute 'STOP SLAVE 's2' SQL_THREAD': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Couldn't execute 'START SLAVE 'm3'': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Error: Unable to start slave 'm3' mysqldump: Couldn't execute 'START SLAVE 's1'': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Error: Unable to start slave 's1' mysqldump: Couldn't execute 'START SLAVE 's5'': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Error: Unable to start slave 's5' mysqldump: Couldn't execute 'START SLAVE 's6'': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Error: Unable to start slave 's6' mysqldump: Couldn't execute 'START SLAVE 's7'': Access denied for user 'dump'@'localhost' (using password: YES) (1045) mysqldump: Error: Unable to start slave 's7
I do not like the dump user having SUPER privileges, but it is an upstream bug: START and STOP SLAVE do not have separate privileges, and without binary log coordinates, backups are useless.
Update: bacula no longer does the backups, but the same issue is relevant.