高可用性は Azure Database for MySQL の重要な機能であり、ダウンタイムを最小限に抑え、計画メンテナンス中や予期しない停止時でもアプリケーションにアクセスできるように設計されています。 この記事では、高可用性 (HA) オプション、課金、フェールオーバー プロセス、パフォーマンスへの影響、ベスト プラクティスに関する一般的な質問について説明します。これは、Azure 上の MySQL ワークロードに関する情報に基づいた意思決定を行う際に役立ちます。
ローカル冗長とゾーン冗長 HA 対応フレキシブル サーバーの SLA は何ですか?
Azure Database for MySQL フレキシブル サーバーの SLA 情報は、Azure Database for MySQL の SLA で確認できます。
高可用性 (HA) サーバーに対してはどのように請求されますか?
HA で有効にされたサーバーには、プライマリ レプリカとセカンダリ レプリカがあります。 セカンダリ レプリカは、同じゾーンまたはゾーン冗長に含めることができます。 プライマリ レプリカとセカンダリ レプリカの両方について、プロビジョニングされたコンピューティングとストレージに対し、料金が発生します。 たとえば、コンピューティングの仮想コアが 4 個、プロビジョニングされたストレージが 512 GB のプライマリがある場合、セカンダリ レプリカには 4 個の仮想コアと 512 GB のプロビジョニング済みストレージがあります。
ゾーン冗長 HA サーバーは、8 個の仮想コアと 1,024 GB のストレージに対して課金されます。 バックアップ ストレージ ボリュームによっては、バックアップ ストレージの請求が発生する場合もあります。
読み取りまたは書き込み操作にスタンバイ レプリカを使用できますか?
スタンバイ サーバーは、読み取りまたは書き込み操作には使用できません。 高速フェールオーバーを可能にするためのパッシブ スタンバイです。
フェールオーバーの発生時にデータ損失はありますか?
ZRS のログには、プライマリ サーバーが使用できない場合でもアクセスできます。 この可用性により、データが失われないことが保証されます。 スタンバイ レプリカがアクティブにされて、バイナリ ログが適用された後は、それがプライマリ サーバーの役割を引き継ぎます。
フェールオーバーの後に、何かを実行する必要がありますか?
フェールオーバーは、クライアント アプリケーションにとって完全に透明です。 実行すべきアクションはありません。 アプリケーションで必要なのは、接続のための再試行ロジックを使用することだけです。
スタンバイ レプリカに特定のゾーンを選択しないとどうなりますか。 後でゾーンを変更できますか?
ゾーンを選択しない場合は、ランダムに選択されます。 プライマリ サーバーに使用されるサーバーです。 後でゾーンを変更するには、[高可用性] ウィンドウで [高可用性] を [無効] に設定し、ゾーン冗長に戻してゾーンを選択します。
プライマリとスタンバイ レプリカの間でレプリケーションは同期しますか?
プライマリとスタンバイの間のレプリケーションは、MySQL の 半同期モード と似ています。 トランザクションがコミットされるとき、必ずしもスタンバイにコミットされるとは限りません。 ただし、プライマリが使用できない場合、スタンバイはプライマリからすべてのデータ変更をレプリケートして、データ損失がないことを確認します。
計画外のすべての障害に対し、スタンバイ レプリカへのフェールオーバーが行われますか?
データベースのクラッシュまたはノード障害が発生した場合、フレキシブル サーバー VM は同じノードで再起動されます。 同時に、自動フェールオーバーがトリガーされます。 フェールオーバーが完了する前にフレキシブル サーバー VM の再起動が成功した場合、フェールオーバー操作は取り消されます。 プライマリ レプリカとして使用するサーバーの決定は、最初に完了するプロセスによって異なります。
HA を使用した場合パフォーマンスに影響がありますか?
ゾーン冗長 HA の場合、可用性ゾーン間の読み取りワークロードのパフォーマンスに大きな影響はありませんが、書き込みクエリの待機時間が最大 40% 低下する可能性があります。 書き込み待ち時間の増加は可用性ゾーン全体の同期レプリケーションに起因します。 書き込み待機時間の影響は、同じゾーン HA と比較して、ゾーン冗長 HA では 2 倍大きくなります。 ローカル冗長 HA の場合、プライマリ レプリカとスタンバイ レプリカが同じゾーンにあるため、レプリケーションの待機時間が長くなり、同期書き込み待機時間が短くなります。
要約すると、可用性と比較して書き込み待機時間が重要な場合は、ローカル冗長 HA を選択することもできますが、書き込み待機時間の低下を犠牲にしてデータの可用性と回復性がより重要な場合は、ゾーン冗長 HA を選択する必要があります。 HA セットアップの待機時間の低下の正確な影響を測定するには、ワークロードのパフォーマンス テストを実行して、情報に基づいた意思決定を行うことをお勧めします。
HA サーバーのメンテナンスはどのように行われますか?
コンピューティングのスケーリングやマイナー バージョンのアップグレードなどの計画イベントは、最初に元のスタンバイ インスタンスで発生し、その後、計画されたフェールオーバー操作をトリガーしてから、元のプライマリ インスタンスで動作します。 HA サーバーの予定メンテナンス期間は、フレキシブル サーバーの場合と同じように設定できます。 ダウンタイムの量は、HA が無効になっている場合の Azure Database for MySQL フレキシブル サーバー インスタンスのダウンタイムと同じです。
HA サーバーのポイントインタイム リストア (PITR) を行うことはできますか?
HA が有効になっている Azure Database for MySQL - フレキシブル サーバー インスタンスから、HA が無効になっている新しい Azure Database for MySQL - フレキシブル サーバー インスタンスに、PITR を実行できます。 ソース サーバーがゾーン冗長 HA で作成された場合は、後で復元されたサーバーでゾーン冗長 HA またはローカル冗長 HA を有効にすることができます。 ソース サーバーがローカル冗長 HA で作成された場合は、復元されたサーバーでローカル冗長 HA のみを有効にすることができます。
サーバーの作成後に、HA を有効にすることはできますか?
ゾーン冗長 HA は、サーバーの作成時に有効にする必要があります。 サーバーの作成後にローカル冗長 HA を有効にできますが、先に進む前に、サーバーパラメーター enforce_gtid_consistency と gtid_mode が ON に設定されていることを確認します。
作成後のサーバーで HA を無効にすることはできますか?
サーバーの HA は、作成後に無効にすることができます。 課金はすぐに停止します。
ダウンタイムを軽減するにはどうすればよいですか?
HA を使用していない場合でも、アプリケーションのダウンタイムを軽減できる必要があります。 計画的なパッチ、マイナー バージョン アップグレード、またはコンピューティングのスケーリングなどのお客様が開始する操作のようなサービス ダウンタイムは、予定メンテナンス期間の間に実行できます。 Azure によって開始されるメンテナンス タスクのアプリケーションへの影響を軽減するために、アプリケーションへの影響を最小限に抑える曜日と時刻にスケジュールを設定できます。
HA が有効になっているサーバーに対して読み取りレプリカを使用できますか?
はい。読み取りレプリカは HA サーバーでサポートされています。
HA サーバーに対しデータイン レプリケーションを使用できますか?
高可用性 (HA) が有効なサーバーのデータイン レプリケーションのサポートは、GTID ベースのレプリケーションでのみ使用できます。
GTID を使用したレプリケーションのストアド プロシージャは、mysql.az_replication_with_gtid という名前ですべての HA 対応サーバーで使用できます。
ダウンタイムを短くするため、サーバーの再起動中、またはスケールアップやスケールダウンの間に、スタンバイ サーバーにフェールオーバーできますか?
現在、Azure Database for MySQL フレキシブル サーバーでは、計画フェールオーバーを利用して、スケールアップ/スケールダウンや計画メンテナンスなどの HA 操作を最適化し、ダウンタイムを削減しています。
このような操作が開始されると、最初に元のスタンバイ インスタンスで動作してから、計画フェールオーバー操作がトリガーされた後に、元のプライマリ インスタンスで処理されます。
サーバーの可用性モード (ゾーン冗長 HA/ローカル冗長) を変更できますか**
ゾーン冗長 HA モードを有効にしてサーバーを作成する場合は、ゾーン冗長 HA からローカル冗長に、またはその逆に変更できます。
可用性モードを変更するには、[高可用性] ウィンドウで [高可用性] を [無効] に設定し、ゾーン冗長またはローカル冗長に戻し、[高可用性モード] を選択します。