Databases for MySQL の高可用性と災害復旧について
高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計が処理できる能力を超えています。、サービスインスタンスを稼動状態に回復させるプロセスである。
Databases for MySQL は、標準プランで定義された サービスレベル目標（SLO ）を満たす地域サービスである。 詳しくは、 サービス・レベル・アグリーメント（SLA ）をご覧ください。 Databases for MySQL で利用可能な IBM Cloud リージョンとデータセンターの詳細については、 ロケーション別のサービスおよびインフラの可用性を 参照してください。
高可用性アーキテクチャ
Databases for MySQL レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。 デプロイメントには、リーダー1台とレプリカ2台からなるクラスターが含まれています。 レプリカは非同期レプリケーションによって最新の状態に保たれます。 フェイルオーバーを処理するために、すべてのメンバーには Orchestrator を使用したデータのコピーが含まれています。 リーダーとレプリカは、マルチゾーン領域において常に異なるゾーンに配置される。 リーダーが到達不能になったり重大な問題に遭遇した場合、サービスはまず既存のリーダーの自動回復を試みます。 リーダーを復旧できない場合、フェイルオーバーが実行され、レプリカがリーダーに昇格します。新しいレプリカがクラスターにレプリカとして再参加し、クラスターは正常に動作を継続します。 レプリカが失敗すると、新しいレプリカが作成される。 ゾーン障害でメンバーが失敗した場合、新しいレプリカは生き残ったゾーンに 作成される。
クロスリージョナル・フェイルオーバーやリード・オフロードのために リード専用レプリカを プロビジョニングすることで、高可用性をさらに拡張することができます。
MySQLのレプリケーション技術に関するドキュメントを確認し、非同期レプリケーションに関連する制約とトレードオフを理解してください。
バージョン 8.0 は準同期レプリケーションを利用し、バージョン 8.4 は非同期テクノロジーを導入しているが、中核となる高可用性とディザスタリカバリの動作は基本的に変わっていない。
プログラムでクラスタにアクセスするワークロードは、可用性を維持するためにクライアントの可用性再試行ロジックに従う必要があります。
Databases for MySQL 通常運転中に制御された切り替えを行うこともある。 こうした切り替えは、通常、データが失われることなく行われ、アクティブな接続がリセットされます。 最大 15 秒の、再接続が失敗する期間があります。 運用環境における予期せぬ事態により、計画外のフェイルオーバーが発生することがあります。 インスタンスが正常なノードをリーダーに割り当てるのに時間がかかる場合があるため、この処理には最大2分ほどかかることがあります。 例えば、サービスのメンテナンスは、制御されたフェイルオーバーの引き金となる。
高可用性機能
Databases for MySQL は以下の高可用性機能をサポートしている：
| 特長 | 説明 | 考慮事項 |
|---|---|---|
| フェイルオーバー動作 | すべてのクラスタに標準装備され、ゾーンや単一メンバーの障害に強い。 リーダーノードが正常でなくなったり、接続不能になった場合、サービスは自動的に回復を試みます。 リーダーを回復できない場合、フェイルオーバーが実行され、レプリカが昇格されて書き込み可用性が復元される。 | リーダーとレプリカ間のレプリカ遅延を最小限に抑えるには、リトライロジック、接続管理、主キーの実装などの ベストプラクティス に従ってください。 |
| メンバー数 | 3人のメンバーで展開する。 3ノードのクラスターは、インスタンスまたはゾーンの単一障害から回復可能ですが、回復プロセス中にデータの遅延が発生する可能性があります。 障害が発生した場合、レプリカはリーダーに昇格し、クラスタは通常通り動作します。 | |
| 読み取り専用レプリカ | 読み取り専用のレプリカは、リモート・リージョンでのローカル・アクセスを提供し、潜在的なネットワーク遅延や接続性の問題に対する可用性を向上させることができる。 | すべてのWriteリクエストは、リード・レプリカに関連付けられたリード・ライト・クラスタのみに向けられなければならない。 |
災害復旧アーキテクチャ
災害復旧の一般的な戦略は、 Restore データベースなどの新しいデータベースを作成することです。 新しいデータベースの内容は、災害前に作成されたソース・データベースのバックアップでもよい。 本番データベースが利用可能であれば、ポイント・イン・タイム機能を使って新しいデータベースを作成することができる。
ディザスターリカバリー機能
Databases for MySQL は、以下のディザスタリカバリ機能をサポートしている：
| 特長 | 説明 | 考慮事項 |
|---|---|---|
| バックアップ・リストア | 以前に作成したバックアップからデータベースを作成する。 詳細については、 Cloud Databases バックアップの管理を 参照してください。 | 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
| ポイント・イン・タイム・リストア | ポイント・イン・タイム・リカバリを 使用して、本番環境からデータベースを作成します。 | これは、アクティブなデータベースが利用可能で、RPO（災害）がサポートされているウィンドウ内にある場合にのみ可能である。 本番クラスタが利用できない場合は役に立ちません。 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
| レプリカの販売促進 | 同じ地域や遠隔地での災害を想定する場合は、 読み取り専用のレプリカを 作成する。 災害から復旧するために、 読み取り専用のレプリカをプロモートする。 | 以前に作成されたリードレプリカが利用可能でなければならない。 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
災害復旧の計画
災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
| 失敗 | 解決方法 |
|---|---|
| ハードウェア障害（シングルポイント） | IBM は、ゾーン内の単一ハードウェア障害から回復力のあるデータベースを提供します。 |
| ゾーン障害 | フェイルオーバー (#mysql-high-availability) データベースのメンバーはゾーン間で分散される。 |
| データ破損 | バックアップ・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。
ポイントインタイム・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。 |
| 地域的な失敗 | バックアップ・リストア。 リストアしたデータベースを本番環境で使用する。
レプリカを読むことを推進する。 読み取り専用レプリカを読み取り/書き込みデータベースにプロモートする。 リストアしたデータベースを本番環境で使用する |
アプリケーション・レベルの高可用性
ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。 アプリケーションを設計する際には、デプロイメントまたは IBM Cloud への接続が一時的に失われてエラーが発生した場合に接続を再試行するように設計することができます。
Databases for MySQL はマネージドサービスであるため、定期的な更新やデータベースのメンテナンスは通常の運用の一環として行われます。 両方のレプリカが失われた場合、半同期レプリケーションプロセスにフォロワーが存在しないため、リーダーへの書き込みが停止します。 詳細については、 準同期レプリケーションを 参照のこと。 この状況により、データベースが一時的に利用できなくなることが時折あります。 また、データベースの正常なフェイルオーバー、再試行、および再接続が実施される可能性もあります。 レプリカであるメンバーとリーダーであるメンバーをデータベースが判別するのに短い時間がかかるため、短い接続の中断が発生する可能性があります。 フェイルオーバーにかかる時間は通常、30 秒未満です。 中断を最低限に抑えるために、更新はまずレプリカに、最後にリーダーに適用されます。
アプリケーションを設計する際には、データベースへの一時的な割り込みの処理、失敗したデータベース・コマンドのエラー処理の実装、一時的な中断から復旧するための再試行ロジックの実装を含める必要があります。
データベースを使用できない状態や接続の中断が数分に及ぶことは想定されていません。 1分以上接続できない状態が続く場合は、詳細を記載の上、 サポートチケット をご提出ください。調査させていただきます。
接続制限
Databases for MySQL では、MySQL データベースへの接続の最大数を 200 に設定します。 いくつかの接続は、データベースの状態と保全性を維持するために内部的に予約されているため、使用可能なままにしておいてください。 接続制限に達すると、それ以降、新しい接続を試みてもエラーが発生します。 接続が原因でデプロイメントが過負荷になることを防止するには、接続プーリングを使用するか、デプロイメントをスケーリングして接続制限を引き上げてください。 詳しくは、 MySQL 接続の管理を 参照。
HAとDRの責任
以下の情報は、HAとDRのプランを作成し、継続的に実践するのに役立つ。
バックアップからデータベースをリストアする場合、またはポイントインタイム・リストアを使用する場合、新しい接続文字列で新しいデータベースが作成されます。 既存のワークロードとプロセスは、新しい接続文字列を消費するように調整されなければならない。 リードレプリカをクラスタに昇格させる場合も同様の影響がありますが、ワークロードの既存のリードオンリー部分は影響を受けません。
復旧したデータベースは、障害データベースと同じように、 お客様依存関係を必要とする場合があります：
- IBM® Key Protect for IBM Cloud®
データベースを削除すると、関連するバックアップも削除されることを忘れないでください。 しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。 データベースの復旧手順の詳細については、 バックアップ FAQ を参照してください。
IBM Cloud、バックアップをコピーすることはできないため、追加のバックアップにはデータベース固有のツールを使用することを検討してください。 悪意のあるデータベースの削除に続き、データベースの再削除からの復旧が必要になる場合があります。 データベースへのIAMアクセスを注意深く管理することで、この問題にさらされる機会を減らすことができる。
各特徴に関連する以下のチェックリストは、プランの作成と実践に役立つ。
- バックアップ・リストア
- RPO要件を満たすために、望ましい頻度でバックアップが利用可能であることを確認する。 詳細については、 Cloud Databases バックアップの管理を 参照してください。 IBM Cloud® Code Engine を使用したスクリプトを検討してください - データベースの重要度とサイズが許せば、定期タイマー(cron)イベント プロデューサーと連携して 追加のオンデマンド バックアップを作成し、RPO を改善します。 しかし、 MySQL's PITRの能力を考慮し、追加バックアップの必要性を慎重に評価する。
- データベースのリストア領域にはいくつかの制限があります。 Cloud Databases バックアップの管理を 読んで、リストア目標が達成できることを確認してください。
- バックアップの保存期間が要件を満たしていることを確認する。
- テストリストアを定期的にスケジュールし、実際のリストア時間が定義されたRTOを満たしていることを検証する。 データベースのサイズはリストア時間に大きく影響することを忘れないでください。 大規模なデータベースをより小さく管理しやすい単位に分割し、未使用のデータを消去するなど、リストア時間を最短化する戦略を検討する。
- Key Protect サービスを確認する。
- ポイント・イン・タイム・リストア
- 先に説明した手順を確認する。
- 目的のバックアップがウィンドウ内にあることを確認します。
- レプリカの販売促進
- リカバリ領域にリードレプリカが存在することを確認する。
- 希望するリージョンに一時的なリードレプリカを作成する。 一時的なレプリカを読み取り/書き込みに昇格させ、本番環境にほとんど影響を与えることなくテストを行うことができます。
Databases for MySQL を使用する際の顧客と IBM Cloud との間の責任分担については、 Cloud Databases の責任分担を 参照のこと。
最新情報： IBM
顧客のワークロードに影響を与えるアップデートは、 IBM Cloud の通知で知らされる。 本サービスに関連する計画的なメンテナンス、アナウンスメント、リリースノートに関する情報は、 モニタリングの通知とステータスの ページをご参照ください。 さらに、 バージョン・ポリシーの ページを定期的に確認し、End-of-Lifeのバージョンと日付に関する最新のアップデートを確認してください。