Azure Database for MySQL の読み取りレプリカ

  • [アーティクル]

適用対象: Azure Database for MySQL - シングル サーバー

重要

Azure Database for MySQL の単一サーバーは提供終了パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、「Azure Database for MySQL 単一サーバーの動作」を参照してください 。

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

レプリカは、通常の Azure Database for MySQL サーバーと同様に管理する新しいサーバーです。 読み取りレプリカごとに、仮想コアおよびストレージのプロビジョニング済みコンピューティング (GB/月) に対して課金されます。

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

Note

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

読み取りレプリカを使用する場合

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

BI ワークロードおよび分析ワークロードでレポート用のデータ ソースとして使用するのが、読み取りレプリカの一般的なシナリオです。

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

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

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

ソース サーバーとは別のリージョンに読み取りレプリカを作成できます。 リージョン間レプリケーションは、ディザスター リカバリー計画や、データをユーザーの所在地の近くに配置するなどのシナリオに役立ちます。

任意の Azure Database for MySQL リージョンにソース サーバーを作成できます。 ソース サーバーは、ペアになっているリージョンまたはユニバーサル レプリカ リージョンにレプリカを持つことができます。 次の図は、ソース リージョンに応じて使用できるレプリカ リージョンを示しています。

ユニバーサル レプリカ リージョン

ソース サーバーが配置されている場所に関係なく、次のいずれかのリージョンに読み取りレプリカを作成できます。 サポートされているユニバーサル レプリカ リージョンは次のとおりです。

リージョン レプリカの可用性
オーストラリア東部 ✔️
オーストラリア東南部 ✔️
ブラジル南部 ✔️
カナダ中部 ✔️
カナダ東部 ✔️
米国中部 ✔️
米国東部 ✔️
米国東部 2 ✔️
東アジア ✔️
東日本 ✔️
西日本 ✔️
韓国中部 ✔️
韓国南部 ✔️
北ヨーロッパ ✔️
米国中北部 ✔️
米国中南部 ✔️
東南アジア ✔️
スイス北部 ✔️
英国南部 ✔️
英国西部 ✔️
米国中西部 ✔️
米国西部 ✔️
米国西部 2 ✔️
西ヨーロッパ ✔️
インド中部* ✔️
フランス中部* ✔️
アラブ首長国連邦北部* ✔️
南アフリカ北部* ✔️

Note

*パブリック プレビューで Azure Database for MySQL に General Purpose ストレージ v2 があるリージョン
*これらの Azure リージョンでは、General Purpose Storage v1 と v2 の両方でサーバーを作成できます。 パブリック プレビュー段階の General Purpose Storage v2 を使用して作成されたサーバーの場合、レプリカ サーバーは、General Purpose Storage v2 をサポートする Azure リージョン内でのみ作成できます。

ペアになっているリージョン

ユニバーサル レプリカ リージョンに加えて、ソース サーバーの Azure のペアになっているリージョンに読み取りレプリカを作成できます。 リージョンのペアがわからない場合は、Azure のペアになっているリージョンに関する記事を参照してください。

ディザスター リカバリー計画にリージョン間レプリカを使用している場合、レプリカの作成場所は別のリージョンのいずれか 1 つではなく、ペアになっているリージョンにすることをお勧めします。 ペアになっているリージョンでは、同時更新を避け、物理的な分離とデータの保存に優先順位を付けます。

ただし、考慮すべきいくつかの制限があります。

  • リージョン別の提供状況Azure Database for MySQL は、フランス中部、アラブ首長国連邦北部、およびドイツ中部で利用できます。 ただし、それらのペアになっているリージョンは使用できません。

  • 一方向のペア:一部の Azure リージョンは一方向にのみペアになっています。 これらのリージョンには、インド西部、ブラジル南部、および US Gov バージニアが含まれます。 これは、インド西部のソース サーバーでインド南部にレプリカを作成できることを意味します。 ただし、インド南部のソース サーバーでインド西部にレプリカを作成することはできません。 この理由は、インド西部のセカンダリ リージョンはインド南部ですが、インド南部のセカンダリ リージョンはインド西部ではないためです。

レプリカの作成

重要

  • 読み取りレプリカ機能は、汎用とメモリ最適化のどちらかの価格レベルにおける Azure Database for MySQL サーバーにのみ使用可能です。 ソース サーバーがこれらの価格レベルのいずれであるかを確認します。
  • 使用されているストレージ (v1 または v2) によっては、ソース サーバーに既存のレプリカ サーバーが存在しない場合、レプリケーションに備えるためにソース サーバーの再起動が必要となる場合があります。 サーバーの再起動を検討して、ピーク時間外にその操作を行ってください。 詳細については、「ソース サーバーの再起動」を参照してください。

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

すべてのレプリカでストレージの自動拡張が有効になっています。 自動拡張機能により、レプリカはレプリケートされるデータに追従していくことができ、ストレージ不足エラーによって発生するレプリケーションの中断が防止されます。

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

レプリカへの接続

レプリカには、作成時にソース サーバーのファイアウォール規則が継承されます。 その後、これらの規則はソース サーバーから独立したものになります。

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

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

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

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

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

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

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

