☰

MariaDB Maxctrl не отвечает CentOS 7

tag-icon • tag-icon networking centos mariadb
MariaDB Maxctrl не отвечает CentOS 7

Я работаю над настройкой кластера MariaDB 3 Node и использую 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 установлен на разрешительный режим для тестирования, Firewalld отключен для тестирования.

Кто-то предположил, что это может быть проблема IPv6, поскольку там указано подключение к ::1, но я не вижу, в чем разница между моими тестовыми и профессиональными машинами, поскольку у них обоих одинаковые настройки адаптера обратной связи по умолчанию loи у обоих одинаковые псевдонимы в/etc/hosts

Предложения по отладке?

EDIT: Пробую несколько рекомендаций от 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

решение1

MaxCtrl используетAPI REST MaxScaleдля выполнения команд. Чаще всего ошибка 99 появляется на стороне клиента, когда система не может создать больше TCP-сокетов. Этот тип ошибки должен быть временным, поэтому он должен исчезнуть со временем. Проверка количества TCP-сокетов и их состояния должна показать, так ли это.

Обычные шаги отладки API REST Maxscale:

  • Проверьте журналы ошибок MaxScale /var/log/maxscale/maxscale.logи убедитесь, что он успешно начал прослушивание на правильном порту.
  • Проверьте работу HTTP-соединений, используя другой клиент, напримерcurl localhost:8989/v1/maxscale
  • Захватите сетевой трафик tcpdump -v -i lo 'port 8989'и проверьте его на наличие каких-либо улик.

Если ни один из этих шагов не решит проблему, вы всегда можете открыть отчет об ошибке наMariaDB Jira в проекте MaxScale.

решение2

Моя система была настроена на использование HTTP-прокси, но прокси не разрешал соединение через порт 8989.

У /etc/environmentменя было:

http_proxy=http://<lan_ip>:3128
https_proxy=http://<lan_ip:3128

Когда я удалил их, закрыл сеанс SSH и вернулся в командах, как maxctrl list serversсейчас работает. Придется поработать над решением вокруг прокси.

Связанный контент