OCIフル・スタック・ディザスタ・リカバリを使用したレプリケーション・チャネルによるMySQL HeatWaveのディザスタ・リカバリの自動化
はじめに
Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)は、1回のクリックで、世界中のOCIリージョン間のコンピュート、データベース、アプリケーションの移行をオーケストレーションします。お客様は、既存のインフラストラクチャ、データベースまたはアプリケーションを再設計または再設計することなく、また特殊な管理サーバーや変換サーバーを必要とせずに、1つ以上のビジネス・システムをリカバリするために必要なステップを自動化できます。
MySQL HeatWaveは、Oracle Cloud Infrastructure(OCI)内に導入されたフルマネージド・データベース・サービスであり、セキュアなクラウドネイティブ・アプリケーションを迅速に導入しようとしているオペレータや開発者をサポートします。MySQL HeatWaveは、統合された高パフォーマンスのインメモリー・クエリ・アクセラレータであるHeatWaveを使用する機能を含む唯一のMySQL製品です。HeatWaveを使用すると、お客様は、運用上のMySQLデータベースに対して高度な分析を直接実行できるため、複雑で時間がかかり、コストがかかるデータの移行や、別々の分析データベースとの統合が不要になります。HeatWaveは、分析および混合ワークロードでMySQLパフォーマンスを大幅に高速化します。HeatWaveはOCI用に完全に最適化されており、MySQL HeatWaveはOCIおよびMySQLエンジニアリング・チームによって構築、管理、サポートされています。
このチュートリアルでは、チャネル・レプリケーションを使用してOCIのMySQL HeatWaveのディザスタ・リカバリ計画を自動化する方法を学習します。ここでは、MySQL HeatWaveをネイティブにサポートしてスイッチオーバーおよびフェイルオーバー操作を管理するようになったOCI Full Stack DRの使用手順について説明します。
アーキテクチャの説明
このチュートリアルで紹介するアーキテクチャは、MySQL HeatWaveを示しています。インバウンド・レプリケーションを使用して、プライマリ・データベース・システムとリモート・レプリカ間の非同期データ・レプリケーションを有効にし、リージョン間の効率的なデータ同期を実現します。

