DBAtlas · データベース運用アトラス

MySQL の論理バックアップとリストア (mysqldump、MySQL Shell)

MySQLレベル: 中級所要時間: 20〜90 分 (データ量による)

mysqldump または MySQL Shell (util.dumpInstance / dumpSchemas / dumpTables + util.loadDump) による論理バックアップとリストアを扱います。テーブル、スキーマ、インスタンス全体、構造のみまたはデータのみ、別サーバーへの移行、フルダンプからの単一テーブルの抽出、systemd/cron によるスケジュール実行で login-path によるパスワードなし接続・検証・保存期間付きのバックアップまで含みます。どの手順も最後に行数の比較を行います。移行、単一オブジェクトの復旧、バージョン間の移行にはこのガイドを、大規模データベースの日次バックアップ、高速リストア、特定時点への復旧 (PITR) には Percona XtraBackup ガイドを使用してください。

構成: サーバー 1 台 (移行とインスタンスのリストアではターゲットサーバーを追加)

シナリオ

  • テーブルのエクスポート / インポート — 1 つまたは複数のテーブルをバックアップする、別のスキーマ/サーバーにコピーする、またはリストアする場合です。ソースは稼働したままで、InnoDB テーブルではロックを取得しません。
  • スキーマ (データベース) をバックアップ / リストアする — データベース (スキーマ) 全体をバックアップする、または別のスキーマ/サーバーにロードする場合です。ソースは稼働したままです。ターゲットで同名のテーブルは削除されて再作成されます。
  • インスタンス全体 (ユーザー + 全スキーマ) — バックアップはこのサーバーで取得し、リストアは空のサーバーで行います。ユーザー、権限、全スキーマが対象です。サーバーの再構築や、バージョン/プラットフォームの変更に使います。
  • 構造のみ (DDL) — テーブル、ビュー、トリガー、プロシージャ、イベントの定義のみで、データは含みません。スキーマの比較、空の環境の構築、構造のバージョン管理に使います。
  • データのみ — ターゲットに構造が用意されている状態で行だけを転送します (例: テストデータの更新)。ロード中にターゲットのトリガーが動作する可能性があり、ガイドではこれを確認します。
  • 別サーバーへの移行 — ターゲットサーバーで作業し、ソースにはネットワーク経由で login-path を使って接続します。切り替え時にアプリケーションの書き込みを止め、停止時間はダンプ + ロードの所要時間になります。サーバー、OS、バージョンの変更に使います。
  • フルダンプから単一テーブルを抽出 — フルダンプがあり、1 つのテーブルだけが必要な場合です (削除された行、DROP されたテーブル)。元のスキーマには触れずに別のスキーマへ抽出するか、削除されたテーブルを元に戻します。
  • スケジュールバックアップ (systemd timer / cron) — 毎日決まった時刻に自動で論理バックアップを取得します。専用のバックアップユーザー、login-path、スクリプト、systemd timer または cron、保存期間、エラー通知を構成します。ソースは稼働したままです。

開始前の確認

  • MySQL … が稼働しており、OS の root が mysql コマンドでパスワードなしで接続できる (auth_socket または ~/.mylogin.cnf)。DBAtlas の MySQL 単一サーバーのインストールガイドで構築した場合、パスは同じです。
  • スキーマのサイズが把握されており、バックアップディレクトリ … に十分な空き容量がある (圧縮した論理バックアップは通常データサイズの 10〜30%。インデックスはダンプに定義としてのみ含まれます)。
  • すべてのテーブルが InnoDB である。--single-transaction (および MySQL Shell の一貫性のあるダンプ) がロックなしで一貫性を保てるのは InnoDB テーブルのみです。MyISAM テーブルがある場合、ダンプ中にそのテーブルへ書き込むと不整合が生じます。
  • MySQL Shell をインストールするサーバーが MySQL リポジトリ (repo.mysql.com) にアクセスできるか、社内ミラーが定義されている。
  • ターゲットサーバー … に同じかそれ以降のバージョンの MySQL が (DBAtlas のインストールガイドで) インストールされて稼働しており、ユーザースキーマを含んでいない。8.4 から 8.0 のような古いバージョンへのロードによる切り戻しはサポートされません。
  • ターゲットサーバーからソースの … ポートに到達できる。
  • サーバーからメールを送信できる: ローカルの MTA (postfix) が組織の SMTP リレーに転送するよう設定されている。
  • 大規模なリストアや移行のためのメンテナンス時間帯が計画されている。ターゲットを上書きする場合はターゲットのバックアップを取得済みである。
  • このサーバーは正常なレプリカである: IO スレッドと SQL スレッドが Yes で、遅延が小さい。ダンプ内のバイナリログ位置 (--source-data=2) はこのレプリカ自身のバイナリログを指します。PITR に使う場合は log_replica_updates が有効である必要があります (8.x ではデフォルト)。
  • このサーバーは InnoDB Cluster のメンバーで、現在 SECONDARY / ONLINE である。

ガイドのフェーズ

  • 準備 — バックアップディレクトリを作成する · テーブルのストレージエンジンと長時間のトランザクションを確認する · MySQL Shell をインストールする
  • リストア (インポート) — ターゲットスキーマを作成する · ターゲットにテーブル構造を作成する · ターゲットのトリガーを確認する · ロードする (mysql) · ロードする (mysql、同じスキーマに上書き) · ロードする (util.loadDump) …
  • インスタンスのバックアップ — ユーザーと権限をエクスポートする · 全スキーマをバックアップする (mysqldump) · インスタンスをバックアップする (util.dumpInstance) · バックアップをリストア先サーバーにコピーする · バックアップをロードする (mysql) · ユーザーをロードする …
  • ソースサーバーの移行用アカウント — 移行用ユーザーを作成する · ファイアウォールでターゲットにポートを開放する · アプリケーションを停止する (切り替え時点)
  • ターゲットサーバーでの転送 — ソースへの接続を login-path として保存する · ユーザーを移行する · スキーマを転送する (mysqldump | mysql) · ユーザーをターゲットにロードする · ソースをダンプする (util.dumpInstance / dumpSchemas) · ターゲットにロードする (util.loadDump) …
  • ダンプから単一テーブルを抽出する — テーブルがダンプに含まれていることを確認する · ダンプからテーブルを抽出する · ターゲットスキーマを作成する · テーブルをロードする · テーブルを元のスキーマにリストアする · 行数を比較する …
  • バックアップユーザーと login-path — OS のバックアップユーザーを作成する · MySQL のバックアップ用アカウントを作成する · login-path を保存する (mysql_config_editor)
  • バックアップスクリプト — 通知ツールをインストールする · バックアップスクリプトを作成する · スクリプトを実行可能にする · 最初のバックアップを手動で取得する
  • スケジュール (systemd timer) — systemd サービスを作成する · systemd timer を作成する · timer を有効にし、サービスを手動でトリガーする · スケジュールジョブの実行を確認する (翌日)
  • スケジュール (cron) — cron サービスを準備する · cron ジョブを作成する · cron ファイルの権限を設定し、cron の環境でテストする · スケジュールジョブの実行を確認する (翌日)
  • 検証と監視 — 最新のバックアップをテスト用スキーマにリストアする · 最新バックアップの経過時間を監視する
  • 次のステップ: 物理バックアップ — 論理バックアップの限界を補う
環境に合わせた手順プランを開く →