アプリケーションのディザスタリカバリでは、MySQLデータテーブルをクラウド間で同期する必要がありますか？

背景

ディザスタリカバリシステムの重要な目標は、システムデータとサービスの「継続性」を確保することです。システムに障害が発生した場合、ディザスタリカバリシステムはサービスを迅速に復元し、データの有効性を確保できます。自然災害、人為的災害、不可抗力を防止するために、対応するITシステムが同じ都市または異なる場所に確立されています。中心的な作業はデータの同期です。

この記事では、アプリケーション層のディザスタリカバリシナリオで、クラウド間で同期する必要のあるデータテーブルと、クラウド間で同期する必要のないデータテーブルについて説明します。特定のケースを通じて、読者が同期テーブルとフィルターテーブルの方法をより適切に分類して、アプリケーション層のビジネスディザスタリカバリ要件を満たすのに役立ちます。

2つの関連用語

この記事で説明するシナリオは、Alibaba Cloudのアプリケーション層の災害復旧に基づいており、次の重要な用語が含まれ
ます。RDSMySQL：MySQLバージョンは、オープンソースソフトウェアの組み合わせLAMP（Linux + Apache + MySQL + Perl）/ PHP / Python）。これはさまざまなアプリケーションシナリオで広く使用されています。Alibaba Cloud RDS MySQLバージョンは、カーネルの詳細な最適化と排他的なインスタンスを通じて、安定した極端なデータベースパフォーマンスを提供します。同時に、柔軟なデプロイメントアーキテクチャと製品フォームは、さまざまなシナリオでデータベース要件を満たすことができます。

DTS：Data Transmission Serviceは、リレーショナルデータベース（MySQLなど）、NoSQL、ビッグデータ（OLAP）などのデータソース間のデータ転送をサポートします。これは、データ移行、データサブスクリプション、およびリアルタイムのデータ同期を統合するデータ送信サービスです。データ送信は、パブリッククラウドおよびハイブリッドクラウドのシナリオにおける長距離のミリ秒レベルの非同期データ送信の問題の解決に取り組んでいます。データ転送を使用して、安全でスケーラブルな高可用性（災害耐性）データアーキテクチャを簡単に構築します。

ASR：ASR-DR（Apsara Stack Resilience Disaster Recovery）は、ディザスタリカバリ機能を提供し、RDSMySQLディザスタリカバリ管理をサポートするクラウド製品です。ASRは、災害耐性スイッチングを迅速に実装し、災害発生時にRTOを可能な限り削減するために開発された、グラフィカルなインタラクティブスイッチングツールです。

同期テーブル：この記事では、RDS MySQLデータベースとデータテーブルについて具体的に説明します。これらのテーブルは、あるクラウドから別のクラウドにバックアップする必要があります。つまり、クロスクラウド同期です。

フィルターテーブル：この記事では、RDS MySQLデータベースとデータテーブルについて具体的に説明します。これらのテーブルは、あるクラウドから別のクラウドに移動することはできません。

アプリケーション構成テーブル：この記事では、RDS MySQLのアプリケーション層のデータテーブルについて具体的に説明します。このテーブルには、IP、ドメイン名、スケジュールされたタスクのオン/オフステータスなど、アプリケーション層の関連する構成情報が記録されます。

シーケンス：グローバルに一意のシリアル番号ID。分散システムで広く使用されており、トランザクションのシリアル番号、ユーザーIDなどに使用できます。これは、検索、データの保存、検索速度の高速化など、多くの面で非常に重要です。このIDは多くの場合、データベースの主キーであり、グローバルに一意で、同時実行性が高く、フォールトトレラントな単一障害点が必要です。パフォーマンスを向上させるために、アプリケーション層は通常、データベースからシリアル番号のバッチ（たとえば、10,000）を毎回取得し、データベースへの頻繁なアクセスを回避するためにアプリケーションメモリに保存します。メモリ内のシリアル番号が使用された後、シリアル番号の新しいバッチがデータベースから再度取得されます。