画像full-stack-disaster-recovery-heatwave.pngの説明
ノート: ディザスタ・リカバリ・リージョンのMySQL HeatWaveレプリカでは、データの整合性を確保し、意図しない変更を防ぐために読取り専用モードを有効にする必要があります。
前提条件(ユーザーの準備)
レプリケーションセットアップを開始する前に、次の前提条件が満たされていることを確認してください。これには、レプリケーション固有の要件と、Oracle Cloud Infrastructure (OCI)上のMySQL HeatWaveの堅牢なフル・スタック・ディザスタ・リカバリ(FSDR)・アーキテクチャをサポートするために必要な追加のインフラストラクチャおよび構成前提条件の両方が含まれます。
- ネットワーク接続
次のものを使用して、ソース・リージョンとターゲット・リージョン間のセキュアな通信を確立します。- Dynamic Routing Gateways(DRG)
- リモート・ピアリング接続
- ネットワーク構成
リージョン間のMySQLトラフィックを許可するように、次を構成します:- セキュリティ・リスト**または**ネットワーク・セキュリティ・グループ(NSG)
- ルーティング表
- フル・スタック・ディザスタ・リカバリ次のドキュメントで説明するように、OCI Full Stack DRに必要なOCI IAMポリシーを構成します。
OCI Full Stack DRには、コンピュート、ネットワーキング、ストレージ、その他のサービスなどの他の主要なOCIサービスを制御および管理する機能が必要です。他のサービスに必要なOCI IAMポリシーを構成するには、フル・スタック・ディザスタ・リカバリによって管理される他のサービスのポリシーおよびOCI IAMポリシーを参照してください。
ノート: MySQL HeatWaveの場合
MySQL HeatWaveをFSDRで構成するための前提条件として、OCI Vaultシークレットを両方のリージョンで作成する必要があります。これらのシークレットには、管理ユーザー・パスワードおよびレプリケーション・ユーザー・パスワードを安全に格納する必要があります。
MySQL HeatWaveシステム設定- 概要
次に、Oracle Cloud Infrastructure (OCI)でMySQL HeatWaveのリージョン間レプリケーションを設定し、リージョン間のセキュアで信頼性が高くスケーラブルなデータ同期を確保するために必要なステップの概要を示します。
- プライマリMySQL HeatWaveをソース・リージョンにデプロイします。
- 適切な権限を持つソースMySQLサーバーにレプリケーション・ユーザーを作成します。
- プライマリ・データベースの手動によるバックアップの作成。
- OCIのバックアップのコピー機能を使用して、ターゲット・リージョンにバックアップをコピーします。
- ターゲット・リージョンのバックアップをリストアして、新しいスタンバイDBシステムを作成します。
- スタンバイDBシステムのモードを「読取り専用」に変更します。
- ターゲット・リージョンで、次を使用してレプリケーション・チャネルを設定します:
- ソースDBホスト名、ポート
- レプリケーション・ユーザー資格証明
- ターゲットMySQL DBで定期的にレプリケーション・ステータスをモニターします。
- データ整合性チェックを実行して、レプリケーションが正確であり、データの整合性が維持されていることを検証します。
これらのステップに従うことで、OCI上のMySQLの堅牢なリージョン間レプリケーション設定を実装し、地理的リージョン間のアプリケーションの耐障害性および可用性を強化できます。
ノート:次のチュートリアル: OCIでのリージョン間MySQL HeatWaveディザスタ・リカバリ・コピーの設定では、MySQLデータベース・システムにディザスタ・リカバリをデプロイするための包括的なガイドを提供し、システム障害が発生した場合のレジリエンスと継続性を確保します。
チュートリアル全体での定義と仮定
-
リージョン:
-
リージョン1はアッシュバーン:アッシュバーンは最初はプライマリ・リージョンとして機能します。ただし、このロールはスイッチオーバー・プロセス中にスタンバイに移行します。スイッチオーバー・プロセスは、ディザスタ・リカバリ計画の一部として後のタスクで実行されます。
-
リージョン2はフェニックス:フェニックスは、最初はスタンバイ・リージョンとして機能します。このロールは、スイッチオーバー・プロセス後にプライマリに移行します。スイッチオーバー・プロセスは、ディザスタ・リカバリ手順の一部として後続のタスクで実行されます。
-
-
コンパートメント:このデプロイメントおよびOCI Full Stack DRは、ITガバナンスの標準内で動作する任意のコンパートメント・スキームに自由に編成できます。このチュートリアルのすべてのOCIリソースを1つのコンパートメントに編成することを選択しました。
目的
このチュートリアルでは、次のタスクについて説明します。
- タスク1: 両方のリージョンでのDR保護グループ(DRPG)の作成
- タスク2: 両方のリージョンのDR保護グループへのMySQL HeatWaveの追加
- タスク3: リージョン2でのDR計画の作成
- タスク4: リージョン2でのDR計画の事前チェックの実行
- タスク5: リージョン2でのスイッチオーバー計画の実行
- タスク6: リージョン1でのDR計画の作成
タスク1: 両方のリージョンでのDR保護グループ(DRPG)の作成
このアプリケーション・スタックの保護グループがまだ存在しない場合は、リージョン1およびリージョン2でDR保護グループを作成します。
タスク1.1: リージョン1での保護グループの作成
-
図1.1に示すように、OCIコンソールに移動し、「DR保護グループ」に移動します。
- OCIリージョン・コンテキストがリージョン1 (アッシュバーン)に設定されていることを確認します。
- 「移行とディザスタ・リカバリ」をクリックします。
- 「DR保護グループ」をクリックします。
図1.1: DR保護グループに移動します。 -
「DR保護グループの作成」をクリックして、ダイアログを開きます。
図1.2:「DR保護の作成」をクリックします -
図1.3に示すように、リージョン1に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
- DRPGにわかりやすい名前を使用します。
- DRPGを作成するコンパートメントを選択します。
- OCI Full Stack DRログのOCI Object Storageバケットを選択します。
- 「作成」をクリックします。
図1.3:リージョン1でDR保護グループを作成するために必要なパラメータ
タスク1.2: リージョン2での保護グループの作成
-
図1.4に示すように、OCIコンソールに移動し、「DR保護グループ」に移動します。
- OCIリージョン・コンテキストがリージョン2 (フェニックス)に設定されていることを確認します。
- 「移行とディザスタ・リカバリ」をクリックします。
- 「DR保護グループ」をクリックします。
図1.4: DR保護グループに移動します。 -
「DR保護グループの作成」をクリックして、ダイアログを開きます。
図1.5:「DR保護の作成」をクリックします -
図1.6に示すように、リージョン2で基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
- DRPGにわかりやすい名前を使用します。
- DRPGを作成するコンパートメントを選択します。
- OCI Full Stack DRログのOCI Object Storageバケットを選択します。
- 「作成」をクリックします。
図1.6:リージョン2でDR保護グループを作成するために必要なパラメータ
タスク1.3: リージョン1およびリージョン2での保護グループの関連付け
各リージョンのDRPGを互いのピアとして関連付け、プライマリおよびスタンバイのピア・ロールを割り当てます。プライマリおよびスタンバイのロールは、DR操作/DR計画実行の一部としてOCI Full Stack DRによって自動的に変更されます。ロールをいつでも手動で管理する必要はありません。
-
「DR保護グループの詳細」ページに移動します。
- OCIリージョン・コンテキストがリージョン1 (アッシュバーン)に設定されていることを確認します。
- 「アクション」をクリックします。
- 「関連付け」をクリックしてプロセスを開始します。
図1.7: DRPGアソシエーションの開始 -
次の図に示すようにパラメータを入力してください。
- ロール: 「プライマリ」ロールを選択します。OCI Full Stack DRは、スタンバイ・ロールをリージョン2に自動的に割り当てます。
- ピア・リージョン:他のDRPGが作成されたリージョン2 (フェニックス)を選択します。
- ピアDR保護グループ:作成されたピアDRPGを選択します。
- 「関連付け」をクリックします。
図1.8: DRPGを関連付けるために必要なパラメータ -
作業リクエストが完了してから続行してください。
図1.9: DRPGアソシエーションが完了しました。
OCI Full Stack DRは、アソシエーションが完了すると、次のイメージに示すように表示されます。
- 現在のプライマリ・ピアDRPGはアッシュバーン(リージョン1)です。
- 現在のスタンバイ・ピアDRPGはフェニックス(リージョン2)です。
図1.10:個々のDRPGの観点から見たピア関係の表示
コンテキスト/ビューがグローバルな観点から見ると、次の図に示すようにすべてのDR保護グループを示す場合でも、同じ情報を確認できます。
- 現在のプライマリ・ピアDRPGはアッシュバーン(リージョン1)です。
- 現在のスタンバイ・ピアDRPGはフェニックス(リージョン2)です。
図1.11:グローバルDRPGの観点から見たピア関係の表示
タスク2: DR保護グループへのMySQL HeatWaveの追加
タスク2.1: リージョン1のDRPGへのMySQL HeatWaveの追加
-
次の図に示すように、Region 1のDRPGを選択します。
- OCIリージョン・コンテキストがリージョン1 (アッシュバーン)であることを確認します。
- 「Region 1」で「DRPG」を選択します。
- 「メンバー」を選択します。
- 「メンバーの管理」をクリックしてプロセスを開始します。
図2.1:リージョン1でDR保護グループへのメンバーの追加を開始する方法 -
「メンバーの追加」をクリックします。
図2.2:リージョン1のDR保護グループへのメンバーの追加を開始します。 -
MySQL HeataWaveをリージョン1のDRPGに追加します。
- メンバーのリソース・タイプとしてMySQL Database Systemと入力します。
- 適切なコンパートメントを選択し、「データベース・システム」フィールドからリージョン1のプライマリMySQL HeatWave名を選択します。
- 適切なコンパートメントを選択し、ピア・データベース・システム・フィールドからリージョン2のレプリカMySQL HeatWave名を選択します。
- Admin usernameを入力します。
- 適切なコンパートメントを選択し、「管理パスワード・シークレット」を選択します。
- Replication usernameを入力します。
- 適切なコンパートメントを選択し、「レプリケーション・パスワード・シークレット」を選択します。
- 「追加」をクリックします。
オプションのパラメータ:
- Reconciliation Timeout: リコンシリエーション・プロセス中にグローバル・トランザクション識別子(GTID)の同期を待機する時間を秒単位で指定します。このタイムアウト設定により、操作が失敗または完了したと判断する前に、システムでGTID同期に十分な時間が確保されます。
- リコンシリエーション・タイムアウトで続行: このオプションを有効にすると、タイムアウトを超えた後にGTID検証プロセスがバイパスされます。これにより、GTID同期が不完全であっても、フェイルオーバーまたはスイッチオーバーを続行できます。
図2.3: MySQL HeatWaveの追加に必要なパラメータ -
DRPGリージョン1での変更の公開
「変更の公開」をクリックします。
図2.4:変更の公開確認するには、「変更の公開」
図2.4:「変更の公開」をクリックします。
図2.5: MySQL HeatWaveがリージョン1のDRPGに追加されました。
タスク2.2: リージョン2のDRPGへのMySQL HeatWaveの追加
-
次の図に示すように、リージョン2のDRPGを選択します。
- OCIリージョン・コンテキストがリージョン2 (フェニックス)であることを確認します。
- 「Region 2」で「DRPG」を選択します。
- 「メンバー」を選択します。
- 「メンバーの管理」をクリックしてプロセスを開始します。
図2.6:リージョン2でDR保護グループへのメンバーの追加を開始する方法 -
「メンバーの追加」をクリックします。
図2.7:リージョン2のDR保護グループへのメンバーの追加を開始します。 -
MySQL HeataWaveをリージョン2のDRPGに追加します。
- メンバーのリソース・タイプとしてMySQL Database Systemと入力します。
- 適切なコンパートメントを選択し、「データベース・システム」フィールドからリージョン2の「レプリカ」MySQL HeatWave名を選択します。
- 適切なコンパートメントを選択し、ピア・データベース・システム・フィールドからリージョン1のプライマリMySQL HeatWave名を選択します。
- Admin usernameを入力します。
- 適切なコンパートメントを選択し、「管理パスワード・シークレット」を選択します。
- Replication usernameを入力します。
- 適切なコンパートメントを選択し、「レプリケーション・パスワード・シークレット」を選択します。
- 「追加」をクリックします。
オプションのパラメータ:
- Reconciliation Timeout: リコンシリエーション・プロセス中にグローバル・トランザクション識別子(GTID)の同期を待機する時間を秒単位で指定します。このタイムアウト設定により、操作が失敗または完了したと判断する前に、システムでGTID同期に十分な時間が確保されます。
- リコンシリエーション・タイムアウトで続行: このオプションを有効にすると、タイムアウトを超えた後にGTID検証プロセスがバイパスされます。これにより、GTID同期が不完全であっても、フェイルオーバーまたはスイッチオーバーを続行できます。
図2.8: MySQL HeatWaveの追加に必要なパラメータ -
DRPGリージョン2の変更を公開します。
「変更の公開」をクリックします。
図2.9:変更の公開「変更の公開」をクリックして確認します。
図2.10:変更の公開
図2.11: MySQL HeatWaveがリージョン2のDRPGに追加されました。
タスク3: リージョン2でのDR計画の作成
このタスクでは、リージョン2 (フェニックス)のスタンバイDR保護グループに関連付けられた初期スイッチオーバーおよびフェイルオーバー計画を作成します。
これらの計画の目的は、ワークロードをプライマリ・リージョン(リージョン1)からスタンバイ・リージョン(リージョン2)にシームレスに移行することです。DR操作の一環として、両方のリージョンのDR保護グループのロールが自動的に元に戻されます。リージョン1の保護グループはスタンバイになり、リージョン2の保護グループはフェイルオーバーまたはスイッチオーバーの後にプライマリ・ロールを引き継ぎます。
OCI Full Stack DRは、前のタスクで追加されたメンバー・リソースから導出された組込みステップを使用して、これらのプランを事前移入します。MySQL HeatWaveがフル・スタック・ディザスタ・リカバリと統合されているため、DR計画には適切なMySQL HeatWaveリカバリ・タスクが自動的に事前移入されます。
DR計画は、常にスタンバイ・ロールを保持する保護グループ内に作成されます。リージョン2 (フェニックス)は現在スタンバイ保護グループであるため、そこでプランの作成を開始します。
タスク3.1: DR計画の作成
-
リージョン2 (フェニックス)でDRPGを選択して基本プランを作成します
- OCIリージョン・コンテキストがリージョン2 (フェニックス)であることを確認します。
- リージョン2でスタンバイDRPGを選択します。
- 「プラン」を選択します。
- 「プランの作成」をクリックしてプロセスを開始します。
図3.1:リージョン2での基本的なDR計画の作成を開始する方法 -
スイッチオーバー計画を作成します。
- スイッチオーバー・プランの単純でわかりやすい名前を入力します。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目で理解しやすい名前にする必要があります。
- 「プラン・タイプ」に「スイッチオーバー(計画済)」を選択します。
図3.2: DRスイッチオーバー計画の作成に必要なパラメータ
図3.3: DRスイッチオーバー計画DR計画名をクリックすると、DR計画の詳細と計画グループが表示されます。
図3.4: DRスイッチオーバーの「MySQL HeatWave Plan」グループ -
フェイルオーバー計画を作成します。
- フェイルオーバー・プランの単純でわかりやすい名前を入力します。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目で理解しやすい名前にする必要があります。
- 「プラン・タイプ」に「フェイルオーバー(計画外)」を選択します。
図3.5: DRフェイルオーバー計画の作成に必要なパラメータ
図3.6: DRフェイルオーバー計画DR計画名をクリックすると、DR計画の詳細と計画グループが表示されます。
図3.7: DRフェイルオーバーのMySQL HeatWaveプラン・グループ
リージョン2のスタンバイDR保護グループには、2つのDR計画が必要です。これらは、リージョン1からリージョン2へのワークロードの移行を処理します。
ノート: スイッチオーバー計画の初回実行後に、リージョン1で対応する計画を作成して、ワークロードをリージョン2から戻します。
- (オプション)DRドリル計画の作成- ドリルの開始およびドリルの停止。
スイッチオーバー計画およびフェイルオーバー計画と同様に、ドリルの開始DR計画を作成できます。ドリルの開始中に、使用可能な最新のバックアップを使用して新しいDBシステムが作成され、DRリージョン内の操作をリカバリする必要がある実際のディザスタ・リカバリ・シナリオがシミュレートされます。
- 「ドリルの開始」プランの単純でわかりやすい名前を入力します。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目で理解しやすい名前にする必要があります。
-
「プラン・タイプ」に「ドリルの開始」を選択します。
図3.8:開始ドリル・プランの作成に必要なパラメータ
「ドリルの開始」が正常に完了した後、「ドリルの停止」を作成/実行する必要があります。この計画では、ドリルの開始の実行中に作成されたDBシステムを終了し、テスト目的で使用された一時リソースをクリーン・アップします。
タスク4: リージョン2での事前チェックの実行
スイッチオーバーおよびフェイルオーバーの両方のDR計画がスタンバイ・リージョン2に正常に作成されました。これらの計画により、OCI Full Stack DRは、リージョン1からリージョン2にワークロードを移行できます。後続のタスクでは、スイッチオーバー計画とフェイルオーバー計画の両方の事前チェックを実行して、準備状況を確認し、移行プロセスを検証します。
タスク4.1: スイッチオーバー計画の事前チェックの開始
スイッチオーバーDR計画の事前チェックを実行します。
- リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
- リージョン2の正しいDR保護グループが選択されていること、それがスタンバイ・ロールであることを確認してください。
- スイッチオーバー・プラン名をクリックします。
- アクションをクリックします。
- 「事前確認の実行」をクリックします。
図4.1:スイッチオーバー計画の事前チェックを実行する方法を示しています。
図4.2:スイッチオーバー計画の事前チェックを実行する方法を示しています。
スイッチオーバー事前チェックの実行グループを計画します。
図4.3:スイッチオーバー・プランの完了した事前チェックの表示
タスク4.2: フェイルオーバー計画の事前チェックの開始
フェイルオーバーDR計画の事前チェックを実行します。
- リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
- リージョン2の正しいDR保護グループが選択されていること、それがスタンバイ・ロールであることを確認してください。
- フェイルオーバー計画名をクリックします。
- アクションをクリックします。
- 「事前確認の実行」をクリックします。
図4.4:フェイルオーバー計画の事前チェックを実行する方法を示しています。
図4.5:フェイルオーバー計画の事前チェックを実行する方法を示しています。
スイッチオーバー事前チェックの実行グループを計画します。
図4.6:フェイルオーバー計画の完了済事前チェックの表示
タスク5: リージョン2でのスイッチオーバー計画の実行
スイッチオーバーDR計画を実行して、MySQL HeatWaveを使用してWordPressアプリケーションをリージョン1からリージョン2に移行するプロセスを開始します。
- リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
- リージョン2の正しいDR保護グループが選択されていること、それがスタンバイ・ロールであることを確認してください。
- スイッチオーバー・プラン名をクリックします。
- アクションをクリックします。
- 「計画の実行」をクリックします。
図5.1:スイッチオーバー計画の実行方法を示します。
このタスクでは、リージョン2でスイッチオーバー計画が実行されます。
- タスク4ですでに実行されているため、「事前チェックの有効化」の選択を解除します。
- 「DR計画の実行」をクリックします。
図5.2:スイッチオーバー計画の実行方法を示します。
「DR計画の実行」をクリックして
を開始します。
図5.3:スイッチオーバー計画の実行を確認する方法を示しています。
完全なワークロードがリージョン1からリージョン2に完全に移行されるまで、スイッチオーバー計画を監視すること。
図5.4:進行中のスイッチオーバー計画グループの実行を示しています。
スイッチオーバー計画の実行が正常に完了しました。
図5.5:完了したスイッチオーバー計画の実行を示しています。
タスク6: リージョン1でのDR計画の作成
OCI Full Stack DRによるスイッチオーバーが正常に完了したことで、リージョン2はプライマリ・リージョンのロールを引き受け、リージョン1はスタンバイ・リージョンとして機能するように移行しました。
タスク3で説明した同じアプローチに従って、リージョン1のDR保護グループ内にスイッチオーバーおよびフェイルオーバー計画を作成します。この計画は、スタンバイ・ピア・リージョンとして機能します。
図6.1:リージョン1で作成したプランを示すスクリーンショット
図6.2:リージョン1のスイッチオーバー計画を示すスクリーンショット
図6.3:リージョン1のフェイルオーバー計画を示すスクリーンショット
次のステップ
詳細は、「関連リンク」の項のOCI Full Stack DRおよびMySQL HeatWaveのドキュメントを参照してください。
関連リンク
-
#full-stack-drスラックチャネルに参加する
確認
-
著者 - Antoun Moubarak氏(設計、CTO担当オフィス- EMEAテクノロジ・エンジニアリング)
-
コントリビュータ - Suraj Ramesh (OCI Full Stack DRの製品マネージャー)
その他の学習リソース
docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。
製品ドキュメントについては、Oracle Help Centerを参照してください。
Automate Disaster Recovery for MySQL HeatWave with Replication Channels Using OCI Full Stack Disaster Recovery
G42707-02