Databases for MySQL の高可用性と災害復旧について

高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。サービスについては、可用性はサービスレベル契約で定義されています。可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。

Databases for MySQL は、標準プランで定義されたサービスレベル目標（SLO ）を満たす地域サービスである。詳しくは、サービス・レベル・アグリーメント（SLA ）をご覧ください。 Databases for MySQL で利用可能な IBM Cloud リージョンとデータセンターの詳細については、ロケーション別のサービスおよびインフラの可用性を参照してください。

高可用性アーキテクチャ

Databases for MySQL は、レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。デプロイメントには、3つのデータ・メンバー（リーダーと2つのレプリカ）を持つクラスタが含まれます。フェイルオーバーを処理するために、すべてのメンバーには Orchestrator を使用したデータのコピーが含まれています。リーダが到達不能になった場合、クラスタはフェイルオーバーを開始し、レプリカがリーダに昇格し、新しいレプリカがレプリカとしてクラスタに再参加し、クラスタは正常に動作し続けます。リーダーとレプリカは常にMZRの異なるゾーンにいる。レプリカが失敗すると、新しいレプリカが作成される。ゾーン障害でメンバーが失敗した場合、新しいレプリカは生き残ったゾーンに作成される。

クロスリージョナル・フェイルオーバーやリード・オフロードのためにリード専用レプリカをプロビジョニングすることで、高可用性をさらに拡張することができます。

半同期レプリケーション戦略に関連する制約とトレードオフを理解するために、レプリケーション技術に関する MySQL のドキュメントを確認してください。

プログラムでクラスタにアクセスするワークロードは、可用性を維持するためにクライアントの可用性再試行ロジックに従う必要があります。

Databases for MySQL 通常運転中に制御された切り替えを行うこともある。これらのスイッチオーバーは、アクティブなコネクションがリセットされるデータロスのないイベントである。最大 15 秒の、再接続が失敗する期間があります。時には、運用環境における予期せぬ出来事により、計画外のフェイルオーバーが発生することがある。最大45秒かかることもあるが、通常は30秒以内。例えば、サービスのメンテナンスは、制御されたフェイルオーバーの引き金となる。

高可用性機能

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®
Hyper Protect Crypto Services

データベースを削除すると、関連するバックアップも削除されることを忘れないでください。しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。データベースの復旧手順の詳細については、バックアップ 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のバージョンと日付に関する最新のアップデートを確認してください。