オンプレミスの MySQL を Azure Database for MySQL に移行する: パフォーマンス ベースライン
オンプレミス環境から Azure Database for MySQL に MySQL データベースを移行するには、パフォーマンス ベースラインの確立が不可欠です。 この記事では、パフォーマンス ベースラインの重要性について詳しく説明し、現在のデータベース パフォーマンスの測定と分析に関する詳細なガイドを提供します。 既存のパフォーマンス メトリックを理解すると、現実的な期待を設定し、移行プロセスの間に改善する領域を明らかにできます。 このガイドを読むと、正確なパフォーマンス ベースラインを作成し、Azure 環境内の移行後のデータベースのパフォーマンス レベルを確実に現在と同等以上にするための知識を得られます。 目的がクエリのパフォーマンスの最適化、スケーラビリティの向上、一貫性のあるユーザー エクスペリエンスの実現のいずれであっても、この記事では、パフォーマンスの目標を達成するために必要な洞察を提供します。
前提条件
オンプレミスの MySQL を Azure Database for MySQL に移行する: テスト計画
概要
既存の MySQL のワークロードを理解することは、移行を成功させるために行うことのできる最善の投資の 1 つです。 優れたシステム パフォーマンスは、適切なハードウェアと優れたアプリケーション設計に依存します。 CPU、メモリ、ディスク、ネットワークなどの項目は、予想される負荷に合わせて適切にサイズを設定し、構成する必要があります。 ハードウェアと構成は、システム パフォーマンスの要素の一部です。 開発者は、データベース クエリの負荷と、実行負荷の最も高いクエリを理解する必要があります。 最も負荷の高いクエリに注目すると、全体的なパフォーマンス メトリックに大きな影響を与えることができます。
移行プロジェクトに対して、クエリのパフォーマンスのベースラインを作成することが不可欠です。 パフォーマンス ベースラインは、移行後のデータ ワークロードに対する Azure ランディング ゾーンの構成を検証するために使用できます。 ほとんどのシステムは年中無休で実行され、負荷がピークになる時間が異なります。 ベースラインでピーク時のワークロードをキャプチャすることが重要です。 メトリックは複数回キャプチャされます。 このドキュメントの後半では、移行元サーバーのパラメーターと、パフォーマンス ベースラインの全体像にとってそれらがどのように重要かを説明します。 移行プロジェクトの間に、サーバー パラメーターを見落とさないようにする必要があります。
ツール
サーバーのメトリックとデータベースのワークロードの情報を収集するために使用するツールを以下に示します。 キャプチャされたメトリックを使って、適切な Azure Database for MySQL のレベルと、関連するスケーリング オプションを決定します。
MySQL Enterprise Telemetry: この有料の Enterprise Edition ツールを使うと、最も負荷の高いクエリ、サーバー メトリック、ファイル I/O、トポロジ情報の並べ替えられたリストを入手できます
Percona Monitoring and Management (PMM): 優れたオープンソースのデータベース監視ソリューションです。 これは、デプロイされた場所に関係なく、複雑さを軽減し、パフォーマンスを最適化し、ビジネス クリティカルなデータベース環境のセキュリティを強化するのに役立ちます。
サーバー パラメーター
MySQL サーバーの既定の構成は、ワークロードをサポートするのに適切でない場合があります。 MySQL には多数のサーバー パラメーターがありますが、ほとんどの場合、移行チームが注目する必要があるのはそのうちの少数です。 移行元と移行先の環境で、次のパラメーターを評価する必要があります。 構成が正しくないと、移行の速度に影響する可能性があります。 移行手順を実行するときに、これらのパラメーターを見直します。
innodb_buffer_pool_size: 値が大きい場合、ディスク I/O を利用する前にまずメモリ内のリソースが使われます。 一般的な値は、使用可能なメモリの 80% から 90% の範囲です。 たとえば、システムのメモリが 8 GB の場合、プール サイズに 5 から 6 GB を割り当てる必要があります。
innodb_log_file_size: 再実行ログは、高速で持続的な書き込みを実現します。 このトランザクション バックアップは、システムのクラッシュ時に役立ちます。 innodb_log_file_size = 512M (再実行ログが 1 GB の場合) 以上にすると、書き込み用に十分な空き領域が得られるはずです。 MySQL 5.6 以降を使う書き込みが多いアプリケーションでは、innodb_log_file_size = 4G 以上にする必要があります。
max_connections: このパラメーターは、
Too many connectionsエラーを軽減するのに役立ちます。 既定値は 151 接続です。 アプリケーション レベルで接続プールを使用することをお勧めしますが、サーバー接続の構成も増やすことが必要になる場合があります。innodb_file_per_table: この設定は、データとインデックスを、共有テーブルスペースに格納するか、それともテーブルごとの separate.ibd ファイルに格納する必要があるかを、InnoDB に指示します。 テーブルごとにファイルを作成すると、テーブルの削除、切り捨て、または再構築が行われるときに、サーバーで領域を再利用できるようになります。 多数のテーブルが含まれるデータベースでは、ファイルごとのテーブルの構成を使用しないでください。 MySQL 5.6 以降では、既定値は ON です。 以前のバージョンのデータベースでは、データを読み込む前に、構成を ON に設定する必要があります。 この設定は、新しく作成されるテーブルにのみ影響します。
innodb_flush_log_at_trx_commit: 既定の設定は 1 で、InnoDB が ACID に完全に準拠していることを意味します。 この低リスクのトランザクション構成を使用すると、各変更を再実行ログにフラッシュするために余分な同期が必要になるので、低速のディスクのシステムでは、大きなオーバーヘッドが発生する可能性があります。 パラメーターを 2 に設定すると、コミットされたトランザクションは 2 回に 1回だけ再実行ログにフラッシュされるため、信頼性がやや低くなります。 一部のマスター環境ではリスクを許容できる可能性があり、レプリカに適した値です。 値を 0 にすると、システムのパフォーマンスは向上しますが、データベース サーバーで障害が発生したときにデータが失われる可能性が高くなります。 結論として、値 0 はレプリカに対してのみ使用してください。
innodb_flush_method: この設定は、データとログをディスクにフラッシュする方法を制御します。 バッテリで保護されたライトバック キャッシュを備えたハードウェア RAID コントローラーが存在する場合は、
O_DIRECTを使用します。 他のシナリオでは、fdatasync(既定値) を使用します。innodb_log_buffer_size: この設定は、まだコミットされていないトランザクション用のバッファー サイズです。 既定値 (1 MB) で問題ありません。 大きい BLOB またはテキストのフィールドがあるトランザクションでは、バッファーが短時間で埋まり、余分な I/O 負荷が発生する可能性があります。 状態変数
Innodb_log_waitsを調べて、それが 0 でない場合は、innodb_log_buffer_sizeを増やします。query_cache_size: クエリ キャッシュは、中程度のコンカレンシーの間に発生する可能性があることが知られているボトルネックです。 初期値は 0 に設定して、キャッシュを無効にする必要があります (例: query_cache_size = 0)。 MySQL 5.6 以降ではこれが既定値です。
log_bin: この設定は、バイナリ ログを有効にします。 サーバーがレプリケーション マスターとして機能する場合は、バイナリ ログを有効にすることが必須です。
server_id: この設定は、レプリケーション トポロジ内の ID サーバーに固有です。
expire_logs_days: この設定は、バイナリ ログが自動的に消去される日数を制御します。
skip_name_resolve: クライアントのホスト名解決を実行するために使います。 DNS が遅い場合、接続が低速になります。 名前解決を無効にしたときは、GRANT ステートメントで IP アドレスのみを使用する必要があります。 IP を使うには、以前の GRANT ステートメントを再実行する必要があります。
確認のためにサーバー パラメーターをファイルにエクスポートするには、次のコマンドを実行します。 必要に応じて、何らかの簡単な解析を使って、移行後に出力で Azure Database for MySQL サーバーに同じサーバー パラメーターを再適用できます。 「Azure portal を使用して Azure Database for MySQL サーバーのサーバー パラメータを構成する」を参照してください。
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
MySQL 5.5.60 により既定でインストールされるサーバー パラメーターは、付録で確認できます。
移行を始める前に、移行元の MySQL の構成設定をエクスポートします。 移行後に、それらの値を Azure ランディング ゾーン インスタンスの設定と比較します。 移行先の Azure ランディング ゾーン インスタンスで既定値から変更された設定がある場合は、移行後にそれらを元に戻します。 また、移行ユーザーは、移行前にサーバー パラメーターを設定できることを確認する必要があります。
構成できないサーバー パラメーターの一覧については、「構成不可能なサーバー パラメーター」を参照してください。
エグレスとイングレス
可能な限り速いエグレスとイングレスをサポートするには、データ移行ツールとパスごとに、移行元と移行先の MySQL サーバー パラメーターを変更する必要があります。 ツールによって、パラメーターが異なる場合があります。 たとえば、移行を並列に実行するツールでは、移行元と移行先の間に、単一スレッド ツールより多くの接続が必要になる場合があります。
データセットの影響を受ける可能性のあるタイムアウト パラメーターを確認します。 これには以下が含まれます。
さらに、最大値に影響を与えるパラメーターを確認します。
注意
一般的な移行エラーは MySQL server has gone away です。 ここで説明したパラメーターは、このエラーを解決するための一般的な原因です。
WWI のシナリオ
WWI によりその Conference データベースのワークロードが調べられ、負荷が小さいことが確認されました。 Basic レベルのサーバーでも問題ありませんでしたが、後で別のレベルに移行する作業を行いたくありませんでした。 デプロイされているサーバーで最終的に他の MySQL データ ワークロードがホストされるので、General Performance レベルを選択しました。
MySQL データベースを確認したところ、MySQL 5.5 サーバーは、初期インストール時に設定される既定のサーバー パラメーターで実行されていることがわかりました。