次の方法で共有

オンプレミスの MySQL を Azure Database for MySQL に移行する: テスト計画

  • [アーティクル]

包括的なテスト計画を開発することは、オンプレミス環境から Azure Database for MySQL へ MySQL データベースを移行する上で重要です。 この記事では、効果的なテスト計画の重要な要素について詳しく説明し、移行プロセスがスムーズに成功するようにします。 主要なテスト戦略を立て、起こり得る問題を特定し、明確な検証基準を確立し、移行されたデータベースが Azure 環境内で最適に実行されるようにすることで、リスクを軽減することができます。 このガイドでは、機能テスト、パフォーマンス テスト、セキュリティ テストのいずれに重点を置いているかによらず、シームレスな移行をサポートする堅牢なテスト計画を作成するために必要な知識とベスト プラクティスを提供します。

前提条件

オンプレミスの MySQL を Azure Database for MySQL に移行する: 移行方法

概要

WWI は、一連の IT タスクとビジネス タスクを含むテスト計画を作成しました。 移行を成功させるには、すべてのテストを実行する必要があります。

テストでは以下を確認します。

  • 移行されたデータベースとオンプレミス テーブルの整合性 (同じレコード数とクエリ結果) を確認します。

  • パフォーマンスが許容できることを確認します (オンプレミスで実行されている場合と同等のパフォーマンスである必要があります)。

  • ターゲット クエリのパフォーマンスが、規定された要件を満たしていることを確認します。

  • オンプレミスと Azure ネットワークの間のネットワーク接続が許容できることを確認します。

  • 指定されたすべてのアプリケーションとユーザーが、移行されたデータ インスタンスに接続できることを確認します。

WWI は、週末に移行を行い、太平洋標準時の午後 10 時から午前 2 時までの時間枠を特定しました。 午前 2 時の目標 (4 時間のダウンタイム目標) までにすべてのテストに成功して移行が完了しなかった場合は、ロールバック手順が開始されました。 問題は今後の移行のために文書化されました。 すべての移行時間枠が前倒しされ、許容できるビジネス タイムラインに基づいて再スケジュールされました。

サンプル クエリ

データベースの移行が成功したかどうかを確認するために、ソースとターゲットで一連のクエリが実行されました。 次のクエリとスクリプトは、移行操作によって、必要なすべてのデータベース オブジェクトがソースからターゲットに移動されたかどうかを判断するのに役立ちます。

テーブルの行

このクエリを使用すると、すべてのテーブルと推定行数を取得できます。

SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';

注意

INFORMATION_SCHEMA テーブルでは、テーブル全体の推定値セットが提供されます。 テーブル サイズなどのメトリックをより正確に表示するには、innodb_stats_transient_sample_pages サーバー パラメーターを使用してページのサンプル サイズを増加します。 このサーバー値を増加すると、より多くのページが分析され、より正確な結果が得られます。

正確な行数を取得するには、すべてのテーブルに対して count(*) SQL ステートメントを実行します。 このコマンドを実行すると、大きなテーブルでは多くの時間がかかることがあります。 次のスクリプトでは、正確な数を取得するために実行できる SQL ステートメントのセットが生成されます。

