基本的に このスレッド で述べたのと同じ問題があります-特定のバックエンドのすべてのサーバーへのすべての要求を一時的に一時停止して、バックエンドとそれが使用するデータベースをアップグレードできるようにします。これはライブシステムなので、リクエストをキューに入れ、アップグレードしたらバックエンドサーバーに送信したいと思います。コードを変更してデータベースをアップグレードしているので、すべてのバックエンドサーバーを同時にアップグレードする必要があります。そのため、一度に1つずつダウンさせることはできません。
そのスレッドで言及されているように、静的ヘルスチェックファイルを削除することと組み合わせてtcp-requestオプションを使用しようとしましたが、うまくいきませんでした。デフォルトの「maxconn」値を0に設定すると、接続が一時停止してキューに入れられるように見えますが、HAProxyを再起動せずに値を正の数に戻す方法はないようです。これにより、それまでキューに入れられていたすべてのリクエストが強制終了されます。ポイント。 (-sfと-stを使用した「ホット再構成」オプションは新しいプロセスを開始しますが、これは私が望むことをしていないようです)。
私がやろうとしていることは可能ですか?
最終的に、HAProxyの作成者であるWillyTarreauにこの質問をすることになりました。彼は私の提案に興味をそそられ、管理ソケットを介してmaxconnをゼロに設定できるようにするHAProxyへの小さな変更をコミットしました(これは私が尋ねた時点では不可能でした)。これで私の問題は解決しました。私が彼に送ったフォローアップメールからの引用:
こんにちは。それは私の問題をかなりうまく解決します。 「setmaxconnfrontend my_frontend 0」を発行し、接続がドレインされるまで数秒待った後、後続のすべての接続が一時停止しました。サーバーを再起動し、「set maxconn frontend my_frontend 3000」を発行すると、既存のリクエストでエラーが発生することなく、接続が正常に再開されました。
JessePの答えに応えて、絶対に、ほとんどの場合、私はこれをしたくありません。トラフィックの一時停止はせいぜいリスクがあるため、通常、DBの移行はお客様が言及したとおりにステージングします。一部のユーザーは、クライアント側のタイムアウトを途方もなく低く設定しているため、通常、トラフィックを15秒以上中断したくありません。しかし、コードとデータの移行の複雑なセットを同時に実行する最近の移行では、このオプションを利用できるようにすることは命の恩人でした。
したがって、要約すると、これを日常の使用にはお勧めしませんが、必要が生じた場合にオプションがあります。
要求したことを達成したとしても、将来的にはデータ移行の実行時間が長くなったり、サーバーが多すぎて更新できなくなったりすることになり、クライアントは何かが来るのを待つ間にタイムアウトになります。オンラインに戻る。
既存のサーバーが引き続き実行できるように、更新をビルドするようにしてください。これには、既存のデータベースで更新されたコードを展開し、データベースを更新してから、実際の更新を展開することが含まれる場合があります。
最終的には、問題を起こすことなく、一度に1つのサーバーをデプロイできるはずです。