ディザスタリカバリのアプリケーションにおけるフィルタテーブルに関する3つの重要な技術的問題

クロスクラウド同期を行わないフィルターテーブルを整理する必要があるのはなぜですか？

非災害耐性アプリケーション

• バックアップセンターのリソース制限：実際のプロジェクトでは、バックアップセンターのリソース制限により、アプリケーションシステムをバックアップセンターに展開できません。したがって、耐災害性のないアプリケーションに対応するデータベースとデータテーブルを配置する必要はありません。同期。
• 運用と保守の一時バックアップデータベースとバックアップテーブルを同期する必要はありません。日常の運用と保守では、DBAは通常、データベースに変更を加えるときに一時バックアップを作成します。一時的にバックアップされるデータベースまたはデータテーブルは、Alibaba Cloud RDS MySQL Cluster自体によってバックグラウンドでバックアップされるため、ユーザーがクラウド間同期を再度実行する必要はありません。このようにして、同期リンクの帯域幅と災害耐性スイッチングの管理ワークロードを削減できます。
• 耐災害性をサポートしないアプリケーション：クラウド製品の耐災害性機能の構築は継続的なプロセスです。一部のクラウド製品は、プロジェクトの提供段階でまだ耐災害性機能を備えていませんが、ユーザーのアプリケーションはこれらの指定されたクラウド製品に依存しています。したがって、アプリケーションのこの部分は一時的にディザスタリカバリドリルを実行できず、対応するデータベースとデータテーブルも一時的に同期されない可能性があります。アプリケーションのプロセス全体が災害耐性のサポートに依存しているクラウド製品の後で、データの同期を実行できます。

別の構成テーブル

• アプリケーションの構成方法：コードと構成を別々に管理するために、アプリケーションシステムは通常、構成パラメーターを別々に保存および管理します。一般的な設定フォームには、設定ファイル、RDS MySQLデータベース、専用の設定センターが含まれます。専用の設定センターもRDSMySQLを使用してバックグラウンドでデータを保存します。よりタブーな方法は、IP、ドメイン名などの構成パラメーターをコードにハードコーディングすることです。
• 環境パラメーター：アプリケーションソフトウェアがRDS MySQL、OSS、SLBなどのクラウド製品を使用する場合、IP、ドメイン名、アカウントパスワード、およびAK / SKを介して接続する必要があります。
• アプリケーションパラメータ：一部の関数はセンター内のアプリケーションでのみ実行でき、これらの関数スイッチはデータテーブルの特定のフィールド値によって制御されます。たとえば、特定の時間指定タスクは、外部機関と定期的にバッチ呼び出しを行います。2つのセンターの時限タスクが同時に実行されると、外部組織のバッチ処理が繰り返し実行される可能性があります。これは、外部組織が同じバッチ処理タスクの繰り返し実行をサポートできるかどうかによって異なります。これらのタイミングタスクの構成テーブルは、デュアルセンターで個別に構成する必要があります。
• 都市内防災の構成方法：ポイント2の環境パラメータはデフォルトで同じです。同じ都市のクラウドのデュアルセンター間の距離は比較的短く（100 km未満）、アプリケーションはクラウドの2つのアベイラビリティーゾーンにデプロイされ、クラウド製品の接続情報は同じです。したがって、アプリケーションソフトウェアを展開すると、同じ環境パラメータにアクセスします。このシナリオでは、分類する必要のある環境パラメーターは比較的少ないです。
• リモートディザスタリカバリの構成方法：ポイント2の環境パラメータが異なります。同じ都市にある2つのクラウドのデュアルセンターは遠く（100 km以上）にあり、アプリケーションは2つのクラウドの2つのアベイラビリティーゾーンにデプロイされており、クラウド製品の接続情報は異なります。したがって、アプリケーションソフトウェアが展開されると、さまざまな環境パラメータにアクセスします。このシナリオでは、各アプリケーションがさまざまな環境パラメーターを個別に分類する必要があります。さまざまな環境パラメーターが配置されているデータテーブルは、クラウド間で同期できません。同期しないと、アプリケーションシステムの展開が失敗します。

