MySQL は、インターネット規模の Web およびモバイル アプリケーションを実行するための一般的なデータベース エンジンの 1 つです。 多くのお客様は、オンライン教育、ビデオ ストリーミング、デジタル支払い、eコマース、ゲーム、ニュース ポータル、政府機関、医療 Web サイトなど、さまざまなアプリケーションに Azure Database for MySQL を使用しています。 これらのサービスは、Web またはモバイル アプリケーション上のトラフィックの増加に応じてサービスを提供し、スケーリングできる必要があります。
アプリケーション側では、開発者は通常 Java または PHP を使用します。 アプリケーションを移行して Azure Virtual Machine Scale Sets、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/月) に基づいて、読み取りレプリカごとに課金料金が発生します。 詳細については、価格に関するページを参照してください。
読み取りレプリカ機能を利用できるのは、General Purpose または Business Critical の価格レベルの Azure Database for MySQL フレキシブル サーバー インスタンスでだけです。 ソース サーバーがこれらの価格レベルのいずれであるかを確認します。
MySQL レプリケーションの機能と問題の詳細については、MySQL レプリケーションに関するドキュメントを参照してください。
注
この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアから用語を削除すると、この記事から削除されます。
読み取りレプリカの一般的なユース ケース
読み取りレプリカ機能を使用すると、読み取り集中型ワークロードのパフォーマンスとスケールを向上させることができます。 書き込みワークロードをソースに送信しながら、読み取りワークロードをレプリカに分離できます。
一般的なシナリオは次のとおりです。
- ProxySQL などの軽量接続プロキシを使用するか、マイクロサービス ベースのパターンを使用してアプリケーションから送信される読み取りクエリを読み取りレプリカにスケールアウトすることで、アプリケーションから送信される読み取りワークロードをスケーリングする
- 読み取りレプリカを BI または分析レポート ワークロードのデータ ソースとして使用する
- IoT または製造シナリオでのデータのレポートに複数の読み取りレプリカを使用しながら、MySQL データベース エンジンにテレメトリ情報を取り込む
レプリカは読み取り専用であるため、ソースへの書き込み容量の負担を直接減らすことにはなりません。 この機能は、書き込み集中型ワークロードを対象としていません。
読み取りレプリカ機能は、MySQL の非同期レプリケーションを使用します。 機能は、同期レプリケーション シナリオを目的としていません。 ソースとレプリカの間には測定可能な遅延が発生します。 レプリカ上のデータは、最終的にソース上のデータと整合するようになります。 この機能は、この遅延に対応できるワークロードに使用してください。
リージョン間レプリケーション
ソース サーバーとは別のリージョンに読み取りレプリカを作成できます。 リージョン間レプリケーションは、ディザスター リカバリー計画や、データをユーザーの所在地の近くに配置するなどのシナリオに役立ちます。 Azure Database for MySQL フレキシブル サーバーを使用すると、Azure Database for MySQL フレキシブル サーバーを使用できる 、Azure でサポートされている任意のリージョン に読み取りレプリカをプロビジョニングできます。 この機能を使うと、ソース サーバーは、ペアになっているリージョンまたはユニバーサル レプリカ リージョンにレプリカを持つことができます。 Azure Database for MySQL フレキシブル サーバーが現在使用できる Azure リージョンの一覧については、 こちらを 参照してください。
レプリカの作成
レプリカの作成ワークフローを開始するときに、空の Azure Database for MySQL フレキシブル サーバー インスタンスを作成します。 新しいサーバーには、ソース サーバー上にあったデータが含まれています。 作成時間は、ソース上のデータ量と、最後の週次完全バックアップからの経過時間に依存します。 時間の範囲は、数分から数時間になる可能性があります。
注
ソースと同じサーバー構成で読み取りレプリカを作成します。 レプリカ サーバーの構成は、作成後に変更できます。 レプリカ サーバーは、ソース サーバーと同じリソース グループとサブスクリプションに常に作成します。 別のリソース グループまたは別のサブスクリプションにレプリカ サーバーを作成する場合は、作成後 にレプリカ サーバーを移動 できます。 レプリカ サーバーの構成をソースと同じかそれ以上の値に保ち、レプリカがソースに対応できるようにします。
Azure portal で読み取りレプリカを作成する方法を確認してください。
レプリカへの接続
レプリカを作成すると、ソース サーバーの接続方法が継承されます。 ユーザーは、レプリカの接続方法を変更できません。 たとえば、ソース サーバーが プライベート アクセス (VNet 統合) を使用している場合、レプリカは パブリック アクセス (許可された IP アドレス) を使用できません。
レプリカの管理者アカウントは、ソース サーバーから継承されます。 ソース サーバー上のすべてのユーザー アカウントが、読み取りレプリカにレプリケートされます。 読み取りレプリカに接続できるのは、ソース サーバーで使用可能なユーザー アカウントを使用することだけです。
レプリカには、通常の Azure Database for MySQL フレキシブル サーバー インスタンスの場合と同様に、ホスト名と有効なユーザー アカウントを使用することで接続できます。 myreplica という名前のサーバーと管理者ユーザー名 myadmin の場合は、MySQL CLI を使用してレプリカに接続できます。
mysql -h myreplica.mysql.database.azure.com -u myadmin -p
メッセージが表示されたら、ユーザー アカウントのパスワードを入力します。
レプリケーションを監視します
Azure Database for MySQL フレキシブル サーバーにより、Azure Monitor にレプリケーションのラグ (秒単位) メトリックが提供されます。 このメトリックは、レプリカのみで使用できます。 Azure Monitor では、MySQL の SHOW SLAVE STATUS コマンドでseconds_behind_master メトリックを使用して、このメトリックが計算されます。 レプリケーションのラグがワークロードの許容できないしきい値を超えたときに通知するアラートを設定します。
レプリケーションのラグが増加している場合は、レプリケーションの待機時間のトラブルシューティングに関する記事を参照して、考えられる原因を把握し、トラブルシューティングします。
重要
読み取りレプリカでは、ストレージ ベースのレプリケーション テクノロジが使用されます。このテクノロジでは、MySQL の SHOW SLAVESTATUS'/'SHOWREPLICA STATUS コマンドで使用できるSLAVE_IO_RUNNING/REPLICA_IO_RUNNING メトリックは使用されなくなりました。 この値は常に "いいえ" と表示され、レプリケーションの状態を示すわけではありません。 レプリケーションの正しい状態を確認するには、[監視] ページの下にあるレプリケーション メトリック ( レプリカ IO 状態 と レプリカ SQL の状態 ) を参照してください。
レプリケーションの停止
ソース サーバーとレプリカ サーバーの間のレプリケーションを停止できます。 ソース サーバーと読み取りレプリカの間のレプリケーションを停止すると、レプリカ サーバーはスタンドアロン サーバーになります。 スタンドアロン サーバーには、レプリケーションの停止コマンドを開始したときにレプリカ サーバーで使用できたデータが含まれています。 スタンドアロン サーバーは、不足しているデータをソース サーバーから同期しません。
レプリカ サーバーへのレプリケーションを停止すると、レプリカ サーバーは以前のソース サーバーと他のレプリカ サーバーへのリンクをすべて失います。 ソース サーバーとそのレプリカ サーバーの間に自動フェールオーバーはありません。
重要
スタンドアロン サーバーをレプリカ サーバーに変換することはできません。 読み取りレプリカでのレプリケーションを停止する前に、レプリカ サーバーに必要なすべてのデータがあることを確認します。
詳細については、「 レプリカへのレプリケーションの停止」を参照してください。
[フェールオーバー]
ソースとレプリカの各サーバー間で、自動フェールオーバーは行われません。
読み取りレプリカは読み取り集中型ワークロードをスケーリングし、サーバーの高可用性を提供しません。 手動フェールオーバーを実行するには、読み取り/書き込みモードでオンラインにすることで、読み取りレプリカのレプリケーションを停止します。
レプリケーションは非同期であるため、ソースとレプリカの間には遅延があります。 ソース サーバー上のワークロードやデータ センター間の待機時間など、多くの要因がラグの量に影響します。 ほとんどの場合、レプリカのラグの範囲は数秒から数分です。 各レプリカで使用できるレプリカ ラグ メトリックを使用して、実際のレプリケーション のラグ を追跡できます。 このメトリックでは、最後に再生されたトランザクションからの時間が表示されます。 時間の経過に伴うレプリカのラグを観察して、平均ラグを特定することをお勧めします。 予想される範囲外に出た場合に対処できるように、レプリカのラグにアラートを設定できます。
ヒント
レプリカにフェールオーバーした場合、ソースからレプリカのリンクを解除した時点のラグは、失われたデータの量を示します。
レプリカへのフェールオーバーを決定した後:
レプリカへのレプリケーションを停止する
レプリカ サーバーが書き込みを受け入れるようにするには、レプリケーションを停止する必要があります。 このプロセスにより、レプリカ サーバーのリンクがソースから解除されます。 レプリケーションの停止を開始した後、バックエンド プロセスは通常、完了するまでに約 2 分かかります。 このアクションの影響を理解するには、この記事の「レプリケーションの停止」セクションを参照してください。
ご利用のアプリケーションが (以前の) レプリカを指すように設定する
各サーバーには一意の接続文字列があります。 ソースではなく、(以前の) レプリカを指すようにアプリケーションを更新します。
アプリケーションが読み取りと書き込みを正常に処理したら、フェールオーバーを完了します。 アプリケーションで発生するダウンタイムの量は、問題を検出し、手順 1 と 2 を完了するタイミングによって異なります。
グローバル トランザクション識別子 (GTID)
グローバル トランザクション識別子 (GTID) は、コミットされた各トランザクションでソース サーバーが作成する一意の識別子です。 Azure Database for MySQL フレキシブル サーバーでは、既定で GTID がオフになります。 バージョン 5.7 および 8.0 では GTID がサポートされています。 GTID とその使用方法の詳細については、 GTID を使用した MySQL のレプリケーションに関するドキュメントを参照してください。
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 に設定されます。
GTID を有効にした後は、オフにすることはできません。 GTID をオフにする必要がある場合は、サポートにお問い合わせください。
GTID をある値から別の値に変更できるのは、モードの昇順で一度に 1 ステップずつのみです。 たとえば、 gtid_mode が現在 OFF_PERMISSIVEに設定されている場合は、 ON_PERMISSIVE に変更できますが、 ONに変更することはできません。
レプリケーションの整合性を維持するために、プライマリ サーバーまたはレプリカ サーバーに対してレプリケーションを更新することはできません。
gtid_modeを ON に設定する前に、enforce_gtid_consistencyを ON に設定します。
GTID を有効にし、整合性の動作を構成するには、 gtid_mode と enforce_gtid_consistency サーバー パラメーターを更新します。
Azure portal を使用して Azure Database for MySQL - フレキシブル サーバーのサーバー パラメーターを構成するか、Azure CLI を使用して Azure Database for MySQL - フレキシブル サーバーでサーバー パラメーターを構成します。
ソース サーバーで GTID (gtid_mode = ON) が有効になっている場合、新しく作成されたレプリカでも GTID が有効になり、GTID レプリケーションが使用されます。 レプリケーションの一貫性を確保するために、GTID が有効になっているプライマリ サーバーまたはレプリカ サーバーを作成した後で gtid_mode を変更することはできません。
考慮事項と制限事項
| シナリオ | 制限と考慮事項 |
|---|---|
| バースト可能価格レベルでのサーバー上のレプリカ | サポートされていません |
| 価格 | レプリカ サーバーを実行するコストは、レプリカ サーバーが実行されているリージョンによって異なります。 |
| ソース サーバーのダウンタイム/再起動 | 読み取りレプリカを作成するときに、再起動やダウンタイムは必要ありません。 この操作はオンライン操作です。 |
| 新しいレプリカ | 読み取りレプリカは、新しい Azure Database for MySQL フレキシブル サーバー インスタンスとして作成します。 既存のサーバーをレプリカにすることはできません。 別の読み取りレプリカのレプリカを作成することはできません。 |
| レプリカ構成 | レプリカは、ソースと同じサーバー構成を使用して作成します。 レプリカを作成した後、ソース サーバーとは別に、コンピューティングの生成、仮想コア、ストレージ、バックアップのリテンション期間など、いくつかの設定を変更できます。 コンピューティング レベルを個別に変更することもできます。 重要 - ソース サーバー構成を新しい値に更新する前に、レプリカ構成を等しいかそれ以上の値に更新します。 このアクションにより、ソースに対して行われたすべての変更をレプリカで把握できるようになります。 接続方法とパラメーターの設定は、レプリカの作成時にソース サーバーからレプリカに継承されます。 その後、レプリカの規則は独立したものなります。 |
| 停止されたレプリカ | ソース サーバーと読み取りレプリカの間のレプリケーションを停止すると、停止されたレプリカは、読み取りと書き込みの両方を受け入れるスタンドアロン サーバーになります。 スタンドアロン サーバーを再びレプリカにすることはできません。 |
| 削除されたソース サーバー | ソース サーバーを削除すると、すべての読み取りレプリカへのレプリケーションが停止します。 これらのレプリカは自動的にスタンドアロン サーバーになり、読み取りと書き込みの両方を受け入れることができます。 ソース サーバー自体は削除されます。 |
| ユーザー アカウント | ソース サーバー上のユーザーは、読み取りレプリカにレプリケートされます。 読み取りレプリカに接続できるのは、ソース サーバーで使用可能なユーザー アカウントを使用することだけです。 |
| サーバー パラメーター | データが非同期にならないようにするため、また潜在的なデータの損失や破損を防ぐために、一部のサーバー パラメーターは、読み取りレプリカの使用時に更新されないようにロックされます。 次のサーバー パラメーターは、ソースとレプリカの両サーバーでロックされます。 - innodb_file_per_table- log_bin_trust_function_creatorsevent_scheduler パラメーターは、レプリカ サーバーでロックされます。ソース サーバーで上記のパラメーターのいずれかを更新するには、レプリカ サーバーを削除し、ソースのパラメーター値を更新して、レプリカを再作成します。 |
| セッション レベル パラメーター | 読み取りレプリカでセッション レベルのパラメーター ("foreign_keys_checks" など) を構成する場合は、読み取りレプリカで設定するパラメーター値がソース サーバーのパラメーター値と一致していることを確認します。 |
| ソース サーバーの既存のテーブルに AUTO_INCREMENT 主キー列を追加する | 読み取りレプリカを作成した後、 AUTO_INCREMENT を使用してテーブルを変更することはお勧めしません。これは、レプリケーションが中断されるためです。 レプリカ サーバーの作成後に自動インクリメント列を追加する場合は、次の方法を検討してください。- 変更するテーブルと同じスキーマを持つ新しいテーブルを作成します。 新しいテーブルで、 AUTO_INCREMENTを使用して列を変更し、元のテーブルからデータを復元します。 古いテーブルを削除し、ソースで名前を変更します。この方法ではレプリカ サーバーを削除する必要はありませんが、バックアップ テーブルを作成するために大きな挿入コストが発生する可能性があります。- すべての自動インクリメント列を追加した後、レプリカを再作成します。 |
| その他 | - レプリカのレプリカを作成することはサポートされていません。 - メモリ内テーブルによってレプリカが同期しなくなる可能性があります。この制限は、MySQL レプリケーション テクノロジが原因です。 詳細については、 MySQL リファレンス ドキュメントを参照してください。 - ソース サーバーのテーブルに主キーがあることを確認します。 主キーがないと、ソースとレプリカ間でレプリケーションの待機時間が発生する可能性があります。 - MySQL ドキュメントの MySQL レプリケーションの制限事項の完全な一覧を確認します。 |