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 サービスでは、99.99% のアップタイムという財務的な裏付けのあるサービス レベル アグリーメント (SLA) で、高レベルの可用性が保証されています。 Azure Database for MySQL では、ユーザーが開始したコンピューティングのスケーリング操作などの計画的なイベント中や、基になるハードウェア、ソフトウェア、ネットワークの障害などの計画外のイベントが発生したときに高可用性が提供されます。 Azure Database for MySQL は、ほとんどの重大な状況から迅速に復旧でき、このサービスを使用するとアプリケーションのダウンタイムが事実上なくなります。

Azure Database for MySQL は、高いアップタイムを必要とするミッション クリティカルなデータベースの実行に適しています。 このサービスは、Azure アーキテクチャに基づいて構築されているので、計画的な停止や計画外の停止によるデータベースのダウンタイムを軽減するための高可用性、冗長性、回復性の各機能が最初から備わっており、追加のコンポーネントを構成する必要がありません。

Azure Database for MySQL のコンポーネント

コンポーネント 説明
MySQL データベース サーバー Azure Database for MySQL には、データベース サーバーに対して、セキュリティ、分離、リソース保護、および迅速な再起動機能が用意されています。 これらの機能により、スケーリングなどの操作が容易になり、データベースのトランザクション アクティビティに応じて、障害の発生後 60 ～ 120 秒でデータベース サーバーの復旧操作を行えます。
データベース サーバーでのデータ変更は、通常、データベース トランザクションのコンテキストで行われます。 データベースのすべての変更は、データベース サーバーに接続されている Azure Storage に、先書きログ (ib_log) の形式で同期的に記録されます。 データベース チェックポイント 処理中に、データベース サーバー メモリのデータ ページもストレージにフラッシュされます。
リモート ストレージ すべての MySQL 物理データ ファイルとログ ファイルはて、データの冗長性、可用性、信頼性を確保するためにリージョン内にデータの 3 つのコピーを格納するように設計されている Azure Storage に格納されます。 また、このストレージ レイヤーはデータベース サーバーから独立しています。 60 秒以内に、障害が発生したデータベース サーバーからデタッチして、新しいデータベース サーバーに再アタッチすることができます。 また、Azure Storage は、ストレージの障害を継続的に監視します。 ブロックの破損が検出されると、新しいストレージ コピーをインスタンス化することによって自動的に修正されます。
ゲートウェイ ゲートウェイはデータベース プロキシとして機能し、すべてのクライアント接続をデータベース サーバーにルーティングします。

計画的なダウンタイムの軽減

Azure Database for MySQL は、計画的なダウンタイム操作中に高可用性をもたらすように設計されています。

view of Elastic Scaling in Azure MySQL

次に、計画的なメンテナンス シナリオをいくつか示します。

シナリオ 説明
コンピューティングのスケールアップ/スケールダウン ユーザーがコンピューティングのスケールアップ/ダウン操作を実行すると、スケーリングされたコンピューティング構成を使用して新しいデータベース サーバーがプロビジョニングされます。 古いデータベース サーバーでは、アクティブなチェックポイントを完了でき、クライアント接続がドレインされ、コミットされていないトランザクションが取り消され、サーバー自体がシャットダウンされます。 続いてストレージが古いデータベース サーバーからデタッチされ、新しいデータベース サーバーに接続されます。 クライアント アプリケーションが接続を再試行するか、または新しい接続を確立しようとすると、ゲートウェイはその接続要求を新しいデータベース サーバーに転送します。
ストレージのスケール アップ ストレージのスケール アップはオンライン操作であるため、データベース サーバーは中断されません。
新しいソフトウェアのデプロイ (Azure) 新機能のロールアウトやバグ修正プログラムは、サービスの計画的なメンテナンスの一環として自動的に行われます。 詳細については、ドキュメントを参照し、自身のポータルを確認してください。
マイナー バージョンのアップグレード Azure Database for MySQL では、Azure によって決定されたマイナー バージョンへの修正プログラムが自動的にデータベース サーバーに適用されます。 これは、サービスの計画的なメンテナンスの一環として行われます。 計画メンテナンス中にデータベース サーバーの再起動またはフェールオーバーが発生する可能性があり、これにより、エンドユーザーがデータベース サーバーを短時間利用できなくなる場合があります。 Azure Database for MySQL サーバーはコンテナー内で実行されているため、データベース サーバーの再起動は、通常は迅速に行われ、60 秒から 120 秒で完了することが想定されています。 各サーバーの再起動を含む計画メンテナンス イベント全体が、エンジニアリング チームによって注意深く監視されます。 サーバーのフェールオーバー時間はデータベースの復旧時間に依存します。このため、フェールオーバー時にサーバーで処理されているトランザクションの量が多い場合は、データベースがオンラインになるまで時間がかかる可能性があります。 再起動時間が長くなるのを避けるために、計画メンテナンス イベント中は実行時間の長いトランザクション (一括読み込み) を行わないようにすることをお勧めします。 詳細については、ドキュメントを参照し、自身のポータルを確認してください。

