Skip to Content

MySQL の高可用性(HA) とは

※このページの内容が日本語である場合は、機械翻訳システムで翻訳したものです。

MySQL の高可用性(HA) は、障害や障害が発生した場合に MySQL データベースを利用可能にするために選択できます。この機能により、より高い稼働時間要件とゼロデータ損失許容誤差を設定できます。この記事では、高可用性の一般的な概念と、MySQL の高可用性オプションの仕組みについて説明します。 

高可用性とは

高可用性とは、システムやサービスが機能を継続し、障害や停止が発生した場合でも利用可能な状態を維持する能力のことです。高可用性システムは、組織のミッションクリティカルなシステムとアプリケーションを常に稼働させます。これは、医療、金融、航空などの分野でミッションクリティカルなシステムの障害が深刻な結果をもたらす可能性がある組織にとって特に重要です。

高可用性は通常、SLA(サービス・レベル・アグリーメント)で定義された稼働時間の割合で表され、100 のスコアは、障害のないシステムを表します。これは事実上達成不可能であるため、ほとんどの組織は「5ナイン」または99.999% の可用性を目標としています。

MySQL による高可用性の実現

障害が発生した場合は、可用性の高いシステムが即座にリカバリできる必要があります。高可用性アーキテクチャには、リカバリ性と高可用性を確保するために連携する少なくとも 3 つの基本要素が必要です。

障害検出

MySQL には高可用性オプションがあり、アプリケーションがより高い稼働時間(データ損失許容度なし)の要件を満たすことができます。高可用性オプションがオンの場合、MySQL システムは異なる障害ドメインまたは可用性ゾーンに 3 つのインスタンスを作成します。

データは、MySQL グループ・レプリケーションを使用して 3 つのインスタンス間でレプリケーションされ、アプリケーションはプライマリ・インスタンスに接続して、データベースとの間でデータの送受信を行います。障害が発生すると、数分でセカンダリ・インスタンスへの自動フェイルオーバーが起動します。

フェイルオーバー

フェイルオーバー・メカニズムは、サービスをレプリケートされたインスタンスに転送します。複数のバックアップインスタンスが使用可能な場合、フェイルオーバー・メカニズムはプライマリ・ノードにプロモートする最適なインスタンスを選択します。 

リダイレクト・メカニズム

セカンダリ・インスタンスへのフェイルオーバーが発生すると、高可用性機能により、全てのアプリケーションとユーザの接続が新しいプライマリ・ノードにリダイレクトされます。また、全てのクエリを古いプライマリ・ノードから新しいプライマリ・データベースにリダイレクトします。 

MySQL の高可用性(HA):稼働時間

稼働時間とは、システムが使用可能で正常に機能する時間であり、システムが稼働すると予想される合計時間の割合として表されます。稼働時間が高いということは、ほとんどの場合、システムが使用可能で期待どおりに機能することを意味します。 

MySQL の高可用性(HA)のさまざまなレベルで期待できる稼働時間は、実装する特定の高可用性(HA)ソリューションによって異なります。

MySQL レプリケーション

MySQL レプリケーションでは、冗長性とフェイルオーバーを提供する複数のサーバーをセットアップし、HA 機能のない MySQL サーバーよりも高い稼働時間をサポートできます。マスター・スレーブ構成では、1 つのマスター・サーバーが読み取りと書き込みを受け付け、1 つ以上の読み取り専用スレーブ・サーバーを使用します。マスター・サーバーからのデータは、スレーブ・サーバーに非同期でレプリケートされます。

フェイルオーバーを実装するには、1 つまたは複数のスレーブ・サーバーをスタンバイとして設定し、障害発生時にマスタに昇格させる必要があります。フェイルオーバーは通常、スレーブ・ノードをマスタノードに昇格させる手動プロセスです。昇格されたスレーブのステータスを読み取り/書き込みモードに変更して、クエリを受け入れる必要があります。

フェイルオーバーは手動で行われるため、時間がかかり、人為的ミスが発生しやすくなり、停止時間が長くなる可能性があります。MySQL レプリケーションは非同期レプリケーションも使用します。つまり、マスターに障害が発生した場合、マスターにコミットされたトランザクションがスレーブ・サーバーにレプリケーションされていない可能性があります。重要なデータ損失が発生した場合は、データをリストアし、システムの停止時間を増やす必要があります。

MySQL グループのレプリケーション