SELECT CONCAT(
    'SELECT "',
    table_name,
    '" AS table_name, COUNT(*) AS exact_row_count FROM `',
    table_schema,
    '`.`',
    table_name,
    '` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';

テーブルの断片化

データ テーブルは、継続的なアプリケーションの使用によって拡大し続ける可能性があります。 場合によっては、データは増加しないかもしれませんが、削除や更新によって常に変化します。 その場合は、データベース ファイルに多くの断片化が発生する可能性があります。 MySQL OPTIMIZE TABLE ステートメントを使用すると、物理ストレージ領域のニーズを軽減し、I/O 効率を向上させることができます。

MySQL のテーブルを最適化するには、次を実行します。

optimize table TABLE_NAME

データベース オブジェクト

次のクエリを使用して、他のすべてのデータベース オブジェクトが考慮されていることを確認します。 これらのクエリはテーブルの行数を計算できますが、特定のデータベース オブジェクトのバージョンを考慮しない可能性があります。 たとえば、ストアド プロシージャが存在したとしても、移行の開始時と終了時では変化している可能性があります。 移行中はデータベース オブジェクトの開発を止めることをお勧めします。

ユーザー

SELECT DISTINCT
        USER
FROM
        mysql.user
WHERE
        user <> '' order by user

インデックス

SELECT DISTINCT
        INDEX_NAME
FROM
        information_schema.STATISTICS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

制約

SELECT DISTINCT
        CONSTRAINT_NAME
FROM
        information_schema.TABLE_CONSTRAINTS
WHERE
        CONSTRAINT_SCHEMA = '{SchemaName}'

ビュー

SELECT
        TABLE_NAME
FROM
        information_schema.VIEWS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

ストアド プロシージャ

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'FUNCTION' and
        ROUTINE_SCHEMA = '{SchemaName}'

関数

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'PROCEDURE' and
        ROUTINE_SCHEMA = '{SchemaName}'

イベント

SELECT
        EVENT_NAME
FROM
        INFORMATION_SCHEMA.EVENTS
WHERE
        EVENT_SCHEMA = '{SchemaName}'

ロールバック戦略

上記のクエリでは、ロールバックの決定に使用されるオブジェクト名とカウントの一覧が提供されます。 移行ユーザーは、ソース オブジェクトとターゲット オブジェクトの数を確認して、最初のオブジェクト検証手順を実行できます。 オブジェクト数の不一致は、ロールバックが必要であることを必ずしも意味しません。 詳細な評価を実行すると、その差はわずかで簡単に回復できる場合があります。 いくつかの失敗したオブジェクトを手動で移行することが解決策になる場合があります。 たとえば、すべてのテーブルとデータ行が移行され、一部の関数だけが失われている場合は、これらの失敗したオブジェクトを修復し、移行を完了してください。 データベースが比較的小さい場合は、Azure Database for MySQL インスタンスをクリアし、移行を再開することができます。 大きなデータベースでは、行方不明のオブジェクトを特定するのに、移行期間で使用可能な時間よりも長い時間が必要になる場合があります。 移行を停止してロールバックする必要があります。

不足しているデータベース オブジェクトの特定は、移行期間中に迅速に実行する必要があります。 1 分 1 分が重要です。 1 つの方法として、環境オブジェクト名をファイルにエクスポートし、データ比較ツールを使用して、不足しているオブジェクトをすばやく特定することができます。 もう 1 つの方法として、ソース データベース オブジェクト名をエクスポートし、そのデータをターゲット データベース環境の一時テーブルにインポートすることもできます。 スクリプト化およびテストされた SQL ステートメントを使用してデータを比較します。 データの検証速度と正確性は、移行プロセスにとって重要です。 移行期間中に、データベース オブジェクトの長い一覧を手動で読み取ったり検証したりすることは避けてください。 人為的なエラーの可能性が非常に高くなります。 ツールを使用して例外によって管理するのが最良の方法です。

WWI のシナリオ

WWI の CIO は、すべてのデータベース オブジェクトがオンプレミス データベースから Azure Database for MySQL インスタンスに移行されたことを示す確認レポートを受け取りました。 データベース チームは、移行の開始前にデータベースに対して上記のクエリを実行し、すべての結果をスプレッドシートに保存しました。

ターゲットの移行オブジェクトの忠実性を確認するために、ソースのデータベース スキーマ情報が使用されました。

テスト計画のチェックリスト

  • テスト クエリをスクリプト化してテストし、いつでも実行できるようにします。

  • テスト クエリの実行にかかる時間を把握し、ドキュメント化された移行タイムラインの一部として使用します。

  • さまざまな可能性のある結果に対して、軽減策とロールバック戦略を用意します。

  • 移行のためのイベントのタイムラインを明確に定義します。

次のステップ

オンプレミスの MySQL を Azure Database for MySQL に移行する: パフォーマンスのベースライン