二重に書く必要のあるビジネステーブル

• デュアルライトシナリオ：a）ビジネストラフィックは、アプリケーション層デュアルアクティブと呼ばれるデュアルセンターで同時に処理され、データテーブルは同時にデュアルセンターに書き込まれる必要があります。b）アプリケーションの実行中にマイクロサービスの呼び出しログを記録します。理想的には、アプリケーションは、処理中のビジネストラフィックがある場合にのみデータベースにデータを記録する必要があります。実際のプロジェクトでは、ビジネスに特殊な状況があります。バックアップセンターのアプリケーションでは、トラフィックリクエストがなくても、マイクロサービスの呼び出しログ、スケジュールされたタスクログ、更新などのログが定期的に書き込まれます。グローバル一意のシリアル番号アプリケーションの起動時のシーケンスなど。待機します。デュアルライトシナリオでは、プライマリセンターとスタンバイセンターの両方のRDSMySQLに読み取りと書き込みのアクセス許可が必要です。
• 都市内のアクティブ-アクティブシナリオ：同じ都市の1つのクラウドのアクティブ-アクティブアーキテクチャでは、メインセンターとスタンバイセンターが統合されたクラウド製品接続情報をアプリケーション層に提供し、アプリケーションはRDSMySQLへの書き込み権限を持ちます。
• リモートアクティブ/スタンバイシナリオ：2つのリモートクラウドのアクティブ/スタンバイアーキテクチャでは、プライマリセンターのRDS MySQLがアプリケーション層に読み取りと書き込みのアクセス許可を提供し、スタンバイセンターのRDSMySQLがアプリケーション層に読み取り専用のアクセス許可を提供します。この許可戦略は、ポイント1の二重書き込み要件を満たすことができません。したがって、二重に記述されたテーブルの場合、フィルターテーブルはアプリケーションのディメンションに従って並べ替える必要があります。

クラウド間で同期されていないデータテーブルを整理するにはどうすればよいですか？

このプロジェクトでは、アプリケーションソフトウェア開発者がビジネスロジックの実現にもっと注意を払っていることに気付くでしょう。クラウド製品のベストプラクティスと災害耐性機能についての彼らの理解は、私たちの期待とは異なる場合があります。コーミングフィルターテーブルは主にアプリケーション開発者によって実装され、コーミングプロセスにはいくつかの一般的な問題があります。

• 設計および開発中に、開発者はディザスタリカバリ中に同期されていないフィルタテーブルを減らすために何をすべきですか？
• 展開および運用と保守の期間中、運用と保守の担当者はどの観点からフィルターテーブルの整合性と正確性を確保する必要がありますか？

エラーを整理した場合、アプリケーション層のディザスタリカバリの演習にどのような影響がありますか？

プロジェクトでは、建設期間の制約と本番システムの安定した運用によって制限されることがよくあります。アプリケーション開発者とクラウドプラットフォームメーカーが設計と開発のベストプラクティスを知っていても、内で変換を完了することは困難です。時間制限。したがって、展開、運用、保守の期間中は、フィルターテーブルを整理し、緊急時の計画を立てることが災害復旧演習の重要なタスクです。

フィルタテーブルのエラーを整理した場合、アプリケーション層のディザスタリカバリにどのような影響があるかを分析してみましょう。

災害耐性のないアプリケーションへの影響：

• 効果はほとんどありません。前に分析したように、災害に耐性のないアプリケーションでデータのバックアップを実行する必要がないことをお勧めします。または、バックアップセンターアプリケーションを本番環境でデータのバックアップに使用しないでください。

ディザスタリカバリアプリケーションへの影響：