MySQL グループ・レプリケーションは、MySQL レプリケーションよりも高い稼働時間を実現します。MySQL グループ・レプリケーションを使用して、1 つのサーバーをプライマリ・サーバーとして、他のサーバーをセカンダリ・サーバーとして指定したグループ内に複数の MySQL サーバーを設定します。グループ内の各サーバーはデータのコピーを保持し、レプリケーションを使用して、コピーが同期されたままであることを確認します。 

プライマリ・サーバーがダウンした場合、グループ内のセカンダリ・サーバーは自動的に障害を検出し、フェイルオーバー・プロセスを開始します。セカンダリ・サーバーの 1 つが自動的に新しいプライマリ・サーバーにプロモートされ、クライアントからのリクエストの処理が開始されます。グループ内の他のセカンダリ・メンバーは、新しいプライマリ・サーバーから更新を受信し、クライアント読み取り要求の処理を続行します。

障害が発生したサーバーがオンラインに戻ると、セカンダリ・サーバーとしてグループに自動的に再結合されます。

MySQL グループ・レプリケーションでは障害の検出とフェイルオーバーが自動的に行われるため、ダウンタイムは最小限に抑えられ、ユーザーやアプリケーションは通常、障害が発生したことに気づきません。 

MySQL クラスタ

MySQL クラスタ HA ソリューションは、最高レベルの稼働時間を提供します。この高可用性の分散データベースシステムは、自動フェイルオーバーと負荷分散とともに、高可用性、性能、スケーラビリティを提供し、ダウンタイムをほぼゼロにするよう設計されています。 

MySQL クラスタは、データの保存と管理のために連携する 3 種類のノードを使用します。

  • データノード:データを保存し、読み取り/書き込みクエリを処理します。
  • MySQL サーバー・ノード:クライアント・アプリケーションからクエリを受信し、データ・ノードで処理してから、結果をクライアントに返します。
  • 管理ノード:クラスタの動作を管理し、障害が発生した場合はフェイルオーバーとリカバリを処理します。

クラスタ内の 1 つ以上のノードに障害が発生した場合、クラスタは自動的に問題を検出し、フェイルオーバー・プロセスをトリガーします。プロセス全体は通常、障害発生後 1 秒以内に発生し、クライアント・アプリケーションへのサービスを中断することはありません。クラスタは、ダウンタイムなしで通常どおり動作し続けます。

FlashArray をテストドライブ

ピュア・ストレージはブロック/ファイル・ストレージをシンプルにします。ハンズオンでお試しいただけます。

テストドライブのご用命

MySQL の高可用性(HA):リカバリ時間 

リカバリ時間とは、MySQL システムが停止からリカバリするまでにかかる時間です。リカバリ時間が長くなると、可用性が低下し、収益、従業員の生産性、顧客満足度の向上に直接影響します。

MySQL では、リカバリ時間は使用するレプリケーションのタイプによって異なります。

  • マスター・スレーブ・レプリケーションの MySQL レプリケーション・リカバリ時間は、手動フェイルオーバー・プロセスの影響を受けます。スレーブ・サーバーを新しいプライマリ・ノードに昇格させた後、残りのスレーブ・サーバーへのデータのレプリケーションを開始できるように、スレーブ・サーバーを再起動する必要があります。その後、トランザクションの欠落を考慮し、発生する可能性のある競合を解決する必要があります。
  • グループレプリケーションは、自動障害検出とフェイルオーバープロセスを使用しており、マスター・スレーブ・レプリケーションよりもリカバリ時間が短縮されます。競合の検出と解決のメカニズムにより、各サーバー上のデータがグループ内の全てのサーバー間で常に同期されます。また、グループ・レプリケーションでは、競合のないレプリケート・データタイプ(CRDT)を使用して、競合が発生した場合にデータを自動的に調整します。グループ・レプリケーションでは、ダウンタイムをほとんど必要とせず、障害からシステムを復旧できます。
  • MySQL クラスタは、「共有なし」のアプローチを使用します。クラスタ内の各ノードには独自のメモリとディスク・ストレージが割り当てられ、高速接続を使用して他のノードと通信します。MySQL クラスタは、1 つ以上のノードに障害が発生しても動作し続けます。クラスタは問題を自動的に検出し、フェイルオーバー・プロセスをトリガーし、ダウンタイムなしでリカバリします。

MySQL HA 要件の決定方法

