高可用性

高可用性DBシステムは、3つのMySQLインスタンス(1つのプライマリと2つのセカンダリ)で構成されます。プライマリ・インスタンスに書き込まれるデータはすべて、セカンダリにも書き込まれます。高可用性DBシステムは、1つのインスタンスに障害が発生した場合に別のインスタンスが引き継いで、データ損失ゼロと停止時間の最小化を実現します。

高可用性の概要

MySQL Databaseの高可用性では、MySQLグループ・レプリケーションを使用して、データを保護してビジネス継続性を実現するスタンバイ・レプリカを提供します。MySQL Group ReplicationではPaxosアルゴリズムが実装されます。

高可用性DBシステムは、3つのMySQLインスタンス(1つのプライマリと2つのセカンダリ)で構成されます。プライマリ・インスタンスに書き込まれるデータはすべて、セカンダリにも書き込まれます。

高可用性DBシステムの作成時に、プライマリ・インスタンスを配置する可用性ドメインを選択できます。これは、プライマリ・インスタンスの優先配置です。セカンダリは、他の2つの可用性ドメインまたはフォルト・ドメインに自動的に配置されます。次のインスタンス配置モデルが使用されます:

  • リージョナル・サブネットがある複数の可用性ドメイン: プライマリとセカンダリは、異なる可用性ドメインに配置されます。
    ノート

    どのフォルト・ドメインにセカンダリを配置するかは指定できません。たとえば、DBシステムの作成中にフォルト・ドメイン1を選択した場合、プライマリのみがそのフォルト・ドメインに配置されます。セカンダリは自動的に配置されます。
  • 可用性ドメイン固有のサブネットがある複数の可用性ドメイン: プライマリとセカンダリは、同じ可用性ドメイン内の異なるフォルト・ドメインに配置されます。
  • 単一可用性ドメイン・リージョン: プライマリとセカンダリは、同じ可用性ドメイン内の異なるフォルト・ドメインに配置されます。

フェイルオーバーまたはスイッチオーバーが発生した場合、セカンダリはプライマリ・インスタンスに昇格されます。

  • フェイルオーバー: プライマリで障害が発生すると、セカンダリのいずれかが自動的にプライマリに昇格され、読取り/書込みモードに設定されて、クライアント・アプリケーションに対して再び使用可能になります。データ損失は発生しません。
  • スイッチオーバー: 手動で切り替えて、セカンダリをプライマリに昇格できます。

MySQL Databaseの高可用性インスタンスは、管理対象のセキュアな内部ネットワークを介してレプリケートされます(このネットワークは、DBシステムのエンドポイント接続用に構成したVCNサブネットには接続されていません)。この内部ネットワークに関しては限られた情報が一部のパフォーマンス・スキーマ表に含まれていますが、そのネットワークに接続することも、関連する他の情報を表示することもできません。

高可用性DBシステムでは、スタンドアロンDBシステムよりも多くのリソース(OCPU、RAM、ネットワーク帯域幅)を消費します。したがって、スループットとレイテンシはスタンドアロンDBシステムとは異なります。

前提条件

高可用性ではMySQLグループ・レプリケーションが使用され、各表に主キーが定義されていることが必要です。高可用性DBシステムに主キーのない表を作成しようとすると、失敗します。

データをMySQLデータベースに移行する際、主キーを表に定義していなかった場合は、追加する必要があります。表に主キーがあるか確認し、それがない表にはキーを追加します:

  1. コマンド行クライアントを使用した主キーの検査
  2. 次のいずれかの方法を使用して主キーを追加します:
    • 非表示列の使用: コマンドライン・クライアントを使用した主キーの手動追加を参照してください。
      ノート

      非表示列を使用した主キーの追加は、高可用性DBシステムに対応できるように既存データを更新するための影響の少ない方法です。これはアプリケーションに対して透過的であり、新しい列はSELECT問合せから隠された状態であるため、アプリケーションは以前と同様に動作し続けることができます。
    • MySQLシェルのダンプ・ユーティリティの使用: MySQLシェルのダンプ・ユーティリティcreate_invisible_pksを参照してください。
    • MySQLシェルのロード・ユーティリティの使用: MySQLシェルのロード・ユーティリティcreateInvisiblePKsを参照してください。
      ノート

      MySQLシェル・ダンプおよびロード・ユーティリティを使用するには、MySQLシェル・バージョン8.0.30以上を使用します。

コマンド行クライアントを使用した主キーの検査

