MySQLデータ移行の概要

序文：

日常業務では、テーブル、データベース、インスタンスの移行など、データの移行が必要になることがよくあります。さまざまなニーズに応じてさまざまな移行計画が必要になる場合があり、データ移行プロセス中にさまざまな規模の問題が発生する可能性があります。この記事では、MySQL のデータ移行について見ていきます。皆さんのお役に立てれば幸いです。

1. データ移行について

まず、データ移行に関するWikipediaの説明を引用しましょう。

データ移行とは、データを選択、準備、抽出、変換し、あるコンピュータストレージシステムから別のコンピュータストレージシステムに永続的に転送するプロセスです。さらに、移行されたデータの整合性の検証と古いデータストアの廃止も、全体的なデータ移行プロセスの一部と見なされます。

データ移行は、あらゆるシステムの実装、アップグレード、統合において重要な考慮事項であり、多くの場合、可能な限り自動化された方法で実行され、人的リソースを面倒な作業から解放します。

データ移行は、サーバーまたはストレージデバイスの交換、メンテナンスまたはアップグレード、アプリケーションの移行、Web サイトの統合、災害復旧、データセンターの移転など、さまざまな理由で発生します。

MySQL データベースでは、テストライブラリから開発ライブラリへの移行、またはあるマシンから別のマシンへの移行など、データ移行のニーズが頻繁に発生します。1 つのテーブルのみの移行が必要な場合もあれば、データベースインスタンス全体の移行が必要な場合もあります。さまざまなニーズに応じてさまざまな移行計画が必要になる場合がありますが、一般的に、MySQL データ移行計画は、物理移行と論理移行の 2 つのカテゴリに大まかに分けられます。

2. 移行計画と留意点

物理的な移行は、大量のデータの全体的な移行に適しています。物理的な移行には、データファイルのコピーと XtraBackup バックアップツールの使用が含まれます。異なるサーバー間では物理的な移行を使用できます。新しいサーバーに同じバージョンのデータベースソフトウェアをインストールし、同じディレクトリを作成します。構成ファイルは元のデータベースと同じにすることをお勧めします。次に、元のデータベースからデータファイルとログファイルをコピーし、ファイルグループの権限を構成してから、mysqld コマンドを使用して新しいサーバーでデータベースを起動します。

物理的な移行ソリューションを使用する利点は、比較的高速であることです。ただし、移行にはダウンタイムが必要であり、MySQL のバージョンと構成が元のサーバーと同じである必要があるため、未知の問題が発生する可能性もあります。

比較すると、論理移行は適用範囲が広く、部分的な移行と完全な移行の両方に使用できます。論理移行で最も一般的に使用される方法は、mysqldump などのバックアップツールを使用してエクスポートおよびインポートすることです。

mysqldump は、異なるバージョンや構成間の移行にも適しています。ただし、データベース全体を移行する場合、特に異なるバージョン間で移行する場合は、-A パラメータを使用してデータベース全体をバックアップすることはお勧めしません。一部のシステムライブラリがわずかに異なる場合があり、移行後に未知の問題が発生する可能性があります。完全な移行に mysqldump を使用する場合は、以下の手順に従います。

# 元のデータベース実行は、データベース作成ステートメントを取得し、新しいデータベース（システムデータベースを除く）でそれを実行します。
選択
  CONCAT( '存在しない場合はデータベースを作成 ', '`', SCHEMA_NAME, '`', ' デフォルト文字セット ', DEFAULT_CHARACTER_SET_NAME, ';' ) AS CreateDatabaseQuery
 から
  情報スキーマ.SCHEMATA
 どこ
  SCHEMA_NAME が ( 'information_schema'、 'performance_schema'、 'mysql'、 'sys' ) にありません。

   # 元のデータベースは、新しいデータベースで取得された作成されたユーザーステートメントを実行します（システムユーザーを除く）
 選択
  CONCAT( 'create user \'', USER, '\'@\'', HOST, '\'' ' IDENTIFIED BY PASSWORD \'', authentication_string, '\';' ) AS CreateUserQuery
 から
  mysql.`ユーザー`
 どこ
  `User` が ( 'root', 'mysql.session', 'mysql.sys' ) に含まれていません。

  # 元のデータベースで show grants を実行してユーザー権限を取得し、新しいデータベースで 1 つずつ実行します (これらの権限テーブルを新しいデータベースにコピーすることもできます)
'testuser'@'%' の権限を表示します。

# この時点で、新しい環境にはすでに移行するライブラリとユーザーが存在しますが、データはありません。# mysqldump を使用して、元の環境のシステムライブラリを除くすべてのライブラリをバックアップします。
 mysqldump -uroot -pxxxx -R -E --single-transaction --databases db1 db2 > db.sql

# 次に新しい環境をインポートします。mysql -uroot -pxxxx < db.sql

一部のライブラリとテーブルを移行する場合も、上記と同様のソリューションを使用できますが、バックアップはオンデマンドで実行する必要があります。一般的な mysqldump バックアップシナリオを次に示します。

# 単一のデータベースをバックアップする mysqldump -uroot -pxxxxx -R -E --single-transactio --databases db1 > db1.sql

# いくつかのテーブルをバックアップします。 mysqldump -uroot -pxxxxx --single-transaction db1 tb1 tb2 > tb12.sql

# いくつかのテーブルをチェックします mysqldump -uroot -pxxxxxx db1 --ignore-table=db1.tb1 --ignore-table=db1.tb2 > db1.sql

# 構造またはデータのみをバックアップする mysqldump -uroot -pxxxxx testdb --no-data > testdb_jiegou.sql
mysqldump -uroot -pxxxxxx testdb --no-create-info > testdb_data.sql

一般的に、mysqldump を使用する方が柔軟性が高くなります。移行を高速化するには、不要なログテーブルを除外するなど、バックアップコンテンツを最小限に抑える必要があります。一部の大きなテーブルについては、別の移行ソリューションを採用することもできます。たとえば、db1 の tb1 テーブルは特に大きいです。バックアップ中に tb1 を除外できます。大きなテーブル tb1 については、LOAD DATA メソッドを使用するか、テーブルスペースを破棄してからインポートして移行できます。

データ移行プロセス中にさまざまなエラーが発生する可能性がありますが、段階的に解決できます。移行前に、新しいデータベースにユーザーを作成し、権限を付与することをお勧めします。ビューと関数には定義者の概念があるため、これにより、ビューと関数のインポート時のエラーを回避できます。新しい環境をインポートするときは、権限によって発生する問題を回避するために、root などの SUPER 権限を持つ管理者ユーザーを使用することをお勧めします。

移行が完了したら、テーブルの数が同じかどうか、いくつかのテーブルをランダムにチェックして、データが同じかどうか、コードが文字化けしていないかどうかなど、新しい環境を再度確認する必要があります。すべてに確信があるときのみ、成功します。