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情報表示
クラスタリストページで、実際に使用しているビューモードに応じて表示します:
1. 左側のクラスタリストページでクラスタをクリックすると、クラスタ管理ページに移動します。 2. クラスタ管理ページのデプロイ方式欄およびクラスタ詳細のトポロジ図で、当該クラスタのデプロイ方式ならびに主/予備アベイラビリティーゾーンをそれぞれ確認できます。
1. クラスタリストページでは、クラスタのアベイラビリティーゾーン情報(主アベイラビリティーゾーン)を表示します。 2. クラスタ詳細ページの基本情報および可用性情報で、クラスタのデプロイ分布アベイラビリティーゾーンを確認できます。
TDSQL-C for MySQLがサポートするデータレプリケーション方式
一、非同期レプリケーション
アプリケーションがデータ更新(insert、update、delete操作を含む)リクエストを発行すると、プライマリノードは更新操作の実行後、直ちにアプリケーションへ応答を返し、その後にセカンダリノードへデータをレプリケーションします。データ更新中、プライマリノードはセカンダリノードの応答を待つ必要がないため、非同期レプリケーションのデータベースインスタンスは通常、高い性能を有し、セカンダリノードが利用不可であってもプライマリノードの対外サービス提供には影響しません。ただし、データはリアルタイムにセカンダリノードへ同期されないため、セカンダリノードに遅延がある状態でプライマリノードに障害が発生した場合、小さい確率でデータ不整合が生じる可能性があります。
二、セミ同期レプリケーション
アプリケーションがデータ更新(insert、update、delete操作を含む)リクエストを発行すると、プライマリノードは更新操作の実行後、直ちにセカンダリノードへデータをレプリケーションします。セカンダリノードはデータを受信してrelay logに書き込み(実行は不要)した後、プライマリノードへ成功情報を返します。プライマリノードはセカンダリノードからの成功情報を受信した後、アプリケーションへ応答を返します。
データレプリケーションに異常が発生した場合(セカンダリノードが利用不可、またはデータレプリケーションに使用するネットワークに異常が発生した場合)のみ、プライマリノードはアプリケーションへの応答を一時停止し(デフォルトで約10秒)、レプリケーションモードを非同期レプリケーションにダウングレードします。データレプリケーションが正常に復旧すると、セミ同期レプリケーションに復旧します。
三、ストロング・シンクロナス・レプリケーション
アプリケーションがデータ更新(insert、update、delete操作を含む)リクエストを発行すると、プライマリノードは更新操作の実行後、直ちにセカンダリノードへデータをレプリケーションします。セカンダリノードはデータを受信してrelay logに書き込み(実行完了)した後、プライマリノードへ成功情報を返します。プライマリノードはセカンダリノードからの成功情報を受信した後、アプリケーションへ応答を返します。
データレプリケーションに異常が発生した場合(セカンダリノードが利用不可、またはデータレプリケーションに使用するネットワークに異常が発生した場合)でも、レプリケーションモードはダウングレードされません。データの一貫性を保証するため、このときプライマリノードはアプリケーションへの応答を一時停止し、異常が終了するまで継続します。