オンプレミスの MySQL を Azure Database for MySQL に移行する: 移行方法
適用対象:
Azure Database for MySQL - 単一サーバー Azure Database for MySQL - フレキシブル サーバー
前提条件
概要
ソースからターゲットにデータを取得するには、MySQL のツールまたは機能を使用して移行を実行する必要があります。
次のステージを開始する前に、評価と計画のステージ全体を完了することが重要です。 この決定と収集されるデータは、移行パスとツールの選択に依存します。
このセクションでは、一般的に使用される次のツールについて説明します。
MySQL Workbench
mysqldump
mydumper と myloader
データイン レプリケーション (binlog)
MySQL Workbench
MySQL Workbench では、開発者と管理者が MySQL インスタンスの設計、開発、管理を行える豊富な GUI エクスペリエンスが提供されます。
最新バージョンの MySQL Workbench では、ソースからターゲットにデータベースを移動するときに、高度なオブジェクト移行機能が提供されます。
データのインポートとエクスポート
MySQL Workbench では、テーブルとデータベース オブジェクトの全体または一部のエクスポートとインポートを行うウィザード ベースの UI が提供されます。 MySQL Workbench の使用方法の例については、「インポートとエクスポートを使用した MySQL データベースの移行」を参照してください。
ダンプと復元 (mysqldump)
mysqldump は通常、MySQL のインストールの一部として提供されます。 これは、データベースを一定の時点まで再構築するために再生できる一連の SQL ステートメントと同じ論理バックアップを作成するために実行できるクライアント ユーティリティです。 mysqldump は、大量のデータをバックアップまたは移行するための高速またはスケーラブルなソリューションとして意図されているものではありません。 インデックスの更新に必要なディスク I/O が原因で、大量の SQL 挿入ステートメントを実行すると、パフォーマンスが低下する可能性があります。 ただし、元のスキーマを必要とする他のツールと組み合わせると、mysqldump はデータベース スキーマとテーブル スキーマを生成するための最適なツールです。 スキーマを使用すると、ターゲット ランディング ゾーン環境を作成できます。
mysqldump ユーティリティには、データ移行フェーズ中に便利な機能があります。 ユーティリティを実行する前に、パフォーマンスに関する考慮事項を評価する必要があります。 「パフォーマンスに関する考慮事項」を参照してください。
mydumper と myloader
高速な移行を必要とする大規模なデータベースがある環境では、mydumper と myloader を使うことをお勧めします。これらのツールは C++ で書かれており、マルチスレッド手法を利用してターゲットの MySQL インスタンスに可能な限り高速にデータを送信できます。 mydumper と myloader は並列処理を利用し、10 倍以上の速度で移行を高速化できます。
パブリック ダウンロードが可能なツールのバイナリ リリースが、Linux 向けにコンパイルされました。 Windows でこれらのツールを実行するには、オープンソース プロジェクトを再コンパイルする必要があります。 ソース コードのコンパイルとリリースの作成は、ほとんどのユーザーにとって簡単な作業ではありません。
データイン レプリケーション (binlog)
他のデータベース管理システムと同様に、MySQL にも binlog レプリケーションというログ レプリケーション機能があります。binlog レプリケーション機能は、データの移行や読み取りレプリカの作成に役立ちます。
binlog レプリケーションを利用して、オンライン シナリオで Azure Database for MySQL にデータを移行します。 データ レプリケーションは、最終的なターゲット データの変更に必要なダウンタイムを減らすのに役立ちます。
binlog レプリケーション機能を使用するには、いくつかのセットアップ要件があります。
マスター サーバーでは、MySQL InnoDB エンジンを使用することをお勧めします。 InnoDB 以外のストレージ エンジンを使用している場合は、そのテーブルを InnoDB に移行する必要があります。
移行ユーザーは、バイナリ ログの構成とマスター サーバーでの新しいユーザーの作成を実行できるアクセス許可を持っている必要があります。
マスター サーバーで SSL が有効になっている場合は、ドメインに対して指定されている SSL CA 証明書が mysql.az_replication_change_master ストアド プロシージャに含まれていることを確認します。 次の例と master_ssl_ca パラメーターを参照してください。
マスター サーバーの IP アドレスが Azure Database for MySQL レプリカ サーバーのファイアウォール規則に追加されていることを確認します。 Azure portal または Azure CLI を使用してファイアウォール規則を更新します。
マスター サーバーをホストしているコンピューターで、ポート 3306 の受信トラフィックと送信トラフィックの両方が確実に許可されているようにします。
マスター サーバーが、ソースからターゲットへのアクセス可能な IP アドレス (パブリックまたはプライベート) を持っていることを確認します。
レプリケーションを使用して移行を実行するには、「Azure Database for MySQL のデータイン レプリケーションを構成する方法」を参照してください。
binlog レプリケーション方法には高い CPU 要件と追加のストレージ要件があります。 移行ユーザーは、オンライン移行中にソース システムにかかる負荷をテストし、それが許容されるかどうかを判断する必要があります。
Azure Database Migration Service (DMS)
Azure Database Migration Service (DMS) は、管理者が移行のさまざまな設定を追跡し、必要に応じて再利用できる Azure クラウドベースのツールです。 DMS は、さまざまなソースと宛先を指す設定を使用して移行プロジェクトを作成することで機能します。 オフライン移行がサポートされています。 さらに、オンプレミスのデータ ワークロードと、Amazon Relational Database Service (RDS) MySQL などのクラウドベースのワークロードもサポートしています。
DMS サービスはオンライン ツールですが、タスクを完了するために MySQL の binlog レプリケーション機能に依存しています。 現在、DMS ではオフライン移行プロセスが部分的に自動化されています。 DMS では、ターゲット Azure Database for MySQL インスタンス内に一致するスキーマを生成し、適用する必要があります。 mysqldump クライアント ユーティリティを使用してスキーマをエクスポートできます。
最速/最小ダウンタイムの移行
データを移行するには、多くのパスがあります。 どのパスを選択するかの判断は、移行チームのスキル セットと、データベースとアプリケーションの所有者が許容できるダウンタイムの長さによります。 一部のツールではマルチスレッドの並列データ移行アプローチがサポートされていますが、他のツールはテーブル データのみを簡単に移行するように設計されています。
最も高速で最も完全なパスは、(MySQL で直接、または DMS を介して) binlog レプリケーションを使用する方法ですが、主キーを追加するコストが発生します。
意思決定テーブル
MySQL ワークロードを移行するために WWI が実行できるパスは多数あります。 可能なパスと、それぞれの長所と短所の表を示します。
| 目標 | 説明 | ツール | 前提条件 | 長所 | 短所 |
|---|---|---|---|---|---|
| 可能な限り最速の移行 | 並列アプローチ | mydumper と myloader | Linux | 高度に並列化 | ターゲットの調整 |
| オンライン移行 | 可能な限りソースを有効な状態に維持 | binlog | なし | シームレス | 追加の処理とストレージ |
| オフライン移行 | 可能な限りソースを有効な状態に維持 | Database Migration Service (DMS) | なし | 反復可能なプロセス | データのみに制限、すべての MySQL バージョンをサポート |
| 高度にカスタマイズされたオフライン移行 | オブジェクトを選択的にエクスポート | mysqldump | なし | 高度にカスタマイズ可能 | 手動 |
| 半自動化されたオフライン移行 | UI ベースのエクスポートとインポート | MySQL Workbench | ダウンロードおよびインストールする | 半自動 | 一般的なスイッチのセットのみをサポート |
WWI のシナリオ
WWI は、最初の移行ワークロードとして会議データベースを選択しました。 このワークロードが選択されたのは、年間の会議スケジュールが途切れることによるリスクが最も少なく、利用可能なダウンタイムが最も長いためです。 さらに、移行チームの評価に基づいて、MySQL Workbench を使用してオフライン移行の実行を試すことを決定しました。
移行方法のチェックリスト
ターゲットとソースの環境で適切な方法が選択されていることを確認します。
その方法がビジネス要件を満たしていることを確認します。
データ ワークロードがその方法をサポートしているかどうかを常に確認します。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示