次の方法で共有

Azure Database for MySQL - フレキシブル サーバーでの読み取りレプリカ

  • [アーティクル]

適用対象: Azure Database for MySQL - フレキシブル サーバー

MySQL は、インターネット規模の Web およびモバイル アプリケーションを実行するための一般的なデータベース エンジンの 1 つです。 多くのお客様は、オンライン教育サービス、ビデオ ストリーミング サービス、デジタル支払いソリューション、eコマース プラットフォーム、ゲーム サービス、ニュース ポータル、政府機関、医療機関の Web サイトなどにそれを使用しています。 これらのサービスは、Web またはモバイル アプリケーションでのトラフィックの増加に合わせて、サービスを提供し、スケーリングする必要があります。

アプリケーション側に関しては、通常、アプリケーションは Java または PHP で開発され、Azure 仮想マシン スケール セットや Azure App Services で実行されるように移行されたり、Azure Kubernetes Service (AKS) で実行するようにコンテナー化されたりします。 仮想マシン スケール セット、App Service、または AKS を基になるインフラストラクチャとして使用すると、アプリケーションのスケーリングは、新しい VM を瞬時にプロビジョニングし、アプリケーションのステートレス コンポーネントをレプリケートして要求に対応することで簡素化されますが、多くの場合、データベースは一元化されたステートフル コンポーネントとしてボトルネックになります。

読み取りレプリカ機能を使用すると、Azure Database for MySQL フレキシブル サーバー インスタンスから読み取り専用サーバーにデータをレプリケートできます。 ソース サーバーから最大で 10 個のレプリカにレプリケートできます。 レプリカは、MySQL エンジンのネイティブなバイナリ ログ (binlog) ファイルの位置ベースのレプリケーション テクノロジを使用して、非同期で更新されます。 binlog レプリケーションの詳細については、MySQL binlog レプリケーションの概要に関する記事を参照してください。

レプリカは、ソースの Azure Database for MySQL フレキシブル サーバー インスタンスと同様に管理する新しいサーバーです。 仮想コアのプロビジョニングされたコンピューティングとストレージ (GB/月) に基づいて、読み取りレプリカごとに課金が発生します。 詳細については、価格に関するページを参照してください。

Note

読み取りレプリカ機能は、General Purpose または Business Critical 価格レベルの Azure Database for MySQL フレキシブル サーバー インスタンスでのみ使用できます。 ソース サーバーがこれらの価格レベルのいずれであるかを確認します。

MySQL レプリケーションの機能と問題の詳細については、MySQL レプリケーションに関するドキュメントを参照してください。

Note

この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。

読み取りレプリカの一般的なユース ケース

読み取りレプリカ機能は、読み取り集中型ワークロードのパフォーマンスとスケールの向上に役立ちます。 読み取りワークロードをレプリカに分離しながら、書き込みワークロードはソースに送ることができます。

一般的なシナリオを次に示します。

  • ProxySQL のような軽量の接続プロキシを使用するか、マイクロサービス ベースのパターンを使用して、アプリケーションからの読み取りクエリを読み取りレプリカにスケールアウトすることによる、アプリケーションからの読み取りワークロードのスケーリング
  • BI または分析のレポート ワークロードで、レポートのデータソースとして読み取りレプリカを使用できる
  • 複数の読み取りレプリカがデータのレポートに使用されている間に、テレメトリ情報が MySQL データベース エンジンに取り込まれる、IoT または製造シナリオの場合

レプリカは読み取り専用であるため、ソースへの書き込み容量の負担を直接減らすことにはなりません。 この機能は、書き込み集中型ワークロードを対象としていません。

読み取りレプリカ機能は、MySQL の非同期レプリケーションを使用します。 機能は、同期レプリケーション シナリオを目的としていません。 ソースとレプリカの間には測定可能な遅延が発生します。 レプリカ上のデータは、最終的にソース上のデータと整合するようになります。 この機能は、この遅延に対応できるワークロードに使用してください。

リージョン間レプリケーション

ソース サーバーとは別のリージョンに読み取りレプリカを作成できます。 リージョン間レプリケーションは、ディザスター リカバリー計画や、データをユーザーの所在地の近くに配置するなどのシナリオに役立ちます。 Azure Database for MySQL フレキシブル サーバーを使用すると、Azure Database for MySQL フレキシブル サーバーを使用できる任意のAzure サポートリージョンで読み取りレプリカをプロビジョニングできます。 この機能を使うと、ソース サーバーは、ペアになっているリージョンまたはユニバーサル レプリカ リージョンにレプリカを持つことができます。 Azure Database for MySQL フレキシブル サーバーが現在利用できる Azure リージョンの一覧については、こちらを参照してください。

