概要

Movable Type（MT）などデータ量が多いCMSのMySQLバックアップでは、単に mysqldump を実行しただけでは、文字化け・権限エラー・復元時の不整合が発生することがあります。

実際に発生した障害を踏まえ、安全にDBダンプを取得するためのオプションと注意点を整理します。

---

推奨コマンド（汎用例）

mysqldump \
  --ssl-mode=REQUIRED \
  -h <DB_HOST> \
  -u <DB_USER> -p \
  --single-transaction \
  --quick \
  --no-tablespaces \
  --hex-blob \
  --set-gtid-purged=OFF \
  --default-character-set=utf8mb4 \
  <DATABASE_NAME> \
  > ~/db_backup/dump_$(date +"%Y%m%d_%H%M%S").sql

実際に遭遇した MT 環境向け（最小構成例）

過去に実際に遭遇した Movable Type 環境では、以下の 3 つのオプションが必須でした。

• --no-tablespaces：PROCESS 権限不足によるエラー回避
• --hex-blob：バイナリデータ由来の警告・復元トラブル回避
• --set-gtid-purged=OFF：GTID 情報による復元エラー回避

以下は、当時実際に使用して問題なく取得できたコマンド構成を、接続先・DB名を伏せた形で整理した例です。

mysqldump \
  --ssl-mode=REQUIRED \
  -h <DB_HOST> \
  -u <DB_USER> -p \
  --no-tablespaces \
  --hex-blob \
  --set-gtid-purged=OFF \
  <DATABASE_NAME> \
  > ~/db_backup/backup_$(date +"%Y%m%d_%H%M%S")_dev--no-tablespaces--hex-blob.sql

この構成は、ダンプを失敗させないことを最優先にした実績ベースの最小構成です。

• 権限制限のある RDS / 共有サーバ環境
• GTID 有効環境
• BLOB を含む MT のデータ構成

こうした条件下では、この形が現実的な落とし所になるケースがあります。

一方で、大容量 DB や本番稼働中の環境では、上記の汎用例（--single-transaction / --quick を含む構成）を推奨します。

---

各オプションの意味と障害事例

MySQL 5.7 / 8.0 における挙動差と改善状況

mysqldump に関するトラブルの多くは、MySQL のマイナーバージョン差分による仕様変更・改善が原因で発生します。Movable Type 環境で問題になりやすいポイントを、5.7 系・8.0 系に分けて整理します。

MySQL 5.7 系

• 5.7.31 以降

  • mysqldump が tablespace 情報取得のために INFORMATION_SCHEMA.FILES を参照する仕様に変更されました
  • PROCESS 権限が必須となり、権限制限ユーザーではダンプが失敗するケースが増加しました
  • 対策として --no-tablespaces が実質必須になるケースが多くあります

• BLOB / VARBINARY を含む場合

  • 環境・データ内容によっては Invalid utf8 character string などの警告が出るケースがあります
  • 安全側を取る場合は --hex-blob の指定が有効です

MySQL 8.0 系（8.0.x）

• バイナリデータの扱い

  • 5.7 系と比べると BLOB に起因する警告は出にくくなっています
  • ただし、データ構成や復元先環境によっては警告が出ることがあります
  • 互換性重視・移行用途では --hex-blob を付けておくほうが安全です

• 8.0 系全般

  • GTID がデフォルト有効のケースが多く、ダンプに GTID 情報が含まれやすくなっています
  • 別環境への単純復元では --set-gtid-purged=OFF を指定しないと復元エラーになることがあります
  • 特に RDS / マネージドDB 環境では注意が必要です

実務的な判断指針

• MySQL 5.7.31 以上
  • 権限制限があるなら --no-tablespaces はほぼ必須です
• MySQL 8.0.x
  • 以前より改善されていますが、移行・バックアップ用途では 5.7 と同様のオプション構成が安全です
• MT のような CMS
  • データ量・履歴・バイナリ混在の影響を受けやすいため、「不要なら外す」よりも「安全側を基準にする」運用が現実的です

—no-tablespaces

MySQL 5.7.31 以降では、mysqldump が tablespace 情報を取得する際に INFORMATION_SCHEMA.FILES を参照し、PROCESS 権限が必要になります。

権限がない場合、以下のエラーが発生します。

Access denied; you need (at least one of) the PROCESS privilege(s)

対策として --no-tablespaces を指定します。

---

—hex-blob

BLOB / VARBINARY カラムを含む場合、バイナリデータが SQL テキストとして解釈されることで警告が出たり、復元時に問題になったりする可能性があります。--hex-blob を指定すると、16進表記で安全に出力できます。

---

—set-gtid-purged=OFF

GTID 有効環境では、GTID 情報がダンプに含まれることで復元先で不整合やエラーが起きることがあります。

単純なバックアップ用途では OFF を指定します。

---

—default-character-set=utf8mb4

文字コードを明示しない場合、環境差により文字化けが発生する可能性があります。対象DBの実運用文字コードに合わせて指定します（多くの環境では utf8mb4）。

---

—single-transaction

InnoDBで整合性を保ちながらロックを最小化します。

---

—quick

大量データを逐次処理し、メモリを節約します。

---

まとめ

mysqldump はオプションを適切に指定しないと、以下の問題が発生します。

• PROCESS 権限不足によるダンプ失敗
• バイナリデータの文字化け
• GTID 情報による復元エラー
• 文字コード不一致による文字化け

これらを回避するため、上記のコマンドを基本形として運用することを推奨します。