Как эмулировать MySQL, не слушая в порту с помощью iptables?
Я использую mysql_nd в php для подключения к базам данных mysql и переключения при отказе между несколькими ведомыми устройствами и мастером, поэтому, когда mysql не работает на сервере, все работает нормально, и все запросы отправляются на другие серверы.
Мне нужно, чтобы сервер mysql был запущен и работал на сервере, но блокировал все входящие соединения, поэтому драйвер mysql_nd в php считает, что сервер не работает. Я думал, что простого REJECT с питьевыми напитками будет достаточно, но его нет; пакеты отклоняются, соединение mysql не установлено, но приложение php ведет себя по-другому, потоки php ждут и увеличиваются, пока не достигнут максимума.
Если служба mysql не работает, mysql_nd просто обнаруживает ее немедленно, запросы перенаправляются на другие серверы, никакого замедления не происходит, потоки php накапливаются на веб-сервере.
Даже с запущенной службой mysql, как только я добавляю или вставляю правило iptbles с отклонением, запросы также перенаправляются на другие серверы, но php накапливается так, как если бы соединение с mysql оставалось открытым по любой причине, поэтому я предполагаю отклонить Пакет с iptables для порта возвращает что-то отличное от ядра Linux, которое ничего не слушает в этом порту.
Есть ли способ сделать это поведение с iptables?
Решение
Сервер, который открыто выставляет закрытый порт, откажется от соединения. Мне кажется, это хорошо смоделировано правилом iptables REJECT. Это также, вероятно, то, что вы получите, если ваш сервер приложений попытается подключиться к базе данных во время запуска, но до того, как он будет готов, так что это правильный случай для обработки, хотя вам может потребоваться воспроизвести. Вы, вероятно, должны заставить этот ответ работать тоже.
Однако сервер, который вообще не отвечает, не может отправить отказанное соединение или отклонить какие-либо пакеты. Такое поведение лучше моделируется с помощью iptables DROP, который просто отбрасывает пакет без дополнительного ответа. Соединение в конечном счете истекает на стороне клиента, вводя некоторое регулирование к клиентским запросам.
Вы можете прочитать больше о разнице между отклонением и отбрасыванием здесь https://serverfault.com/questions/157375/reject-vs-drop-when-using-iptables но для ваших целей достаточно сказать, что сервер, который не может ответить (не существует или не функционирует), смоделирован с помощью DROP, а сервер, который не будет отвечать (не прослушивает порт или явно отклоняет), смоделирован с помощью REJECT.
Другие решения
Других решений пока нет …