• バックアップセンターがアプリケーションを展開した後、アプリケーションは起動に失敗し、この時点で間違った環境パラメータが識別される可能性があります。対策は、対応するデータテーブルの同期を停止し、読み取りおよび書き込み権限を修正した後、展開を続行することです。
• バックアップセンターアプリケーションの機能をテストするときは、バックグラウンドのタイミングタスクとビジネス以外のリクエストに焦点を合わせてRDS MySQLシナリオを作成し、テストフェーズ中にフィルターテーブルのリストを変更します。
• 本番システムの実行時にディザスタリカバリ切り替えの演習を実行します。リモートディザスタリカバリアーキテクチャでは、フィルタテーブルのリストが間違っていると、データベースの主キーの書き込み競合でエラーが発生し、書き込みビジネスの失敗の問題が発生する可能性があります。このとき、非常停止、非常停止、同期機能の追加、データテーブルフィールド値の変更、アプリケーション方式の再起動などで復旧できます。次の演習の前に、フィルターテーブルのリストを修正してください。このシナリオについては、この記事の後半でケースを使用して簡単に説明します。

アプリケーションのディザスタリカバリにおける4つの設計非同期データテーブル

以前、アプリケーションのディザスタリカバリでテーブルを同期しない必要性を紹介しました。このセクションでは、フィルタテーブルを分類および設定する方法について説明します。以下の分析は理想的な状況であり、実際のプロジェクトにはいくつかの違いがあります。

クラウドプラットフォームの視点

• クラウドプラットフォームの機能を理解する：現在、主流のクラウドプラットフォームベンダーはRDS MySQL製品を持っていますが、各ベンダーのRDS MySQLは、同じ都市のマルチアベイラビリティーゾーンと異なる場所のマルチリージョンで異なる災害耐性機能を備えています。ユーザーは、各クラウドベンダーのデータ同期機能が、同じ都市と異なる場所の両方でバックグラウンドで自動的に実行されることを理解する必要がありますか？または、ツール（Alibaba CloudのDTSなど）を使用しますか？それとも手動で行われますか？
• フィルタテーブルの設定方法：Alibaba Cloud DTS製品は、RDSMySQLインスタンスの同期リンクを作成するときに同期されないデータベースとデータテーブルの設定をサポートしています。
• フィルタテーブル機能の自動設定：ディザスタリカバリの実行中に、メインスイッチとスタンバイスイッチが関与するため、対応するデータ同期の方向が逆になります。これを順方向同期と逆方向同期と呼びます。同期の方向が逆の場合、ディザスタリカバリスイッチングプラットフォームは、フィルタテーブルの自動構成をサポートする必要があります。Alibaba Cloud ASR-DRは、同期リンクが初めて作成されたときのフィルターテーブルのリストの保存をサポートし、ASR-DRは、同期方向が切り替わるたびに、新しいリンクのフィルターテーブルを自動的に構成します。

以下は、AlibabaCloudデータ転送サービスDTS製品の公開情報ドキュメントです。

アプリケーション層の視点

次に、アプリケーション開発者のいくつかの段階に焦点を当て、クラウドのディザスタリカバリに基づいてアプリケーションソフトウェアを効果的に提供する方法を分析します。

1.設計段階：

• クラウドの災害耐性に基づいてアイデアを設計します。将来的には、アプリケーションが2つ以上のクラウドに、場合によっては異なるベンダーのクラウドプラットフォームにデプロイされることを考慮してください。したがって、IOEアーキテクチャに基づく初期のディザスタリカバリアーキテクチャでは、プロのストレージハードウェアによって完了されたデータレイヤーの同期はマルチクラウドシナリオには適用できず、Oracleの高価なライセンスも多くの企業に受け入れられません。
• 現在の構成がどのクラウドに適用されるかを示すために、各クラウドおよび各センターの識別パラメーターを予約することを検討してください。構成センターは、現在の動作環境で有効になるクラウドパラメーターを一律に管理し、アプリケーションコードは、実行されているクラウドに注意を払う必要がありません。
• シーンの1つでのみ実行できる機能を特定し、これらの機能のスイッチを配置します。構成センターを介して動的に構成可能で効果的なスイッチを設定します。時限タスクに焦点を合わせます。
• これらの機能スイッチの操作は、周囲の人に電話をかけて閉じてもらうのではなく、限られた緊急の災害耐性切り替え時に操作および保守担当者が迅速に操作できるように、白い画面のインターフェイスに配置することをお勧めします。どのライブラリ、どのテーブルのどのフィールドがスイッチを制御するかという特定の時間指定タスク。
• フィルタリングテーブルのリストを記録し、時間内に更新します。

