問題タブ [disaster-recovery]

障害復旧要件の必要性を考慮して、ES に使用できるアーキテクチャは何ですか。基本的に、異なる場所にある 2 つのクラスターのセットアップを維持する必要があります。cluster1 がダウンしている場合にのみ、要求は Cluster2 に送られます。ここでの課題は、2 つのクラスター間でインデックス データの一貫性を維持することです。

ES はこのタイプのセットアップをサポートしていますか? または、これを達成する方法を提案できる人はいますか? また、これらのクラスタへのデータの全ロード インデックス作成と増分更新を実現する方法についても説明します。

ありがとう、ラケシュ

何らかの理由で ***_status.tokudb ファイルが欠落している TokuDB テーブルがあります。

TokuDB のクラッシュが原因でファイルが欠落しているのかどうかはまだわかりません。

質問は:

• メイン ファイルとキー ファイルからステータス ファイルを復元または再作成する方法はありますか (これは tokudb_file マップから確認できます)。
• tokuDBステータスファイルが削除された原因をデバッグするにはどうすればよいですか?

これは本当によくあることですか、それとも既知のバグですか? https://github.com/percona/tokudb-engine/wiki/Broken-tables-caused-by-non-transactional-table-operations#unexplained-inconsistency-problems-with-tokudb

データセンター DC1 の Hadoop クラスター H1 に存在するデータを、データセンター DC2 の別の Hadoop クラスター H2 にレプリケートする最善の方法は何かと考えていました (ウォーム バックアップが望ましい)。Hadoop はデータのレプリケーションを行い、作成されるデータのコピーの数は、hdfs-site.xml で設定されたレプリケーション ファクターによって決定されることを知っています。これに関連していくつか質問があります

• H1 のデータ ノードが DC1 と DC2 の両方に存在するように、1 つのクラスターのデータ ノードを両方のデータ センターに分散させることは理にかなっていますか。これが理にかなっていて実行可能である場合、H2は必要ないということですか?

• データノードのみを両方のデータセンターに分散させるのではなく、ネームノードとデータノードを両方のデータセンターに分散させることは理にかなっていますか?

また、人々が distcp を使用しており、多くのツールが distcp の上に構築されていると聞いています。しかし、distcp は遅延バックアップを行い、コールド バックアップよりもウォーム バックアップを優先します。

これに Kafka を使用することを提案する人もいますが、どのように使用すればよいかわかりません。

どんな助けでも大歓迎です。ありがとう。

お客様のディザスター リカバリー ソリューションとして、VMware を使用した Azure Site Recovery の調査を開始しました。私が持っている主な疑問は、フェイルオーバーを自動化する方法です。つまり、オンプレミスの VM がオフラインであるかどうかを確認し、フェールオーバー プロセスを自動的に開始するように Azure に指示するにはどうすればよいでしょうか? それを実現するために OMS のようなものが必要ですか、それとも Automation Runbook などで十分でしょうか?

LDAP クライアントの設計に UnboundID LDAP SDK を使用しています。この API を使用したフォールト トレランス スキーマを考えています。プライマリ サーバーに LDAP セカンダリ サーバーを追加する必要があります。プライマリ サーバーに障害が発生した場合、サービスはセカンダリ サーバーに移動する必要があります。サービスは中断することなく継続する必要があります。UnboundID LDAP SDK でこれを実現するにはどうすればよいですか?

Windows サービスがクラッシュし、いくつかの回復オプションが原因で自動的に再起動されたとします。これが発生するたびにネットワークアクションを実行する（シャットダウンのアラートを送信する）プログラム（C＃）でコードを実行したいと考えています。

適用できるイベントや、その発生後に実行できるコードはありますか?

ありがとう！

BizTalk 障害復旧シナリオに関するヘルプを探しています。

DR サーバーにフェールオーバーし、Microsoft 標準のログ配布方法を使用してデータベースを復元しました。すべて問題なく実行されましたが、管理コンソールが元の SSO サーバーに接続しようとしているため、管理コンソールのポート設定を変更できません。

これは、管理コンソールによって表示されるエラーで、サーバー名が削除されているだけです。:-

送信ポート 'DRTestAppSendPort' のプライマリ トランスポートのトランスポート タイプ データを構成ストアに保存できませんでした。両方の SSO サーバー (プライマリ ='{クラスター化された古い SSO インスタンス}' およびバックアップ ='{古いアプリ サーバー}') が失敗しました。バックアップ サーバーのエラー: SSO サーバー '{Old app server}' に接続できませんでした。SSO が構成されていること、および SSO サービスがそのサーバーで実行されていることを確認してください。(Microsoft.BizTalk.ExplorerOM)

• SampleUpdateInfo.xml が正しく更新され、復元スクリプトが C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Bins32\Schema\Restore から 2 回実行されました。
• BizTalk 管理 DB には、[adm_OtherDatabases] に正しいサーバー名が含まれています。
• スクリプトの実行後、レジストリ設定はすべて正しくなります。
• SSOConfig –Status および SSOAdministration ユーティリティは、正しい DR アプリ サーバーをマスター シークレットとして報告します。
• BizTalk グループが削除され、管理コンソールに再度追加されました。
• DR サーバーで SSO マスター シークレットが正常に復元されました。
• Windows Management Instrumentation サービスが再起動されました..

これを修正する方法のアイデアが完全に不足しているため、どんなアイデアでも大歓迎です。

多くの msdn ドキュメントとフォーラムを調べましたが、解決策が見つかりませんでした。

クラッシュ前の状態=> SQL 2008 上の単一サーバー TFS 2010。

ポスト クラッシュ=> tfs コレクションを含むすべてのデータベースの SQL バックアップが利用可能でした。(TFS バックアップなし)

そのため、10 個のプロジェクト コレクション データベースといくつかの TFS データベースの SQL バックアップを継承しました。

現在の状態=> 新しい単一サーバー tfs 2015/sql 2012 インストール。SQL 2012 で復元された SQL バックアップ tfs 2015 で作成された新しいプロジェクト コレクション

ただし、復元されたデータベース プロジェクト コレクションを TFS 管理者からアタッチしようとすると、

次のエラーが表示されます

TF254078: SQL Server の次のインスタンスで接続可能なデータベースが見つかりませんでした: MyServerName。サーバーの名前とインスタンスの名前の両方が正しいこと、および Team Foundation 管理コンソールで detach コマンドを使用してデータベースが適切に切断されたことを確認してください。

SQL Server に正しく復元されたプロジェクト コレクションに TFS をアタッチできないのはなぜですか (と思います) を参照しました。 しかし、修正にはあまり役に立ちません。

これらのプロジェクト コレクション データベースは実際に tfs 2015 で復元できますか?

親切に、適切なデタッチ/アタッチを行うための 2010 セットアップがなく、新しい tfs 2015 プロジェクトを変更できないことに注意してください。