これは私の備忘録です。
2020年初秋から「さくらレンタルサーバー（スタンダード）」で、MySQL データベースの cron バックアップでエラーが出ていた。 エラーがでてもバックアップファイルは作成されていたので、解決を後回しにしていた。
だが、毎日のエラーメールが増えるばかりだから昨年末に対策をした。
これはその作業記録を書き留めたもの。
MySQLのデータベースバックアップは朝方にやっているのだが、起床してメールチェックすると次のエラーメッセージを含んだメールがデータベースの数だけ送られてきていた。
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespacesエラーメールを遡ってみたら、どうも MySQL 5.7.3＊ になった頃から発生していた。
詳しいことがわかないので、早速、ググってみた。
やはり、同様のケースを確認したけど日本語より英語の記事が多くて「うっ！」になってしまった。
そこで、DeepL をフル活用して英語サイトを漁り、日本語で同症状に関する記事と比較してみたらみたら、PROCESS権限を付与すれば解決しそうだと言うことが分かった。
・・・が、ウチの場合は無理だった。（root権限じゃないと駄目？）
さらに、ググりは続きある情報を目にした。 その情報を参考にあれこれやってみて、素直にはいかなかったが、結果オーライ！
毎日のエラーメールは無くなった。
・・・で、やったこと。
mysqldump のオプションに –no-tablespaces を付ける。これだけ。但し、このオプションを付ける時は、mysqldump の直後は駄目。 オプションの指定には優先順位（順序）があるそうで、色々とやったらリダイレクトの直前が良さそうなことが分かった。
うちの場合、こんなコマンドラインを指定した。（一部、省略）
TODAY=date +'%y%m%d'
DBDUMP_FILE_1=mysql.$TODAY.LabelName
：
mysqldump --defaults-extra-file=[設定ファイル名].conf --default-character-set=utf8mb4 [Databse Name] > $DBDUMP_FILE_1これを、
mysqldump --defaults-extra-file=[設定ファイル名].conf --default-character-set=utf8mb4 [Databse Name] --no-tablespaces > $DBDUMP_FILE_1・・・に設定して動作確認ができた。
–defaults-extra-file がある場合は「必ず先頭！」にするのがポイント。（先人の知恵に感謝！）
–no-tablespaces は、”CREATE LOGFILE GROUP ステートメントおよび CREATE TABLESPACE ステートメントを出力に書き出さない” と言う MySQL オフィシャルの解説があった。 なるほど・・・ねと、分かったフリｗ
cron が１日１回の動作で、いちいち時間変更して動作検証するのも面倒なので、昨年末に１週間かけておこなった。
うーん、ヱビスが旨い！
誰かのために参考になれば幸いです。