2.開発段階：

• 最初に構成センターを使用して、パラメーターを保存します。実際のプロジェクトでは、構成センター、構成ファイル、RDS MySQL、さらにはコードにアドレス、アカウントパスワードを直接エンコードするなど、構成を保存する方法はたくさんあります。Alibaba Cloud EDAS製品は、構成センター機能を提供します。これは、アプリケーションの再起動を有効にすることなく、動的構成、静的構成、および構成変更後の動的プッシュをサポートします。
• 構成センター自体のアドレスをアプリケーションの構成ファイルに記録し、構成ファイルとアプリケーションを一緒にパッケージ化してリリースすることができます。デプロイメント後に構成センターサービスが変更されることはめったにないためです。
• 設定センターを一時的に使用できない場合は、RDSMySQLを使用して設定を管理する必要があります。さまざまなクラウド環境パラメーターを記録する構成を別のデータテーブルに配置することをお勧めします。また、個別に提供する機能スイッチの構成も、ビジネステーブルと結合せずに別のデータテーブルに配置する必要があります。利点は、フィルターテーブルの管理の難しさを軽減することです。クラウド製品のドメイン名、IP、アカウントパスワード、AK / SKに焦点を当てます。

3.展開フェーズ：

• 運用保守担当者と開発者は、各フィルターテーブルを選択した理由と、その背後にあるビジネス基盤を確認しますか？フィルタテーブルが他にもあるかどうかに注意してください。
• 各データベースにログインし、ディザスタリカバリスイッチングプラットフォームASR-DRが期待どおりにフィルタテーブルを設定したかどうかを確認します。フィルタテーブルが数百ある場合、省略やエラーが発生しやすくなります。
• スタンバイセンターで事前にビジネス機能を検証するための条件を作成し、フィルターテーブルのシナリオが期待を満たしているかどうかに焦点を当て、タイミングタスクが1つのセンターでのみ実行されるかどうかに焦点を当てます。

4.運用および保守段階：

• 構成の変更は、両方のクラウドのフィルターテーブルで同時に実行されます。フィールドの追加やフィールドタイプの調整など、メインセンターでフィルタステップテーブルが変更された場合、バックアップセンターはそれを認識できないため、バックアップセンターで同じ変更を手動で行う必要があります。そうしないと、ディザスタリカバリがバックアップセンターに切り替えられた後、テーブルが更新されないため、アプリケーションエラーが発生します。
• フィルタテーブルが同期テーブルに復元されます。フィルタテーブルのリストを早期に分類するのは誤りであり、より多くのフィルタテーブルが構成され、後で検証を同期する必要がありました。データテーブル内の全量のデータを再同期し、このテーブルがディザスタリカバリ管理プラットフォームASR-DRで同期されているかどうかのフラグを変更する必要があります。
• 同期テーブルがフィルターテーブルに変更されます。ビジネス調整のため、早期に同期されたテーブルは、将来再度同期する必要はありません。このテーブルがディザスタリカバリ管理プラットフォームASR-DRおよびディザスタリカバリ管理プラットフォームで同期されているかどうかのフラグを変更する必要があります。 ASR-DR。

次の図は、リモートディザスタリカバリマスター/バックアップアーキテクチャの同期テーブルとフィルタテーブルの構成ロジックの説明を示しています。

5つのケース

次のリモートディザスタリカバリプロジェクトの分析では、フィルタリストリストの並べ替えが間違っているため、ビジネスの異常な問題と処理経験が発生し、読者はデータテーブルをクラウド間で同期する必要があるかどうかをよりよく理解できます。 。

（1）問題の説明

Alibaba CloudディザスタリカバリプラットフォームのASR-DRがアプリケーションのディザスタリカバリスイッチを実行した後（RDS MySQLの読み取りおよび書き込み権限がクラウドAからクラウドBに切り替えられた）、ビジネスリクエストがスタンバイセンター（クラウドB）にある場合、ビジネスエラーが報告され、データベースは「プライマリキーの競​​合」を要求します。

