問題タブ [downtime]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
hosting - 合理的なダウンタイム
さまざまなホスティング プロバイダーを通じて、約 5 つの異なるホスト サーバーを実行しています。過去 2 か月間で、私が使用しているサーバーの 1 つが 2 回ダウンしました。どちらの時間も予想外で、かなり長かった (36 時間と 4 時間)。問題のサーバーは、共有サーバーではなく VPS です。他のサーバー/プロバイダー (VPS と共有の両方) での私の経験を考えると、これは許容できない量のダウンタイムのように思えます。
- どう思いますか?
- サーバーの合理的なダウンタイム (計画的および計画外) はどれくらいだと思いますか?
downtime - ウェブサイトを優雅にアップグレードする
Webサイトを適切にアップグレードするための好ましい方法はありますか?完全に新しいコードベースをサイトに配置する準備ができていますが、更新には数時間かかります。「アップグレードして、すぐに戻ってきて!」と言ってサイトがずっとダウンしてほしくない。メッセージが表示されますが、新しいサイトが配置されている間は、現在のサイトをそのままにしておくこともできません。
正常なアップグレードが可能になると私が考える唯一の方法は、2台のサーバーを使用することですが、これはより高価になります。
asp.net - web.config の編集 - ダウンタイムの原因?
私が作業しているサイトでは、2 つのクラスの変更を求めることができます。一方で、彼らは私が再構築して再展開しなければならないものを持っています. これらは「ダウンタイム」の変更としてカウントされます。これは、小さなスプラッシュ スクリーンを表示し、サイトに戻ったときにサイトを徹底的にテストするためです。
一方、彼らは私たちに多くのテキストの変更、機能のオンとオフの切り替えなどを行うように求めてきましたが、これは web.config に分離されています。展開ウィンドウの内側または外側でこれらを実行することを提案します。ファイルを編集し、変更が正しいことを確認して、作業に戻るだけです。
しかし、クライアント側の賢い人の 1 人は、web.config を編集するとアプリケーション プールがリサイクルされ、それがダウンタイムであると指摘しました。気付かなかったのですが、その通りだと思います。アプリ プールが利用できない間、アプリは「ダウン」しています。
しかし、どのくらいの期間ですか?ダウンタイム間隔でクライアントの快適さのレベルを分類するように求めているわけではありませんが、これは一般的な見方ですか? それとも、web.config の編集に 1 ~ 2 秒のアプリケーションのダウンタイムが伴うことを心配する必要はありませんか?
jakarta-ee - ダウンタイムなしでJavaEEアプリケーションを更新するにはどうすればよいですか?
展開を自動化(ダウンタイムなし)するにはどうすればよいですか?
また、メンテナンスのために任意のサーバーをオフにすることができます。
どのツールを使用する必要がありますか?
私はTomcatを使用していますが、提示された要件に最も適した他のJavaEEサーバーに移行したいと思っています。
すぐに使用できる構成の詳細を知りたいのですが。
google-app-engine - App Engine のダウンタイム
Google の App Engine には、特にデータストアの書き込みに関して過度のダウンタイムがありますか?
さらに、ダウンタイムはトラフィックの多い時間帯にスケジュールされているようです。たとえば、午前中の午前 3 時ではなく、午後の中頃です。これは正常ですか?技術が成熟するにつれて、それは改善されますか?
git - Git リポジトリを移動してダウンタイムを最小限に抑える方法
Git リポジトリを古い SCM サーバーから新しいサーバーに移動します。私の主な関心事 (もちろん忠実度以外) は、ダウンタイムを最小限に抑えることです。これが私の計画です:
- 新しいマシンで、次を使用して各リポジトリを複製します
git clone --mirror
- 各リポジトリのリポジトリ フックをコピーする
- 古いサーバーへのアクセスを禁止します (gitosis を使用しているため、新しいサーバーを除くすべてのユーザーのアクセスを削除します)
- DNS エントリを移動して、DNS エイリアス Git ユーザーが使用するようにします
git pull
新しいサーバー上のリポジトリごとに実行します。- 新しいサーバーのリポジトリごとに、構成ファイルを編集して
remote "origin"
セクションを削除します。 - 新しいサーバーへのアクセスをオンにする
質問:
- これは正しく見えますか?私は特にステップ#6に関心があります。
- ダウンタイムを短縮するこれを行う方法はありますか?
ありがとう。
google-app-engine - データストアとタスクキューのダウンタイムの相関関係
データストアとタスクキューのダウンタイムの間にはどのような相関関係がありますか?
(データストアのダウンタイムが発生した場合に、タスクキューを使用して一部の操作を延期したいと思います。)
google-app-engine - AppEngineでのフェイルセーフデータストアの更新
もちろん、AppEngineデータストアにはダウンタイムがあります。ただし、データストアエラーに直面してもより堅牢な「フェイルセーフ」プットが必要です(以下の動機を参照)。データストアが利用できない場合、タスクキューは書き込みを延期するための明白な場所のようです。ただし、他の解決策はわかりません(urlfetchを介してデータをサードパーティに送信する以外)。
動機:データストアに配置する必要のあるエンティティがあります。ユーザーにエラーメッセージを表示するだけでは不十分です。たとえば、簡単に元に戻すことができない何らかの副作用が発生した可能性があります(おそらくサードパーティのサイトとの相互作用)。
私は(私が思うに)合理的な「フェイルセーフ」プットを提供する単純なラッパーを思いついた(以下を参照)。これに問題がありますか、またはより堅牢な実装のアイデアがありますか?(注:NickJohnsonとSaxonDruceによる回答に投稿された提案のおかげで、この投稿はコードにいくつかの改良を加えて編集されました。)
タスクのリクエストハンドラ:
私はこれをすべてのプットに使用することを期待していません-ほとんどの場合、エラーメッセージを表示することは問題ありません。すべてのプットに使用したくなりますが、変更が後で表示されることをユーザーに伝えると(データストアがバックアップされて延期されるまで古いデータを表示し続けると、ユーザーが混乱する可能性があると思います)puts execute)。
sql-server-2005 - データベース スキーマの変更でゼロ ダウンタイムの展開を実現する方法
データベース スキーマの変更中に、e コマース サイトのゼロ ダウンタイム展開を達成する必要があります。データベースは sql server 2005 です。誰かが次の手順が実行可能かどうかを確認できますか? あなたの提案を提供してください。
- プリンシパル データベースが要求を処理し、変更がミラー データベースにレプリケートされます。
- デプロイの前に、プリンシパルからミラーへのレプリケーション プロセスを停止します。
- ミラー化するデータベース スキーマの変更を実行します。
- 少しの間、プリンシパルを読み取り専用にします。
- 変更をプリンシパルからミラーに再度複製します。
- リクエストをミラーにルーティングする (役割の切り替えを実行する)
- 元のプリンシパルに対してデータベース スキーマの変更を実行します (役割の切り替え後にミラー化されます)。
web - サイトへの ping は、サイトがダウンしているかどうかを確認する良い方法ですか?
Web ホストがダウンしているかどうかを確認し、稼働時間を計算したり、ダウンしている場合は警告したりできる、小さな Web サイト監視プログラムを作成しようとしています。スタンドアロンアプリになります。
サイトがダウンしているかどうかを確認するのに ping が有効かどうか知りたいです。
前もって感謝します。