☰

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.

わかりました。Maxscale より前に何かがポートを使用していたようです8989。以下を確認しましょうlsof -i -P -n | grep 89:

maxscale 1117 maxscale   23u  IPv4  19765      0t0  TCP 127.0.0.1:8989 (LISTEN)

SELinux はテスト用に Permissive に設定されており、Firewalld はテスト用にオフになっています。

::1への接続と表示されているので、IPv6の問題かもしれないと誰かが示唆しましたが、テストマシンとプロマシンの両方に同じデフォルトのループバックアダプタ設定があり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 は、回線に何も流れていないことを示しています。これは非常に奇妙です。上記の 2 つの curl メソッドを試しましたtcpdump -v -i ens192 'port 8989'がtcpdump -v -i lo 'port 8989'、結果は同じでした。

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はマックススケールRESTAPIコマンドを実行します。ほとんどの場合、システムが 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今度は機能するようになりました。プロキシに関する解決策を検討する必要があります。

関連情報