レプリカの作成

ソース サーバーに既存のレプリカ サーバーがない場合、まずレプリケーションの準備のためにソースが再起動されます。

レプリカの作成ワークフローを開始すると、空の Azure Database for MySQL フレキシブル サーバー インスタンスが作成されます。 新しいサーバーには、ソース サーバー上にあったデータが設定されます。 作成時間は、ソース上のデータ量と、最後の週次完全バックアップからの経過時間に依存します。 時間の範囲は、数分から数時間になる可能性があります。

Note

ソースと同じサーバー構成で、読み取りレプリカが作成されます。 作成された後、レプリカ サーバーの構成を変更できます。 レプリカ サーバーは、ソース サーバーと同じリソース グループおよび同じサブスクリプションに常に作成されます。 レプリカ サーバーを別のリソース グループや別のサブスクリプションに作成したい場合は、作成後にレプリカ サーバーを移動します。 レプリカが確実にソースに追随できるように、レプリカ サーバーの構成をソースと同じかそれ以上の値にしておくことをお勧めします。

Azure portal で読み取りレプリカを作成する方法を確認してください。

レプリカへの接続

作成時に、レプリカはソース サーバーの接続方法を継承します。 ユーザーは、レプリカの接続方法を変更できません。 たとえば、ソース サーバーでプライベート アクセス (VNet 統合) が使用されている場合、レプリカでパブリック アクセス (許可された IP アドレス) を使用することはできません。

レプリカの管理者アカウントは、ソース サーバーから継承されます。 ソース サーバー上のすべてのユーザー アカウントが、読み取りレプリカにレプリケートされます。 ソース サーバー上で使用可能なユーザー アカウントのみを使って読み取りレプリカに接続できます。

通常の Azure Database for MySQL フレキシブル サーバー インスタンスと同様に、ホスト名と有効なユーザー アカウントを使用してレプリカに接続できます。 管理者ユーザー名が myadmin の myreplica というサーバーの場合、mysql CLI を使用して、レプリカに接続できます。

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

メッセージが表示されたら、ユーザー アカウントのパスワードを入力します。

レプリケーションを監視します

Azure Database for MySQL フレキシブル サーバーでは、Azure Monitor のレプリケーションラグ (秒単位) メトリックが提供されます。 このメトリックは、レプリカのみで使用できます。 このメトリックは、MySQL の SHOW SLAVE STATUS コマンドで使用できる seconds_behind_master メトリックを使用して計算されます。 レプリケーションのラグがワークロードに対して許容できない値に達したときに通知されるアラートを設定します。

レプリケーションのラグが増加している場合は、レプリケーションの待機時間のトラブルシューティングに関する記事を参照して、考えられる原因を把握し、トラブルシューティングします。

重要

読み取りレプリカはストレージ ベースのレプリケーション テクノロジを使用します。このテクノロジでは、MySQL の 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' コマンドで使用できる 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' メトリックは使用されなくなりました。 この値は常に "いいえ" と表示され、レプリケーションの状態を示すものではありません。 レプリケーションの正しい状態を確認するには、[監視] ブレードの下にあるレプリケーション メトリック ( レプリカ IO 状態 と レプリカ SQL の状態 ) を参照してください。

レプリケーションの停止

ソースとレプリカの間のレプリケーションを停止できます。 ソース サーバーと読み取りレプリカの間のレプリケーションを停止すると、レプリカがスタンドアロン サーバーになります。 スタンドアロン サーバー内のデータは、レプリケーション停止コマンドが起動された時点でレプリカで使用可能だったデータです。 スタンドアロン サーバーにはソース サーバーへの変更が反映されなくなっています。

レプリカへのレプリケーションを停止すると、以前のソースと他のレプリカへのリンクがすべて失われます。 ソースとそのレプリカの間に自動フェールオーバーはありません。

重要

スタンドアロン サーバーをもう一度レプリカにすることはできません。 読み取りレプリカでレプリケーションを停止する前に、レプリカに必要なすべてのデータがあることを確認してください。

レプリカへのレプリケーションを停止する方法を確認します。

[フェールオーバー]

ソースとレプリカの各サーバー間で、自動フェールオーバーは行われません。

読み取りレプリカは、読み取り中心のワークロードのスケーリングを目的としたものであり、サーバーの高可用性のニーズを満たすようには設計されていません。 この手動フェールオーバーを実行するには、読み取りレプリカでのレプリケーションを停止して、読み取り/書き込みモードでオンラインにします。

