☰

MariaDB Maxctrl 没有响应 CentOS 7

tag-icon • tag-icon networking centos mariadb
MariaDB Maxctrl 没有响应 CentOS 7

我正在设置 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

答案1

MaxCtrl 使用MaxScale REST API执行命令。大多数情况下，当系统无法创建更多 TCP 套接字时，客户端会出现错误 99。这种类型的错误应该是暂时的，因此应该会随着时间的推移而消失。检查 TCP 套接字的数量及其状态应该可以指示是否是这种情况。

通常的Maxscale REST API调试步骤是：

  • 检查 MaxScale 错误日志/var/log/maxscale/maxscale.log并验证它是否已成功开始在正确的端口上监听。
  • 使用不同的客户端测试 HTTP 连接是否正常工作，例如curl localhost:8989/v1/maxscale
  • 捕获网络流量tcpdump -v -i lo 'port 8989'并检查是否有任何线索

如果上述步骤均无法解决问题，您可以随时在MaxScale项目下的MariaDB Jira。

答案2

我的系统设置为使用 HTTP 代理，但代理不允许端口 8989 上的连接。

我/etc/environment有：

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

当我删除这些后，关闭 SSH 会话，然后返回命令，如maxctrl list servers现在工作。必须围绕代理进行解决方案。

相关内容