（2）問題分析

問題処理の順序に従って、問題の特定プロセスを分析します。

1.データベースエラー「主キーの競合」を分析します。

• 競合するフィールド値がトランザクションのシリアル番号IDであることを確認してください。ビジネスデータシートをチェックして、このIDのトランザクション情報がすでに存在することを確認してください。

2.ビジネスリクエストパスを分析します。

• 二重書き込みが異常なアクセス層のトラフィックスケジューリングによって引き起こされているかどうかを分析します。リモートディザスタリカバリのアクティブおよびスタンバイアーキテクチャでは、アクセスレイヤのグローバルロードバランシングデバイスGSLB制御により、メインセンターのみにサービス要求トラフィックがあり、スタンバイセンターにはサービス要求トラフィックがないことが保証されます。したがって、デュアルセンターサービスの二重書き込みによって引き起こされる主キーの競合の疑いを排除できます。
• メインセンターのアプリケーション層のキャッシュが、アクティブ/スタンバイの切り替え後にデータの書き込みを遅らせるかどうかを分析します。アクティブ/スタンバイアーキテクチャでは、ディザスタリカバリプラットフォームASR-DRプラットフォームは、スタンバイセンター内のアプリケーションに対してRDS MySQLの読み取りおよび書き込みアクセス許可を開く前に、プライマリセンターのRDSMySQLデータベースアクセス許可が読み取り専用に設定されていることを確認します。メインセンターのアプリケーション層にキャッシュ遅延書き込みがある場合でも、耐災害性の切り替え後、メインセンターアプリケーションにはデータを書き込む権限がなく、二重書き込みのシナリオはありません。この疑いを排除します。
• ディザスタリカバリの切り替え前にシリアル番号が使用されているかどうかを分析します。メインセンターのデータベースにログインし、シリアル番号フィールドの現在使用可能な範囲が[90000000000、18446744073709551615]であることを確認します。これは、90000000000未満のシリアル番号が使用されたことを示します。主キーの競合を促す現在のシリアル番号80000000000には、ビジネステーブルに対応するトランザクションレコードがあります。したがって、このトランザクションレコード番号がメインセンターで使用されていることを確認してください。
• 準備センターアプリケーションによって取得されたシリアル番号の記録を分析します。アプリケーションログから、スタンバイセンターアプリケーションは、最初に起動したときに一度最新のシリアル番号を取得し、その後データベースから最新のシリアル番号を取得しなかったことがわかります。同時に、アプリケーションのメモリ値を確認し、スタンバイセンターが現在シリアル番号の範囲[80000000000、80000009999]を使用していることを確認します。明らかに、これは期限切れのシリアル番号です。

問題の結論：スタンバイセンターアプリケーションは、期限切れのトランザクションシリアル番号IDを使用します。これにより、データベースへの書き込み時に「主キーの競合」が発生します。

3.問題の導入プロセスを分析します。

