☰

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現在這樣的命令。將必須圍繞代理制定解決方案。

相關內容