TDSQL-C for MySQLクラスタのインスタンス形態はプリセットリソースまたはサーバーレスであり、どちらもマルチAZデプロイをサポートします。シングルAZデプロイと比較して、マルチAZデプロイの方法はより高い災害復旧能力を備え、データベースインスタンスの障害やAZの停止を防ぐためにデータベースを保護し、データセンターレベルの障害に耐えることができます。マルチAZデプロイはデータベースインスタンスに高可用性とフェイルオーバーサポートを提供します。マルチAZは、単一AZのレベルで、同一リージョンの複数の単一AZを組み合わせた物理的な領域です。本稿では、インスタンス形態がプリセットリソースのクラスタのマルチAZデプロイをご紹介します。インスタンス形態がサーバーレスのマルチAZデプロイをご覧になりたい場合は、マルチAZデプロイを参照してください。 説明:
TDSQL-C for MySQLの予備アベイラビリティーゾーンは災害復旧のために使用され、外部へのアクセスを提供しません。
前提条件
クラスタが配置されているリージョンは、2つ以上のアベイラビリティーゾーンを含む必要があります。
対象アベイラビリティーゾーンは十分なコンピューティングリソースを備えています。
データベースのバージョン要件:
データベースバージョン5.7では、カーネルのマイナーバージョンが2.0.15以上である必要があります。
データベースバージョン8.0では、カーネルのマイナーバージョンが3.0.1以上である必要があります。
マルチAZデプロイアーキテクチャ
サポート対象のリージョンとアベイラビリティーゾーン
現在この機能はパブリックベータ期間中であり、当面は以下の表に示すリージョンとアベイラビリティーゾーンのみをサポートしています。
本機能は順次、サポート対象のリージョンとアベイラビリティーゾーンを拡大していきます。
業務上の必要に応じて、チケットを提出の上、他のリージョンおよびアベイラビリティーゾーンへのデプロイを申請できます。 |
北京 | 北京第3ゾーン | 北京第5ゾーン |
| 北京第5ゾーン | 北京第7ゾーン |
| 北京第6ゾーン | 北京第7ゾーン |
|
| 北京第8ゾーン |
| 北京第7ゾーン | 北京第5ゾーン |
広州 | 広州第3ゾーン | 広州第4ゾーン |
| 広州第4ゾーン | 広州第6ゾーン |
| 広州第6ゾーン | 広州第4ゾーン |
|
| 広州第7ゾーン |
| 広州第7ゾーン | 広州第4ゾーン |
上海 | 上海第2ゾーン | 上海第4ゾーン |
| 上海第4ゾーン | 上海第2ゾーン |
| 上海第5ゾーン | 上海第4ゾーン |
中国香港 | 香港第1ゾーン | 香港第3ゾーン |
| 香港第2ゾーン | 香港第3ゾーン |
シンガポール | シンガポール第2ゾーン | シンガポール第4ゾーン |
| シンガポール第3ゾーン | シンガポール第4ゾーン |
| シンガポール第4ゾーン | シンガポール第3ゾーン |
シリコンバレー | シリコンバレー第2ゾーン | シリコンバレー第1ゾーン |
フランクフルト | フランクフルト第1ゾーン | フランクフルト第2ゾーン |
| フランクフルト第2ゾーン | フランクフルト第1ゾーン |
バージニア | バージニア第1ゾーン | バージニア第2ゾーン |
| バージニア第2ゾーン | バージニア第1ゾーン |
東京 | 東京第1ゾーン | 東京第2ゾーン |
| 東京第2ゾーン | 東京第1ゾーン |
ジャカルタ | ジャカルタ第2ゾーン | ジャカルタ第1ゾーン |
マルチAZアーキテクチャの実現方法
マルチAZアーキテクチャについては、コンソールで新しいクラスタを作成することで実現でき、既存のシングルAZクラスタもマルチAZクラスタにアップグレードされます。このアップグレードはデータのオンライン移行によって自動的に完了し、お客様のビジネスに一切影響を与えません。詳細についてはマルチAZデプロイの設定をご参照ください。 マルチAZ料金説明
マルチAZ機能は現時点では追加料金の支払いが不要です。
説明:
現在、シングルAZクラスタも無料でマルチAZクラスタにアップグレードできます。
マルチAZ情報表示
クラスタリストページで、実際に使用しているビューモードに応じて表示します:
1. 左側のクラスタリストページでクラスタをクリックすると、クラスタ管理ページに移動します。 2. クラスタ管理ページのデプロイ方式欄およびクラスタ詳細のトポロジ図で、当該クラスタのデプロイ方式ならびに主/予備アベイラビリティーゾーンをそれぞれ確認できます。
1. クラスタリストページでは、クラスタのアベイラビリティーゾーン情報(主アベイラビリティーゾーン)を表示します。 2. クラスタ詳細ページの基本情報および可用性情報で、クラスタのデプロイ分布アベイラビリティーゾーンを確認できます。
TDSQL-C for MySQLがサポートするデータレプリケーション方式
一、非同期レプリケーション
アプリケーションがデータ更新(insert、update、delete操作を含む)リクエストを送信すると、マスターは更新操作を実行した後、直ちにアプリケーションに応答を返し、その後スレーブにデータを複製します。データ更新プロセスにおいてマスターはスレーブの応答を待つ必要がないため、非同期複製のデータベースインスタンスは通常高いパフォーマンスを有し、スレーブが利用不可でもマスターのサービス提供に影響しません。ただし、データはスレーブにリアルタイムで同期されないため、マスターがスレーブに遅延がある状態で障害が発生すると、わずかな確率でデータ不整合が生じる可能性があります。
二、セミ同期レプリケーション
アプリケーションがデータ更新(insert、update、delete操作を含む)リクエストを送信すると、マスターは更新操作を実行した後、直ちにスレーブにデータを複製します。スレーブはデータを受信してリレーログに書き込み(実行不要)して初めてマスターに成功情報を返します。マスターはスレーブからの成功情報を受信してからでないと、アプリケーションに応答を返すことができません。
データ複製に異常が発生した場合(スレーブノードが利用不可、またはデータ複製に使用するネットワークに異常が発生した場合)に限り、マスターはアプリケーションへの応答を一時停止(デフォルトで約10秒)し、複製方式を非同期複製に変更します。データ複製が正常に戻ると、半同期複製に復元されます。
三、ストロング・シンクロナス・レプリケーション
アプリケーションがデータ更新(insert、update、delete 操作)リクエストを送信すると、マスターは更新操作を実行した後、直ちにスレーブにデータを複製します。スレーブがデータを受信し、リレーログに書き込み(実行完了)して初めてマスターに成功情報を返します。マスターはスレーブからの成功情報を受信してからでないと、アプリケーションに応答を返すことができません。
データ複製に異常が発生した場合(スレーブノードが利用不可、またはデータ複製に使用するネットワークに異常が発生した場合)、複製方式は一切ダウングレードされません。データの一貫性を保証するため、マスターは異常が解消されるまでアプリケーションへの応答を一時停止します。