• アプリケーションのシリアル番号を取得するプロセスを分析します。アプリケーションを初めて起動すると、データベースから10,000の使用可能なシリアル番号を取得し、データベースとアプリケーションのメモリ値を更新します。
• プライマリセンターとスタンバイセンターのデータ同期メカニズムを分析します。グローバルに一意のシリアル番号を管理するデータテーブルxx_tableとして、データ同期ツールDTSは、データが2つのセンター間でリアルタイムに同期され、データベースがシリアルになるときに確実に同期されます。番号が更新され、データベースが追加されます。ロックは不整合を防ぎます。理論的には、アクティブセンターとスタンバイセンターで同じシリアル番号が取得されることはありません。
• プライマリセンターとバックアップセンターのデータテーブルxx_tableの内容に一貫性があるかどうかを分析します。プライマリセンターのシリアル番号の使用可能な範囲は[90000000000、18446744073709551615]であり、シリアル番号の使用可能な範囲はバックアップセンターは[80000010000、18446744073709551615]です。この2つは一貫しておらず、データテーブルが同期されていないことを示しています。
• データ同期ツールDTSを確認してください。正常に動作し、エラーや誤動作は見つかりません。
• フィルタテーブルのリストを確認します。グローバル一意シリアル番号を管理するデータテーブルxx_tableはクラウド間で同期する必要がありますが、フィルタテーブルとして構成されているため、データの同期に失敗します。
• フィルタリングテーブルの並べ替えプロセスを確認します。ディザスタリカバリ演習の前の準備段階で、運用および保守担当者がアプリケーションをバックアップセンターに展開した後、ビジネス担当者は機能トランザクションが失敗したことを確認します。失敗の理由は、アプリケーションの起動時にシリアル番号を取得した後、アプリケーションがデータベースへの書き込みに失敗し、書き込み権限がないことを示しているため、トランザクション関数の初期化が失敗するためです。アクティブ/スタンバイアーキテクチャでは、デフォルトで、プライマリセンターアプリケーションにはRDS MySQLの読み取りおよび書き込み権限があり、スタンバイセンターにはRDSMySQLの読み取り専用権限があります。バックアップセンターの起動時にいくつかの権限が必要なため、ビジネス担当者は、グローバル一意シリアル番号を管理するデータテーブルxx_tableを、同期されていないフィルタテーブルのリストに追加しました。その結果、このテーブルはプライマリセンターから同期されません。バックアップセンターへ。

問題の結論：グローバル一意シリアル番号を管理するデータテーブルxx_tableが、クラウド間で同期しないフィルターテーブルのリストに誤って追加されています

緊急措置

• バックアップセンターのデータテーブルxx_tableのシリアル番号の有効範囲を正しい[90000000000、18446744073709551615]に手動で修正します。
• スタンバイセンターのアプリケーションソフトウェアを再起動して、アプリケーションをトリガーし、シリアル番号を再度取得します。

改善策

• データの同期：グローバル一意シリアル番号を管理するデータテーブルxx_tableを同期する必要があります。フィルターテーブルリストからxx_tableを削除して、プライマリセンターとセカンダリセンターの有効なシリアル番号の範囲が一貫していることを確認します。
• アプリケーションの変更：バックアップセンターがRDS MySQLへの読み取り専用アクセス権を持っている場合、シリアル番号の更新は失敗することが許可され、アプリケーションの初期化は成功します。耐災害性の切り替え後、バックアップセンターがRDS MySQの読み取りおよび書き込み権限を取得した後、ビジネスリクエストによってトリガーされ、オンデマンドで最新のシリアル番号を再度取得します。
• テスト効果：
  • メインセンターとスタンバイセンターがデータを同期した後、同期リンクを切断し、スタンバイセンターデータベースを手動で読み取り専用に設定します。
  • 変換されたアプリケーションを再デプロイし、アプリケーションが正常に起動し、ビジネスリクエストが（期待どおりに）読み取り専用モードで失敗することを確認します。
  • スタンバイセンターデータベースを手動で読み取りおよび書き込みに設定すると、ビジネスリクエストが成功し、アプリケーションが有効なシリアル番号を再度取得できるかどうかを確認します。
  • メインセンターとバックアップセンター間のデータ同期リンクを再構成します。
• ディザスタリカバリドリル：ビジネスシナリオ全体を検証するために、別のドリルを実行します。

改善前

改善後

6つの要約

• 耐災害訓練は、システムの問題を発見するための開始点であり、終了点ではありません。システムの耐災害機能を維持するには、定期的な訓練が必要です。
• クラウドプラットフォームの災害耐性は、アプリケーションの災害耐性と同等ではなく、アプリケーションレベルの災害耐性は体系的なエンジニアリングです。
• 技術的にはクラウドプラットフォーム、アプリケーション、ネットワークを含むエンジニアリング機能をチェックするための演習を通じて、プロセスには、障害判断、災害耐性の意思決定、ハンドオーバー操作、緊急時計画などが含まれます。

元のリンク

この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。