計画外のダウンタイムの軽減

計画外のダウンタイムは、基になるハードウェアの障害、ネットワークの問題、ソフトウェアのバグなど、予期しない障害の結果として発生する可能性があります。 データベース サーバーが予期せず停止した場合は、新しいデータベース サーバーが 60 ～ 120 秒で自動的にプロビジョニングされます。 リモート ストレージは、新しいデータベース サーバーに自動的に接続されます。 MySQL エンジンによって、WAL およびデータベース ファイルを使用して復旧操作が実行され、データベース サーバーが開かれてクライアントからの接続が可能になります。 コミットされていないトランザクションは失われ、アプリケーションが再試行する必要があります。 計画外のダウンタイムは回避できませんが、Azure Database for MySQL では、データベース サーバーとストレージ レイヤーの両方で、ユーザーの介入を必要とすることなく自動的に復旧操作を実行することでダウンタイムが軽減されます。

view of High Availability in Azure MySQL

計画外のダウンタイム: 障害シナリオとサービス復旧

いくつかの障害シナリオと、Azure Database for MySQL が自動的に復旧されるしくみを次に示します。

シナリオ 自動復旧
データベース サーバーの障害 基になるハードウェアの障害が原因でデータベース サーバーが停止した場合、アクティブな接続は切断され、処理中のすべてのトランザクションは中止されます。 新しいデータベース サーバーが自動的にデプロイされ、リモート データ ストレージが新しいデータベース サーバーに接続されます。 データベースの復旧が完了すると、クライアントはゲートウェイ経由で新しいデータベース サーバーに接続できるようになります。

MySQL データベースを使用するアプリケーションによって、切断された接続や失敗したトランザクションが検出され、再試行するように構築されている必要があります。 アプリケーションが再試行すると、ゲートウェイは、新しく作成されたデータベース サーバーへの接続を透過的にリダイレクトします。
ストレージの障害 アプリケーションは、ディスク障害や物理ブロックの破損など、ストレージ関連の問題の影響を一切認識しません。 データが 3 つのコピーに格納されるので、データのコピーは存続しているストレージから提供されます。 ブロックの破損は自動的に修正されます。 データのコピーが失われると、データの新しいコピーが自動的に作成されます。

次に、復旧にユーザーの操作が必要な障害シナリオをいくつか示します。

シナリオ 復旧計画
リージョンの障害 リージョンの障害は、まれにしか発生しないイベントです。 ただし、リージョンの障害から保護する必要がある場合は、ディザスター リカバリー (DR) 用に他のリージョンで 1 つ以上の読み取りレプリカを構成できます。 (詳細については、読み取りレプリカの作成と管理に関するこの記事をご覧ください)。 リージョン レベルの障害が発生した場合は、運用データベースサーバーとして他のリージョンで構成されている読み取りレプリカを手動で昇格できます。
論理/ユーザー エラー 誤って破棄されたテーブルや間違って更新されたデータなどのユーザーエラーからの復旧には、エラーが発生する直前の時間までデータを復元および復旧することによる、特定の時点への復旧 (PITR) の実行が含まれます。

データベース サーバー内のすべてのデータベースではなく、データベースまたは特定のテーブルのサブセットのみを復元する場合は、新しいインスタンスでデータベース サーバーを復元し、mysqldump を使用してテーブルをエクスポートし、restore を使用してそれらのテーブルをデータベースに復元することができます。

まとめ

Azure Database for MySQL には、データベース サーバー高速再起動機能、冗長ストレージ、ゲートウェイからの効率的なルーティングが用意されています。 データの保護を強化するために、geo レプリケートするようにバックアップを構成したり、他のリージョンに 1 つ以上の読み取りレプリカをデプロイしたりすることもできます。 Azure Database for MySQL には、高可用性機能が内在されているため、最も一般的な障害からデータベースが保護され、財務に裏付けられた業界最高レベルの 99.99% のアップタイム SLA が保証されます。 このような可用性と信頼性の機能すべてによって、Azure はミッションクリティカルなアプリケーションを実行するための理想的なプラットフォームになることができています。

次のステップ