アカウント名:
パスワード:
バックアップ環境を待機系のように運用していたためのようです。
「のように」というよりは、普通の待機系にしか見えないんだけど...。じゃなきゃ、
脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
なんて話は出てこないと思うんだが...。
待機系にパッチを当ててメインに昇格、確認後元メインにも同様にパッチを当てるとかやらないのかなあ。外部から見てメインが落ちてる時間を短縮できるし切り替えが正常に行えることも確認できる。
仮定の話に仮定をしても意味は無いですが、
待機系にパッチ当てている間にメインに保存しているデータが更新されたらどうなるんでしょう？
パッチ適用有無でデータ矛盾が生じるならば、待機系にだけパッチを当てるような手順はやってはいけません。
だから関係ないじゃん。そら本番系は稼働中なのだからデータの書き換えは発生するでしょう。待機系ってどういうものかわかってないのですかねぇ。
発生するんじゃないの？それがどうしたの？
一般的なWeb - DB構成なら、Webのプライマリ、セカンダリ（待機）を交互にパッチ適用、再起動しても別サーバのDBに影響は無いし、多少金かけてDBもフェイルオーバーさせるなら、若干のダウンタイムを我慢しつつ片っぽずつパッチ適用と再起動させて後はDBの機能で上手いこと整合性合わせてくれるように期待するだけなんだけど、君は何をそんなに気にしてるの?
単純にWebサーバとDBサーバが同じマシンに同居している環境しか触ったことがないんじゃないですか?
さぁ?ミラーリング構成のDBを両方飛ばしたのかもしれないし、SQLiteをWebごと消したのかもしれないし、プランをパッと見てもどういう構成になってるのかわからんのでそんなんわからんわ。てか、プラン毎に違んじゃないかそれ。
仮定に仮定を重ねてもしょうがないけどさ，それはとてもとても愚問というものだ．
A(初期状態の稼働系)の最新状態に同期したB(初期状態の待機系)を用意していて，Aが故障により一時停止し，Bが業務を引き継いだ場合(Bが稼働系になる)を仮定する．その後，Aを修理して待機系として再接続するためには，A上のデータは古くなっているから，B上のデータをA上のデータに反映する何らかの手段は「必ず」必要になる．
言い換えれば，2台のサーバで稼働系-待機系という構成を採っている時，待機系が再起動したり，ある程度の時間停止していたりするとい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
待機系だよなぁ、やっぱり。 (スコア:2)
バックアップ環境を待機系のように運用していたためのようです。
「のように」というよりは、普通の待機系にしか見えないんだけど...。じゃなきゃ、
脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
なんて話は出てこないと思うんだが...。
Re: (スコア:0)
待機系にパッチを当ててメインに昇格、確認後元メインにも同様にパッチを当てるとかやらないのかなあ。外部から見てメインが落ちてる時間を短縮できるし切り替えが正常に行えることも確認できる。
Re: (スコア:1)
Re: (スコア:0)
仮定の話に仮定をしても意味は無いですが、
待機系にパッチ当てている間にメインに保存しているデータが更新されたらどうなるんでしょう？
パッチ適用有無でデータ矛盾が生じるならば、待機系にだけパッチを当てるような手順はやってはいけません。
Re:待機系だよなぁ、やっぱり。 (スコア:1)
Re: (スコア:0)
だから関係ないじゃん。
そら本番系は稼働中なのだからデータの書き換えは発生するでしょう。
待機系ってどういうものかわかってないのですかねぇ。
Re: (スコア:0)
発生するんじゃないの？
それがどうしたの？
Re: (スコア:0)
一般的なWeb - DB構成なら、Webのプライマリ、セカンダリ（待機）を交互にパッチ適用、再起動しても別サーバのDBに影響は無いし、
多少金かけてDBもフェイルオーバーさせるなら、若干のダウンタイムを我慢しつつ片っぽずつパッチ適用と再起動させて後はDBの機能で上手いこと整合性合わせてくれるように期待するだけなんだけど、君は何をそんなに気にしてるの?
Re:待機系だよなぁ、やっぱり。 (スコア:2)
Re: (スコア:0)
単純にWebサーバとDBサーバが同じマシンに同居している環境しか触ったことがないんじゃないですか?
Re: (スコア:0)
さぁ?
ミラーリング構成のDBを両方飛ばしたのかもしれないし、SQLiteをWebごと消したのかもしれないし、
プランをパッと見てもどういう構成になってるのかわからんのでそんなんわからんわ。
てか、プラン毎に違んじゃないかそれ。
Re:待機系だよなぁ、やっぱり。 (スコア:2)
Re: (スコア:0)
仮定に仮定を重ねてもしょうがないけどさ，それはとてもとても愚問というものだ．
A(初期状態の稼働系)の最新状態に同期したB(初期状態の待機系)を用意していて，Aが故障により一時停止し，Bが業務を引き継いだ場合(Bが稼働系になる)を仮定する．その後，Aを修理して待機系として再接続するためには，A上のデータは古くなっているから，B上のデータをA上のデータに反映する何らかの手段は「必ず」必要になる．
言い換えれば，2台のサーバで稼働系-待機系という構成を採っている時，待機系が再起動したり，ある程度の時間停止していたりするとい