レプリケーションは非同期であるため、ソースとレプリカの間にタイム ラグがあります。 タイム ラグは、ソース サーバーで実行されているワークロードの負荷とデータ センター間の待機時間など、多くの要因によって影響を受ける可能性があります。 ほとんどの場合、レプリカのラグは数秒から数分の範囲になります。 各レプリカで利用可能なレプリカのラグ メトリックを使用して、実際のレプリケーションのラグを追跡できます。 このメトリックでは、最後に再生されたトランザクションからの時間が表示されます。 長期間にわたってレプリカのラグを観察することで、平均ラグを特定することをお勧めします。 予想される範囲外に出た場合に対処できるように、レプリカのラグにアラートを設定できます。

ヒント

レプリカにフェールオーバーする場合、ソースからレプリカのリンクを解除したときのラグによって、どれだけのデータが失われたかを示します。

レプリカにフェールオーバーすることを決定したら、次の操作を行います。

  1. レプリカへのレプリケーションを停止する
    この手順では、レプリカ サーバーで書き込みを受け入れられるようにすることが必要です。 このプロセスの一部として、レプリカ サーバーはソースからリンクを解除されます。 レプリケーションの停止を開始すると、通常、バックエンド プロセスは完了するまでに約 2 分かかります。 このアクションの影響を理解するには、この記事の「レプリケーションの停止」セクションを参照してください。

  2. ご利用のアプリケーションが (以前の) レプリカを指すように設定する
    各サーバーには一意の接続文字列があります。 ソースではなく、(以前の) レプリカを指すようにアプリケーションを更新します。

ご利用のアプリケーションで読み取りと書き込みが正常に処理されると、フェールオーバーが完了します。 アプリケーションで経験するダウンタイムは、問題を検出し、上記の手順 1 と 2 を完了したタイミングによって異なります。

グローバル トランザクション識別子 (GTID)

グローバル トランザクション識別子 (GTID) は、ソース サーバー上のコミットされた各トランザクションで作成された一意の識別子であり、Azure Database for MySQL フレキシブル サーバーでは既定ではオフになっています。 GTID はバージョン 5.7 と 8.0 でサポートされています。 GTID の詳細とレプリケーションでの使用方法については、MySQL の GTID を使用したレプリケーションに関するドキュメントを参照してください。

GTID を構成するために、次のサーバー パラメーターを使用できます。

