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

[アーティクル]
06/01/2023

重要

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 サーバーの場合と同じように、そのホスト名と有効なユーザーアカウントを使用して、レプリカに接続できます。管理者ユーザー名が myadmin の myreplica というサーバーの場合、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 メトリックを使用して計算されます。

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

レプリケーションの停止

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

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

重要

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

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

[フェールオーバー]

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

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

ヒント

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

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

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

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

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

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

考慮事項と制限事項

価格レベル

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

注意

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

ソースサーバーの再起動

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

新しいレプリカ

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

レプリカ構成

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

重要

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

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

停止されたレプリカ

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

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

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

ユーザーアカウント

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

サーバーパラメーター

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

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

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

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

その他

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

次のステップ

Azure portal を使用して読み取りレプリカの作成と管理を行う方法について確認する。
Azure CLI と REST API を使用して読み取りレプリカの作成と管理を行う方法について確認する。