次の方法で共有


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

重要

Azure Database for MariaDB は、提供終了予定です。 Azure Database for MySQL に移行することを強くお勧めします。 Azure Database for MySQL への移行の詳細については、「Azure Database for MariaDB の現状」を参照してください

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

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

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

Note

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

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

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

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

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

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

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

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

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

読み取りレプリカ リージョン

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

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

オーストラリア東部、オーストラリア南東部、ブラジル南部、カナダ中部、カナダ東部、米国中部、東アジア、米国東部、米国東部 2、東日本、西日本、韓国中部、韓国南部、米国中北部、北ヨーロッパ、米国中南部、東南アジア、英国南部、英国西部、西ヨーロッパ、米国西部、米国西部 2、米国中西部。

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

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

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

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

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

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

レプリカの作成

重要

読み取りレプリカ機能は、汎用またはメモリ最適化の価格レベルの Azure Database for MariaDB サーバーにのみ使用可能です。 ソース サーバーがこれらの価格レベルのいずれであるかを確認します。

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

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

Note

サーバーに記憶域のアラートを設定していない場合、設定することをお勧めします。 サーバーがレプリケーションに影響を与えるその容量の上限に近づくと、アラートによって通知されます。

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

レプリカへの接続

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

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

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

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

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

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

Azure Database for MariaDB は、Azure Monitor にレプリケーションのラグ (秒単位) メトリックを提供しています。 このメトリックは、レプリカのみで使用できます。

このメトリックは、MariaDB の SHOW SLAVE STATUS コマンドで使用できる seconds_behind_master メトリックを使用して計算されます。

レプリケーションのラグがワークロードに対して許容できない値に達したときに通知されるアラートを設定します。

レプリケーションの停止

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

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

重要

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

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

[フェールオーバー]

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

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

ヒント

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

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

  1. レプリカへのレプリケーションを停止する。

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

  2. ご利用のアプリケーションが (以前の) レプリカを指すように設定する。

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

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

考慮事項と制限事項

価格レベル

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

注意

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

ソース サーバーの再起動

既存のレプリカがないソースのレプリカを作成すると、ソースは最初に、レプリケーションの準備をするために再起動します。 これを考慮して、これらの操作はオフピーク期間中に実行してください。

新しいレプリカ

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

レプリカ構成

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

重要

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

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

停止されたレプリカ

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

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

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

ユーザー アカウント

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

サーバー パラメーター

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

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

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

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

その他

  • レプリカのレプリカの作成はサポートされていません。
  • インメモリ テーブルを使用すると、レプリカの同期が解除される可能性があります。これは、MariaDB レプリケーション テクノロジの制限事項です。
  • ソース サーバーのテーブルに主キーがあることを確認します。 主キーがないと、ソースとレプリカ間でレプリケーションの待機時間が発生する可能性があります。

次のステップ