У меня в основном та же проблема, что и в эта тема - Я хотел бы временно приостановить все запросы ко всем серверам определенного бэкэнда, чтобы я мог обновить бэкэнд и базу данных, которую он использует. Поскольку это действующая система, я хотел бы ставить запросы в очередь и отправлять их на серверные серверы после их обновления. Поскольку я выполняю обновление базы данных с изменением кода, мне нужно обновлять все внутренние серверы одновременно, поэтому я не могу просто отключать один за раз.
Я попытался использовать параметры tcp-request в сочетании с удалением файла статической проверки работоспособности, как упоминалось в этом потоке, но мне не повезло. Установка значения по умолчанию "maxconn" на 0, кажется, приостанавливает и ставит в очередь соединения по желанию, но тогда, похоже, нет способа увеличить значение до положительного числа без перезапуска HAProxy, который убивает все запросы, которые были поставлены в очередь до этого. точка. (Параметры «горячей реконфигурации» с использованием -sf и -st запускают новый процесс, который, похоже, не делает то, что я хочу).
Возможно ли то, что я пытаюсь сделать?
В конце концов я задал этот вопрос Вилли Тарро, автору HAProxy. Он был заинтригован моим предложением и внес небольшое изменение в HAProxy, которое позволяет установить maxconn до нуля через сокет администратора (это было невозможно в то время, когда я спросил), что решило мою проблему. Цитата из последующего письма, которое я ему отправил:
Всем привет. Это очень хорошо решает мою проблему. Я выдал команду «set maxconn frontend my_frontend 0», подождал несколько секунд, пока соединения не истощатся, а затем все последующие соединения приостанавливаются. Я перезапустил сервер, выдал команду «set maxconn frontend my_frontend 3000», и соединения возобновились должным образом, без ошибок в существующих запросах.
В ответ на ответ JesseP - абсолютно точно, большую часть времени я никогда не хочу этого делать. Обычно мы стараемся провести миграцию БД точно так, как вы упомянули, потому что приостановка трафика в лучшем случае рискованна. Некоторые из наших пользователей устанавливают смехотворно низкие таймауты на стороне клиента, поэтому обычно мы не хотим, чтобы трафик приостанавливался более чем на 15 секунд. Но для недавней миграции, когда у нас был сложный набор переносов кода и данных, которые нужно было выполнять одновременно, наличие этой опции было спасением.
Итак, подводя итог - не рекомендую это для повседневного использования, но вариант есть, если возникнет необходимость.
Даже если вы выполните то, о чем просите, в будущем у вас будет более длительная миграция данных, слишком много серверов для обновления и т.д. снова в сети.
Вам действительно следует попытаться создать свои обновления так, чтобы существующие серверы могли работать. Это может включать развертывание некоторого обновленного кода с существующей базой данных, затем обновление базы данных, а затем развертывание фактического обновления.
В конце концов, у вас должна быть возможность развертывать по одному серверу за раз, без каких-либо проблем.