レプリケーションの停止

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

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

重要

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

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

[フェールオーバー]

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

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

ヒント

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

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

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

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

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

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

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

MySQL では、次の 2 種類のトランザクションがサポートされます。GTID トランザクション (GTID で識別) と匿名トランザクション (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 の一貫性に違反することが許可されますが、警告が生成されます。

Note

  • いったん GTID を有効になると、無効に戻すことはできません。 GTID をオフにする必要がある場合は、サポートにお問い合わせください。

  • GTID をある値から別の値に変更するには、一度に 1 つのステップをモードの昇順で実行します。 たとえば、gtid_mode が現在 OFF_PERMISSIVE に設定されている場合、ON_PERMISSIVE に変更することはできますが、ON にはできません。

  • レプリケーションの整合性を維持するために、マスターまたはレプリカ サーバーに対してこれを更新することはできません。

  • gtid_mode=ON を設定する前に enforce_gtid_consistency を ON に設定することをお勧めします

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

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

考慮事項と制限事項

価格レベル

読み取りレプリカは現在、General Purpose 価格レベルとメモリ最適化価格レベルでのみ使用できます。

注意

レプリカ サーバーの実行にかかるコストは、レプリカ サーバーが実行されているリージョンに基づいています。

ソース サーバーの再起動

汎用ストレージ v1 を使用しているサーバーでは、log_bin パラメーターが既定では OFF になります。 最初の読み取りレプリカを作成するとき、この値が ON になります。 ソース サーバーに既存の読み取りレプリカがない場合、まずレプリケーションの準備のためにソース サーバーが再起動されます。 サーバーの再起動を検討して、ピーク時間外にその操作を行ってください。

汎用ストレージ v2 を使用しているソース サーバーでは、log_bin パラメーターが既定で ON になります。読み取りレプリカを追加するときに再起動する必要はありません。

新しいレプリカ

読み取りレプリカは、新しい Azure Database for MySQL サーバーとして作成されます。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成することはできません。

レプリカ構成

レプリカは、ソースと同じサーバー構成を使用して作成されます。 レプリカが作成されたら、ソース サーバーとは独立していくつかの設定 (コンピューティング世代、仮想コア、ストレージ、バックアップ保持期間) を変更できます。 価格レベルも独立して変更できます (Basic レベルへの変更や Basic レベルからの変更を除く)。

重要

ソース サーバー構成を新しい値に更新する前に、レプリカ構成を新しい値またはそれより大きな値に更新してください。 このアクションにより、ソースに対して行われたすべての変更をレプリカで把握できるようになります。

ファイアウォール規則とパラメーターの設定は、レプリカの作成時にソース サーバーからレプリカに継承されます。 その後、レプリカの規則は独立したものなります。

停止されたレプリカ

ソース サーバーと読み取りレプリカの間のレプリケーションを停止すると、停止されたレプリカは、読み取りと書き込みの両方を受け入れるスタンドアロン サーバーになります。 スタンドアロン サーバーをもう一度レプリカにすることはできません。

削除されたソースおよびスタンドアロン サーバー

ソース サーバーが削除されると、すべての読み取りレプリカへのレプリケーションが停止されます。 これらのレプリカは自動的にスタンドアロン サーバーになり、読み取りと書き込みの両方を受け入れることができます。 ソース サーバー自体は削除されます。

ユーザー アカウント

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

サーバー パラメーター

データが非同期にならないようにするため、また潜在的なデータの損失や破損を防ぐために、一部のサーバー パラメーターは、読み取りレプリカの使用時に更新されないようにロックされます。

次のサーバー パラメーターは、ソースとレプリカの両サーバーでロックされます。

event_scheduler パラメーターは、レプリカ サーバーでロックされます。

ソース サーバーで上記のパラメーターのいずれかを更新するには、レプリカ サーバーを削除し、ソースでパラメーターの値を更新してから、レプリカを再作成してください。

GTID

GTID は以下でサポートされています。

  • MySQL バージョン 5.7 および 8.0。
  • 最大 16 TB のストレージをサポートするサーバー。 16 TB のストレージをサポートするリージョンの完全な一覧については、価格レベルに関する記事をご覧ください。

GTID は既定では無効になっています。 いったん GTID を有効になると、無効に戻すことはできません。 GTID をオフにする必要がある場合は、サポートにお問い合わせください。

ソース サーバーで GTID が有効になっている場合、新しく作成されたレプリカでも GTID が有効になり、GTID レプリケーションが使用されます。 レプリケーションの整合性を維持するために、ソースまたはレプリカ サーバーの gtid_mode を更新することはできません。

その他

  • レプリカのレプリカを作成することはサポートされていません。
  • インメモリ テーブルを使用すると、レプリカの同期が解除される可能性があります。これは、MySQL レプリケーション テクノロジの制限事項です。 詳細については、MySQL のリファレンス ドキュメントをお読みください。
  • ソース サーバーのテーブルに主キーがあることを確認します。 主キーがないと、ソースとレプリカ間でレプリケーションの待機時間が発生する可能性があります。
  • MySQL レプリケーションの制限事項の完全な一覧については、MySQL のドキュメントをご確認ください。

次のステップ