MySQLクライアントやMySQLシェルなどのコマンドライン・クライアントを使用して、表の主キーを確認し、主キーのないキーをリストします。主キーは、高可用性で使用されるグループ・レプリケーションの前提条件です。

  1. データベースに対して次の文を実行して、主キーがない表のリストを生成します。
    SELECT t.table_schema, t.table_name
    FROM information_schema.tables t
      LEFT JOIN (SELECT table_schema, table_name 
                 FROM information_schema.statistics
                 WHERE index_name = 'PRIMARY' 
                 GROUP BY table_schema, table_name, index_name
                 ) pks 
      ON t.table_schema = pks.table_schema AND t.table_name = pks.table_name 
    WHERE pks.table_name IS NULL
      AND t.table_type = 'BASE TABLE' 
      AND t.table_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema');

コマンド行クライアントを使用した主キーの手動追加

MySQLクライアントやMySQLシェルなどのコマンドライン・クライアントを使用して、主キーを非表示列に追加します。

このタスクでは次が必要です:
  • MySQLバージョン8.0.23以上。非表示列は8.0.23バージョンで導入されました。
非表示列に主キーを追加するには、次を実行します:
  1. 非表示列および主キーを追加する表に対して、次のようなコマンドを実行します:
    ALTER TABLE <Table1> ADD <my_row_id> BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY INVISIBLE FIRST;

    このコマンドは、1つの列testを含む表<Table1>に列<my_row_id>を追加して変更します。この列は非表示で、表の主キーを含みます。

関連トピック

コンソールを使用した高可用性の有効化および無効化

コンソールを使用して、DBシステムで高可用性を有効または無効にします。

フェイルオーバー

プライマリ・インスタンスに障害が発生した場合、別の可用性ドメインまたはフォルト・ドメインに存在するセカンダリ・インスタンスが自動的にプライマリに昇格されます。

フェイルオーバーが完了すると、必ずエンドポイント(読取り、書込み)は新たに昇格されたプライマリを指します。フェイルオーバー後にアプリケーションまたはツールで使用されるIPアドレスを更新または変更する必要はありません。

表7-1 フェイルオーバーの理由

フェイルオーバー 説明
ハードウェア 次のいずれかで障害が発生すると、新しいプライマリが選択されます:
  • ストレージ障害
  • ネットワーク障害
  • 可用性ドメインまたはフォルト・ドメインの障害
  • ホスト障害
MySQL Server 次のような障害が発生すると、新しいプライマリが選択されます:
  • MySQLプロセスの停止
  • オペレーティング・システムの停止
  • MySQLインスタンスまたはプロセスが遅いか過負荷
  • レプリケーション・エラー
高可用性DBシステムを最初に作成したときにプライマリとして選択するインスタンスが、DBシステムの優先プライマリ・インスタンスです。エラーが発生し、プライマリがグループから離れて、他のセカンダリの1つがプライマリに昇格した場合、最初にプライマリとして選択したインスタンスが常に優先プライマリになります。エラーが修正され、元のプライマリがセカンダリの1つとしてグループに戻った後で、別のフェイルオーバーが発生した場合、最初にプライマリとして定義したインスタンスが昇格で優先されます。
ノート

スイッチオーバーを実行する場合、選択したインスタンスが優先プライマリ・インスタンスになります。

フェイルオーバーが発生し、プライマリ・インスタンスが優先可用性ドメインまたはフォルト・ドメインにない場合、DB Systemの詳細ページに「フェイルオーバーまたはメンテナンス・アクティビティのため、現在の配置先(domainName)は優先配置先とは異なります」というメッセージが表示されます。ここで、domainNameは、現在のプライマリ・インスタンスのフォルト・ドメインまたは可用性ドメインの名前です。

ノート

インバウンド・レプリケーション・チャネルを持つDBシステムでフェイルオーバーが発生した場合、フェイルオーバーが完了するまでチャネルは一時停止されます。フェイルオーバーが完了し、新しいプライマリが昇格されると、チャネルは自動的に再開されます。

スイッチオーバー

スイッチオーバーでは、現在のプライマリ・インスタンスをセカンダリ・インスタンスの1つに手動で切り替えます。

スイッチオーバーでは、現在のプライマリ・インスタンスをセカンダリに降格し、選択したセカンダリをプライマリに昇格します。また、優先配置が現在の配置に変わります。つまり、プライマリ・インスタンスの現在の配置が優先配置と同じになります。この操作ではエンドポイントは変更されません。DBシステム・エンドポイントのIPアドレスを変更する必要はありません。エンドポイントは、内部的には、新しく昇格されたプライマリにリダイレクトされます。

スイッチオーバーでは、DBシステムのエンドポイントが新しく昇格されたインスタンスにリダイレクトされるまで、短い停止時間が発生します。データベース接続を再オープンする必要があります。

