Я работаю над настройкой кластера узлов MariaDB 3 и использую Maxscale в качестве прокси. Я настроил тренировочную конфигурацию на некоторых локальных KVM-машинах, работал без сбоев. Итак, я пошел, чтобы развернуть рабочие серверы, и получаю ошибку, которую не понимаю. Если я запустил любую команду в maxctrl
вообще это выдает ту же ошибку:
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL: http://localhost:8989/v1/maxscale/modules/mariadbmon/
Connection to ::1 failed.
The system returned: (99) Cannot assign requested address
The remote host or network may be down. Please try the request again.
Хорошо, похоже, что-то использовало порт 8989
перед Maxscale, давайте проверим с lsof -i -P -n | grep 89
:
maxscale 1117 maxscale 23u IPv4 19765 0t0 TCP 127.0.0.1:8989 (LISTEN)
SELinux настроен на Permissive для тестирования, Firewalld отключен для тестирования.
Кто-то предположил, что это может быть проблема IPv6, поскольку в нем говорится о подключении к :: 1, но я не вижу, какая разница будет между моими тестовыми и профессиональными машинами, поскольку они оба имеют одинаковые настройки адаптера обратной связи по умолчанию в lo
и оба имеют одинаковые псевдонимы в /etc/hosts
Предложения по отладке?
РЕДАКТИРОВАТЬ: Попробовать несколько рекомендаций от markusjm ниже: 1) В журналах ничего не выскакивает на меня, вот все до тех пор, пока слушатель не заявит, что он запущен:
MariaDB MaxScale /var/log/maxscale/maxscale.log Sun Feb 2 21:31:23 2020
----------------------------------------------------------------------------
2020-02-02 21:31:23 notice : syslog logging is enabled.
2020-02-02 21:31:23 notice : maxlog logging is enabled.
2020-02-02 21:31:23 notice : Using up to 3.51GiB of memory for query classifier cache
2020-02-02 21:31:23 notice : Working directory: /var/log/maxscale
2020-02-02 21:31:23 notice : The collection of SQLite memory allocation statistics turned off.
2020-02-02 21:31:23 notice : Threading mode of SQLite set to Multi-thread.
2020-02-02 21:31:23 notice : MariaDB MaxScale 2.4.5 started (Commit: 61b8bbf7f63c38ca9c408674e66f3627a0b2192e)
2020-02-02 21:31:23 notice : MaxScale is running in process 8036
2020-02-02 21:31:23 notice : Configuration file: /etc/maxscale.cnf
2020-02-02 21:31:23 notice : Log directory: /var/log/maxscale
2020-02-02 21:31:23 notice : Data directory: /var/lib/maxscale
2020-02-02 21:31:23 notice : Module directory: /usr/lib64/maxscale
2020-02-02 21:31:23 notice : Service cache: /var/cache/maxscale
2020-02-02 21:31:23 notice : Worker message queue size: 1.00MiB
2020-02-02 21:31:23 notice : No query classifier specified, using default 'qc_sqlite'.
2020-02-02 21:31:23 notice : Loaded module qc_sqlite: V1.0.0 from /usr/lib64/maxscale/libqc_sqlite.so
2020-02-02 21:31:23 notice : Query classification results are cached and reused. Memory used per thread: 449.02MiB
2020-02-02 21:31:23 notice : The systemd watchdog is Enabled. Internal timeout = 30s
2020-02-02 21:31:23 notice : Loading /etc/maxscale.cnf.
2020-02-02 21:31:23 notice : /etc/maxscale.cnf.d does not exist, not reading.
2020-02-02 21:31:23 notice : Loaded module MariaDBClient: V1.1.0 from /usr/lib64/maxscale/libmariadbclient.so
2020-02-02 21:31:23 notice : [readwritesplit] Initializing statement-based read/write split router module.
2020-02-02 21:31:23 notice : Loaded module readwritesplit: V1.1.0 from /usr/lib64/maxscale/libreadwritesplit.so
2020-02-02 21:31:23 notice : [readconnroute] Initialise readconnroute router module.
2020-02-02 21:31:23 notice : Loaded module readconnroute: V2.0.0 from /usr/lib64/maxscale/libreadconnroute.so
2020-02-02 21:31:23 notice : [mariadbmon] Initialise the MariaDB Monitor module.
2020-02-02 21:31:23 notice : Loaded module mariadbmon: V1.5.0 from /usr/lib64/maxscale/libmariadbmon.so
2020-02-02 21:31:23 notice : Loaded module MariaDBBackend: V2.0.0 from /usr/lib64/maxscale/libmariadbbackend.so
2020-02-02 21:31:23 notice : Loaded module mariadbbackendauth: V1.0.0 from /usr/lib64/maxscale/libmariadbbackendauth.so
2020-02-02 21:31:23 notice : Using encrypted passwords. Encryption key: '/var/lib/maxscale/.secrets'.
2020-02-02 21:31:23 notice : Loaded module mariadbauth: V1.1.0 from /usr/lib64/maxscale/libmariadbauth.so
2020-02-02 21:31:23 notice : Started REST API on [127.0.0.1]:8989
2020-02-02 21:31:23 notice : MaxScale started with 8 worker threads, each with a stack size of 8388608 bytes.
2020-02-02 21:31:23 notice : Starting a total of 2 services...
2020-02-02 21:31:23 notice : Server 'server1' version: 10.3.21-MariaDB-log
2020-02-02 21:31:23 notice : Server 'server2' version: 10.3.21-MariaDB-log
2) curl localhost:8989/v1/maxscale
возвращает код ошибки 99, как указано выше. Если я сделаю curl 127.0.0.1:8989/v1/maxscale
он возвращает другую ошибку 111.
<blockquote id="error">
<p><b>Connection to 127.0.0.1 failed.</b></p>
</blockquote>
<p id="sysmsg">The system returned: <i>(111) Connection refused</i></p>
3) tcpdump показывает, что абсолютно ничего не происходит по сети, что действительно странно. Я попытался tcpdump -v -i ens192 'port 8989'
и tcpdump -v -i lo 'port 8989'
а затем оба метода curl, как указано выше, и получите тот же результат:
tcpdump: listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
MaxCtrl использует MaxScale REST API выполнять команды. В большинстве случаев ошибка 99 появляется на стороне клиента, когда система не может создать больше сокетов TCP. Этот тип ошибки должен быть временным, поэтому со временем он должен исчезнуть. Проверка количества сокетов TCP и их состояния должна показать, так ли это.
Обычные шаги отладки Maxscale REST API:
/var/log/maxscale/maxscale.log
и убедитесь, что он начал успешно прослушивать правильный порт.curl localhost:8989/v1/maxscale
tcpdump -v -i lo 'port 8989'
и осмотрите его на предмет подсказок Если ни один из этих шагов не решит проблему, вы всегда можете открыть отчет об ошибке на MariaDB Jira в рамках проекта MaxScale.
Моя система была настроена на использование прокси-сервера HTTP, и прокси-сервер не разрешал соединение через порт 8989.
В /etc/environment
Я имел:
http_proxy=http://<lan_ip>:3128
https_proxy=http://<lan_ip:3128
Когда я удалил их, закрыл сеанс SSH и вернулся с такими командами, как maxctrl list servers
в настоящее время работают. Придется работать над разрешением вокруг прокси.