アカウント名:
パスワード:
バックアップ環境を待機系のように運用していたためのようです。
「のように」というよりは、普通の待機系にしか見えないんだけど...。じゃなきゃ、
脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
なんて話は出てこないと思うんだが...。
待機系にパッチを当ててメインに昇格、確認後元メインにも同様にパッチを当てるとかやらないのかなあ。外部から見てメインが落ちてる時間を短縮できるし切り替えが正常に行えることも確認できる。
仮定の話に仮定をしても意味は無いですが、
待機系にパッチ当てている間にメインに保存しているデータが更新されたらどうなるんでしょう?
パッチ適用有無でデータ矛盾が生じるならば、待機系にだけパッチを当てるような手順はやってはいけません。
一般的なWeb - DB構成なら、Webのプライマリ、セカンダリ(待機)を交互にパッチ適用、再起動しても別サーバのDBに影響は無いし、多少金かけてDBもフェイルオーバーさせるなら、若干のダウンタイムを我慢しつつ片っぽずつパッチ適用と再起動させて後はDBの機能で上手いこと整合性合わせてくれるように期待するだけなんだけど、君は何をそんなに気にしてるの?
さぁ?ミラーリング構成のDBを両方飛ばしたのかもしれないし、SQLiteをWebごと消したのかもしれないし、プランをパッと見てもどういう構成になってるのかわからんのでそんなんわからんわ。てか、プラン毎に違んじゃないかそれ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
待機系だよなぁ、やっぱり。 (スコア:2)
バックアップ環境を待機系のように運用していたためのようです。
「のように」というよりは、普通の待機系にしか見えないんだけど...。じゃなきゃ、
脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
なんて話は出てこないと思うんだが...。
Re: (スコア:0)
待機系にパッチを当ててメインに昇格、確認後元メインにも同様にパッチを当てるとかやらないのかなあ。外部から見てメインが落ちてる時間を短縮できるし切り替えが正常に行えることも確認できる。
Re: (スコア:1)
Re: (スコア:0)
仮定の話に仮定をしても意味は無いですが、
待機系にパッチ当てている間にメインに保存しているデータが更新されたらどうなるんでしょう?
パッチ適用有無でデータ矛盾が生じるならば、待機系にだけパッチを当てるような手順はやってはいけません。
Re: (スコア:1)
Re: (スコア:0)
一般的なWeb - DB構成なら、Webのプライマリ、セカンダリ(待機)を交互にパッチ適用、再起動しても別サーバのDBに影響は無いし、
多少金かけてDBもフェイルオーバーさせるなら、若干のダウンタイムを我慢しつつ片っぽずつパッチ適用と再起動させて後はDBの機能で上手いこと整合性合わせてくれるように期待するだけなんだけど、君は何をそんなに気にしてるの?
Re:待機系だよなぁ、やっぱり。 (スコア:2)
Re: (スコア:0)
さぁ?
ミラーリング構成のDBを両方飛ばしたのかもしれないし、SQLiteをWebごと消したのかもしれないし、
プランをパッと見てもどういう構成になってるのかわからんのでそんなんわからんわ。
てか、プラン毎に違んじゃないかそれ。
Re:待機系だよなぁ、やっぱり。 (スコア:2)