サーバー パラメーター 説明 既定値 値
gtid_mode トランザクションを識別するために GTID を使用するかどうかを示します。 モード間の変更は、一度に 1 つのステップで昇順でのみ実行できます (例: OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF* OFF:新規とレプリケーションのトランザクションの両方が匿名である必要があります
OFF_PERMISSIVE:新しいトランザクションは匿名です。 レプリケートされたトランザクションは、匿名または GTID トランザクションのいずれかにすることができます。
ON_PERMISSIVE:新しいトランザクションは GTID トランザクションです。 レプリケートされたトランザクションは、匿名または GTID トランザクションのいずれかにすることができます。
ON:新規およびレプリケートされたトランザクションは、どちらも GTID トランザクションである必要があります。
enforce_gtid_consistency トランザクション セーフな方法でログに記録できるステートメントのみを実行できるようにすることで、GTID の一貫性を強制的に適用します。 GTID レプリケーションを有効にする前に、この値を ON に設定する必要があります。 OFF* OFF:すべてのトランザクションが GTID の一貫性に違反することが許可されます。
ON:すべてのトランザクションが GTID の一貫性に違反することが許可されません。
WARN:すべてのトランザクションは GTID の一貫性に違反することが許可されますが、警告が生成されます。

高可用性機能が有効になっている Azure Database for MySQL フレキシブル サーバー インスタンスの場合、既定値は ON.

Note

  • いったん GTID を有効になると、無効に戻すことはできません。 GTID をオフにする必要がある場合は、サポートにお問い合わせください。
  • モードの昇順で、一度に 1 つの値から別のステップにのみ GTID を変更できます。 たとえば、gtid_modeが現在OFF_PERMISSIVEに設定されている場合は、ON_PERMISSIVEに変更できますが、ON に変更することはできません。
  • レプリケーションの整合性を維持するために、マスター/レプリカ サーバー用に更新することはできません。
  • gtid_mode=ON に設定する前に、Standard Edition T enforce_gtid_consistencyを ON にすることをお勧めします。

GTID を有効にし、整合性の動作を構成するには、Azure portal または Azure CLI を使用して、サーバー パラメーターとenforce_gtid_consistencyサーバー パラメーターを更新gtid_modeします。

ソース サーバーで GTID が有効になっている場合 (gtid_mode = ON)、新しく作成されたレプリカでも GTID が有効になり、GTID レプリケーションが使用されます。 レプリケーションの一貫性を確保するために、GTID が有効になっているマスターまたはレプリカ サーバーを作成した後で gtid_mode を変更することはできません。

考慮事項と制限事項

シナリオ 制限と考慮事項
バースト可能価格レベルでのサーバー上のレプリカ サポートされていません
価格 レプリカ サーバーの実行のコストは、レプリカ サーバーが実行されているリージョンに基づきます
ソース サーバーの再起動 既存のレプリカがないソースのレプリカを作成すると、ソースは最初に、レプリケーションの準備をするために再起動します。 これを考慮して、これらの操作はオフピーク期間中に実行します
新しいレプリカ 読み取りレプリカは、新しい Azure Database for MySQL フレキシブル サーバー インスタンスとして作成されます。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成することはできません。
レプリカ構成 レプリカは、ソースと同じサーバー構成を使用して作成されます。 レプリカが作成されたら、ソース サーバーとは独立していくつかの設定 (コンピューティング世代、仮想コア、ストレージ、バックアップ保持期間) を変更できます。 コンピューティング レベルは、個別に変更することもできます。

重要 - ソース サーバーの構成を新しい値に更新する前に、レプリカ構成を等しいかそれ以上の値に更新します。 このアクションにより、ソースに対して行われたすべての変更をレプリカで把握できるようになります。
接続方法とパラメーターの設定は、レプリカの作成時に、ソース サーバーからレプリカに継承されます。 その後、レプリカの規則は独立したものなります。
停止されたレプリカ ソース サーバーと読み取りレプリカの間のレプリケーションを停止すると、停止されたレプリカは、読み取りと書き込みの両方を受け入れるスタンドアロン サーバーになります。 スタンドアロン サーバーをもう一度レプリカにすることはできません。
削除されたソースおよびスタンドアロン サーバー ソース サーバーが削除されると、すべての読み取りレプリカへのレプリケーションが停止されます。 これらのレプリカは自動的にスタンドアロン サーバーになり、読み取りと書き込みの両方を受け入れることができます。 ソース サーバー自体は削除されます。
ユーザー アカウント ソース サーバー上のユーザーは、読み取りレプリカにレプリケートされます。 ソース サーバー上で使用可能なユーザー アカウントのみを使って読み取りレプリカに接続できます。
サーバー パラメーター データが非同期にならないようにするため、また潜在的なデータの損失や破損を防ぐために、一部のサーバー パラメーターは、読み取りレプリカの使用時に更新されないようにロックされます。
次のサーバー パラメーターは、ソースとレプリカの両サーバーでロックされます。
- innodb_file_per_table
- log_bin_trust_function_creators
event_scheduler パラメーターは、レプリカ サーバーでロックされます。
ソース サーバーで上記のパラメーターのいずれかを更新するには、レプリカ サーバーを削除し、ソースでパラメーターの値を更新してから、レプリカを再作成してください。
セッション レベル パラメーター 読み取りレプリカで「foreign_keys_checks」などのセッション レベルのパラメーターを構成する場合は、読み取りレプリカで設定されているパラメーター値がソース サーバーのパラメーター値と一致していることを確認してください。
ソース サーバーの既存のテーブルに AUTO_INCREMENT 主キー列を追加する。 レプリケーションが中断するため、読み取りレプリカの作成後に AUTO_INCREMENT によってテーブルを変更することはお勧めしません。 ただし、レプリカ サーバーの作成後に自動インクリメント列を追加する場合は、次の 2 つの方法をお勧めします。
- 変更するテーブルと同じスキーマを持つ新しいテーブルを作成します。 その新しいテーブルで、AUTO_INCREMENT によって列を変更し、元のテーブルからデータを復元します。 ソースで古いテーブルをドロップして名前を変更します。この場合、レプリカ サーバーを削除する必要はありませんが、バックアップ テーブルの作成に多くの挿入コストが必要になる可能性があります。
- もう 1 つの簡単な方法は、すべての自動増加列を追加した後にレプリカを再作成することです。
その他 - レプリカのレプリカを作成することはサポートされていません。
- メモリ内テーブルを使用すると、レプリカが同期しなくなる可能性があります。これは、MySQL レプリケーション テクノロジの制限事項です。 詳細については、MySQL のリファレンス ドキュメントをお読みください。
- ソース サーバーのテーブルに主キーがあることを確認します。 主キーがないと、ソースとレプリカ間でレプリケーションの待機時間が発生する可能性があります。
- MySQL のレプリケーションの制限事項の完全な一覧については、MySQL のドキュメントを確認してください

次のステップ