スイッチオーバー・プロセスは次のとおりです:

  • 実行中のトランザクションは完了できます。スイッチオーバー・プロセスは、実行中のすべてのトランザクションが終了してコミットされるまで待機します。
  • 新しいトランザクションが受け入れられ、読取りと書込みを実行できます。ただし、セカンダリが新しいプライマリとして昇格されて、前のプライマリとの接続が切断されると、コミットされていないトランザクションはすべてロールバックされます。
  • DBシステムのエンドポイントは、新しく昇格されたプライマリに割り当てられます。
  • 前のプライマリに対する既存の接続は閉じられます。クライアント・アプリケーションは接続を再オープンする必要があります。

次のシナリオでスイッチオーバーを使用できます:

  • アプリケーション・テスト: 新しく昇格したプライマリでアプリケーションが正常に動作することを確認します。
  • 可用性ドメインの近接性: フォルト・ドメインが同じデータ・センター内に存在しますが、可用性ドメインは異なるデータ・センターに分散されます。これらの可用性ドメインは低レイテンシ・ネットワークで接続されていますが、場合によっては、プライマリを可用性ドメイン間で移動することでレイテンシをテストして、プライマリの最適な場所を確認する必要があります。たとえば、接続するアプリケーションと同じ可用性ドメイン内のインスタンスへの切替えです。

コンソールを使用したプライマリ・インスタンスの切替え

コンソールを使用して、セカンダリ・インスタンスの1つをプライマリに昇格します。

このタスクでは次が必要です:
  • 高可用性が有効になっている、実行中のDBシステム。
現在のプライマリ・インスタンスからセカンダリ・インスタンスの1つに切り替えるには、次を実行します:
  1. ナビゲーション・メニューを開きます。「MySQL」で、「DBシステム」をクリックします。
  2. 「リスト範囲」からコンパートメントを選択します。
  3. DBシステムのリストで、切り替えるDBシステムを見つけて、次のいずれかを実行します:
    • DBシステムと同じ行にある「アクション」メニューから、「スイッチオーバー」を選択します。
    • DBシステムの名前をクリックして、DB Systemの詳細ページを開きます。「その他のアクション」メニューから「スイッチオーバー」を選択します。
  4. 「スイッチオーバー」ダイアログ・ボックスで、設定に応じて、切替え先のインスタンスが含まれる可用性ドメインまたはフォルト・ドメインを選択します。
  5. 「スイッチオーバー」をクリックします。
DBシステムのステータスが「更新中」に変わり、選択したインスタンスがプライマリになります。

制限事項

高可用性DBシステムには一定の制限があります。

  • 高可用性DBシステムはローリング・アップグレードを実行し、新たに昇格されたプライマリが接続を再開する前に短い停止時間が発生します。各MySQLインスタンスは個別にアップグレードされます。高可用性DB Systemのメンテナンスを参照してください。
  • 高可用性を備えたDB SystemでHeatWaveクラスタを有効にすることはできません。
  • スタンドアロンDBシステムから高可用性を備えたDBシステムにバックアップをリストアすることはできません。
  • MySQLのバージョン8.0.24以上では、高可用性がサポートされています。以前のバージョンのDBシステムからのバックアップを使用して高可用性DBシステムを作成することはできません。
  • MySQLシェルまたは他の同様のクライアントを使用してセカンダリ・インスタンスに直接アクセスすることはできません。
  • 高可用性を備えたDBシステムの構成を編集することはできません。ただし、バックアップを作成し、選択した構成のDBシステムにそのバックアップをリストアすることはできます。コンソールを使用した手動バックアップの作成およびコンソールを使用したバックアップから新しいDB Systemへのリストアを参照してください。
  • トランザクションの最大サイズはシェイプに依存します。シェイプおよび関連付けられたトランザクション・サイズ制限(バイト)は次のとおりです:
    • MySQL.VM.Standard.E3.1.8GB: 85899346
    • MySQL.VM.Standard.E3.1.16GB: 171798692
    • MySQL.VM.Standard.E3.2.32GB: 343597384
    • MySQL.VM.Standard.E3.4.64GB: 687194767
    • MySQL.VM.Standard.E3.8.128GB: 1073741824
    • MySQL.VM.Standard.E3.16.256GB: 1073741824
    • MySQL.VM.Standard.E3.24.384GB: 1073741824
    • MySQL.VM.Standard.E3.32.512GB: 1073741824
    • MySQL.VM.Standard.E3.48.768GB: 1073741824
    • MySQL.VM.Standard.E3.64.1024GB: 1073741824

請求

高可用性DBシステムには3つのMySQLインスタンスが含まれており、選択したシェイプの定義に応じて、それぞれが同じブロック・ボリューム・ストレージ容量、OCPU数およびRAM容量を使用します。

3つのMySQLインスタンスに対して請求されます。グループ・レプリケーションで使用される内部ネットワーキングに対する追加料金はありません。