MySQL Shell Dump Utility なら速くて便利でコストにも優しい
ポート株式会社 サービス開発部 Advent Calendar 2025 12日目 です。
はじめに
これまで RDS(Aurora MySQL) の日次スナップショットを取得していましたが、
スナップショットは高額なので、Dumpファイル を S3 に保存する方針に変えました。
Dumpファイルを取得するとなると、mysqldump をすぐに思い浮かべます。
弊社でもいくつかのプロジェクトで利用していましたので、今回も mysqldump を利用しようと考えていました。
その際、社内のメンバーから「 MySQL Shell を使ってみてはどうか」という案が出ました。
この MySQL Shell が非常に便利だったので、使ってみた所感をまとめました。
MySQL Shell とは
mysqldump
MySQL の Dumpファイルを取得する際、mysqldump コマンドを利用します。
mysqldump は古くから使われている標準的な方法で、SQLテキスト形式でバックアップします。
mysqldump -h DB_HOST -u DB_USER -p DB_NAME > dump.sql
mysqlsh
一方、MySQL Shell だと、mysqldump とはまったく別物の「ディレクトリ形式ダンプ」になります。
- インスタンス単位では、
util.dumpInstance() - スキーマ単位では、
util.dumpSchemas() - テーブル単位では
util.dumpTables()
コマンド名は mysqlsh で、Dump は JSON 形式のメタデータ と バイナリ形式のテーブルデータ を組み合わせて並列処理で高速にバックアップします。
mysqlsh -h DB_ENDPOINT -u DB_USER -p DB_PASS \
-e "util.dumpSchemas(
['DB_NAME'],
'outputUrl',
{
threads: 8,
chunking: 'AUTO',
consistent: true,
showProgress: true,
compress: true,
compatibility: ['strip_restricted_grants']
}
)"
実際に使ってみる
mysqlsh インストール
DBバックアップ処理を EC2インスタンス で行っているので、
Amazon Linux 環境で利用できるように mysqlsh をインストールします。
- MySQL公式の Yum リポジトリを追加
sudo yum install -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
Amazon Linux 2 は CentOS 7 相当なので el7 を使用します。
- リポジトリの確認
yum repolist enabled | grep mysql
- MySQL Shell をインストール
sudo yum install -y mysql-shell
- インストール確認
mysqlsh --version
mysqlsh でバックアップを取る
今回は 単一のアプリケーションのデータベースのみをバックアップしたいので、
util.dumpSchemas() を利用します。
以下のコマンドになります。
mysqlsh -u"${DB_USER}" -p"${DB_PASSWORD}" -h"${DB_ENDPOINT}" \
--js -e "util.dumpSchemas(
['${DB_NAME}'], '${DUMP_PREFIX}',
{
s3BucketName: '${S3_BUCKET_NAME}',
s3Region: '${REGION}',
threads: 2,
consistent: true,
compress: 'gzip'
}
)"
オプションの解説として
- s3BucketName: 保存先のS3を指定できます。
- s3Region: 対象のAWSリージョン
- threads: 並列数の指定
- consistent: InnoDB の一貫性スナップショットを取得する
- compress: 圧縮形式
ポイント
s3BucketName
s3BucketName とするだけで、対象のS3バケットに Dump ファイルを保存してくれます。
認証は EC2インスタンスの IAMロール(インスタンスプロファイル)に権限があればOKです。
threads
threads は EC2が t2.small(1vCPU) なので、必要以上に多いとリソース枯渇になる可能性があるので、2 に設定しました。
ちなみに 8 にしてみた時と、2 にしてみた時で比べてみましたが、ダンプ取得速度にそれほど大きな違いがありませんでした。
むしろ インスタンスのCPU使用率が 8 にした時の方がやや高めになっていたので、その辺りを考慮した方がよさそうです。
consistent
このオプションは、
mysqldump --single-transaction と同じで、基本は true にした方が良いです。
MySQL Shell を使うメリット
MySQL Shell を使って感じたメリットをいくつか挙げます。
バックアップ速度が速くなった
mysqldump にした時と、mysqlsh にした時とで、Dumpの取得速度を測ってみました。
mysqldump
最初の start から mysqldump complete までおよそ 44分程度

mysqlsh
Dump duration: 00:22:59s となっており、
およそ22分程度で、mysqldumpと比較しておよそ半分の速度に収まりました。


なぜ速くなる?
mysqldump は 基本 1 スレッドで順番にテーブルをダンプします。
一方、mysqlsh の方が速い要因として、並列処理でダンプする仕組みが挙げられます。
- threads: N に応じて 複数テーブルを同時にダンプ
- 大きなテーブルも チャンク分割して複数スレッドで同時処理
事前調査で、並列処理であることを理解していましたが、これほどまでに速くなるとは思いませんでした。
S3 へのバックアップがシームレス
mysqldump の時は、Dumpファイルを S3に保存するために、
tmpファイル を用意して、aws s3 コマンドを打つ、というスクリプトを書いていました。
しかし、MySQL Shell には S3 へ直接書き込むための組み込みストレージ・ドライバ が用意されています。
オプションで、 s3BucketName と指定すれば、tmpファイルを作らずに S3 バケットへストリーム転送できます。
ですから、AWS CLI の aws s3 cp をパイプで呼び出す必要はなく、スクリプトが簡略化されるメリットがあります。
ログの詳細が出力できてデバッグしやすい
mysqlsh では ログ出力に関するオプションも用意されています。
-
--log-level=INFO/DEBUG...でかなり細かくレベルを指定可能 -
showProgressやdryRunで 挙動を分かりやすく確認できる
上記のログ画像から見ても、mysqldump よりかなり詳細なログを確認できるのがわかります。
コストにも優しい
コストに関しては、mysqldump も mysqlsh も大差はないと思いますが、
弊社では (様々な歴史的背景があり) DBのバックアップをスナップショットとしてずっと保管していました。
Dumpの場合、S3に保存するだけなので、S3のストレージ料金しかかかりません。
mysqlshの便利さに加え、DBのバックアップデータの長期保存が低コストでできるので、
非常にコストパフォーマンスが良いツールだと感じました。
ただ、S3に蓄積され続けると、数年後にそれなりのコストになる可能性もあるので、
ライフサイクルはしっかり設定するのを推奨します。
(30日後に Standard -> Glacier に移行させるなど)
最後に
MySQL Shell (mysqlsh) は非常に便利なツールで、使ってみて特に大きなデメリットは感じませんでした。
強いてデメリットを言うなら、オプションが多彩で、公式ドキュメントの内容も難解であることかなと感じました。
DBのバックアップで Dumpファイルを取得することを検討しているなら、
この MySQL Shell Dump Utility は大いに使う価値があると思います。
ぜひ参考にしてみてください。
Discussion