MySQL の高可用性(HA)要件を決定するには、次のような要素を考慮する必要があります。

  • 現在のシステム・アーキテクチャ:現在のシステムにはどのようなコンポーネントが含まれており、どのように構成されていますか? MySQL の高可用性(HA)をサポートできますか?
  • 予算:ハードウェア、ソフトウェア、人員などのリソースにいくら投資する必要がありますか? また、トレーニングや継続的な保守に関連するコストも考慮してください。
  • ビジネス・ニーズ:目標復旧時間(RTO)と目標復旧ポイント(RPO)を考慮してください。理想的なリカバリ時間を教えてください。障害からどのくらい迅速に復旧する必要がありますか? 高可用性を必要とする特定の規制またはコンプライアンス要件の対象かどうかを検討してください。
  • データの重要性:ビジネス・データはどの程度重要ですか。最新の状態にしておくことはどの程度重要ですか? どのくらいのデータ損失を許容できますか?

MySQL の高可用性(HA) を使用するタイミング

MySQL の高可用性(HA)ソリューションが必要なユースケースを以下にいくつかご紹介します。

トラフィックの多い Webサイト

トラフィックの多い Webサイトは、数千人の同時ユーザーはもちろん、毎秒数千のクエリやトランザクションを処理します。サーバーの冗長性や負荷分散などの高可用性対策により、データベースが常に利用可能で、負荷を処理できます。 

冗長サーバーは、サーバーに障害が発生してもWebサイトを利用可能にし、複数のサーバー間で受信要求をロードバランシングすることで、単一のサーバーがオーバーロードしたりオフラインになったりすることを防ぎます。

ミッションクリティカルなアプリケーションとワークロード

ミッション・クリティカルなシステムやアプリケーションを持つ企業は、高いレベルの可用性と稼働時間を必要とします。多くの場合、これらのシステムはダウンタイムを経験する余裕がなく、データベースは常に利用可能である必要があります。 

グループ・レプリケーションやクラスタなどの MySQL HA ソリューションは、ダウンタイムをほとんどまたはまったく引き起こさない自動フェイルオーバー・メカニズムを採用しているため、このユースケースに最適です。

ピュア・ストレージによる MySQL の高可用性(HA)のサポート

ピュア・ストレージの Evergreenは、ダウンタイムのない展開を実現するサブスクリプション・ポートフォリオです。Evergreen は、ピュア・ストレージ独自のストレージ・アレイ・アーキテクチャとの組み合わせにより、サービス・ワークロードを中断することなくストレージ・インフラのアップグレードを可能にします。 

ピュア・ストレージは、 アクティブ/アクティブ・クラスタリング と、マルチサイトのアクティブ/アクティブ・ストレッチ・クラスタである Purity ActiveClusterによる自動透過的なフェイルオーバーもサポートしており、RPO と RTO をゼロに抑えます。

また、ミッションクリティカルなアプリケーションにエンタープライズレベルのクラウド信頼性を提供する Pure Cloud Block Storeもお勧めです。無停止アップグレードと可用性ゾーン間の高可用性により、マルチクラウドの事業継続性とディザスタ・リカバリのための高可用性を実現します。

こちらの資料もご覧ください!

08/2025
Pure Storage Cloud Azure Native for Azure VMware Solution
Discover how Pure Storage Cloud for Azure VMware Solution simplifies cloud migration, streamlines daily operations, and reduces the total cost of ownership for virtualized workloads. Read the full ESG Technical Validation to learn more.
アナリスト・レポート
12 pages

関連リソースとイベント

Pure//Accelerate 2025
Pure//Accelerate の内容をオンデマンドで視聴できます。

イノベーションに触れ、インスピレーションを得て、データによる価値創出に向けたスキルアップにお役立てください!

コンテンツをチェック
Pure//Accelerate ロードショー
世界の主要都市で開催されます。是非ご参加ください!

最先端のデータ・ストレージ・プラットフォームと、エンタープライズ・データ・クラウドがもたらす効果/メリットを実感していただけます。

詳細と参加のお申し込み
動画
動画:エンタープライズ・データ・クラウドのメリット

会長兼 CEO のチャーリー・ジャンカルロが、ストレージ管理からデータ管理へのシフトこそが未来である理由を解説します。統合により、エンタープライズ IT の運用管理がいかに変わるかがわかります。

視聴する
リソース
従来のストレージは未来を支えません。

近代的なワークロードには、AI 対応の高速性、セキュリティ、拡張性が求められます。スタックの準備はできていますか?

現行のサイバー対策を評価する
このブラウザは現在サポートされていません。

古いブラウザには、セキュリティ・リスクが存在する場合があります。ピュア・ストレージの Web サイトをより快適にご利用いただけるよう、最新のブラウザにアップデートしてください。