☰

MariaDB Maxctrl reagiert nicht unter CentOS 7

tag-icon • tag-icon networking centos mariadb
MariaDB Maxctrl reagiert nicht unter CentOS 7

Ich arbeite daran, einen MariaDB 3-Knoten-Cluster einzurichten und Maxscale als Proxy zu verwenden. Ich hatte eine Übungskonfiguration auf einigen lokalen KVM-Maschinen eingerichtet, die problemlos funktionierte. Also wollte ich die Produktionsserver hochfahren und bekomme einen Fehler, den ich nicht verstehen kann. Wenn ich überhaupt einen Befehl ausführe, maxctrlwird der gleiche Fehler ausgegeben:

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.

Ok, es klingt, als ob 8989vor Maxscale etwas den Port verwendet hat. Überprüfen wir das mit lsof -i -P -n | grep 89:

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

SELinux ist zum Testen auf Permissive eingestellt, Firewalld ist zum Testen deaktiviert.

Jemand meinte, es könnte ein IPv6-Problem sein, da dort eine Verbindung zu ::1 angezeigt wird, aber ich kann den Unterschied zwischen meinen Test- und Pro-Rechnern nicht erkennen, da beide die gleichen Standardeinstellungen für den Loopback-Adapter haben lound beide die gleichen Aliase haben in/etc/hosts

Vorschläge zur Fehlerbehebung?

BEARBEITEN: Ich probiere einige der Empfehlungen von markusjm unten aus: 1) In den Protokollen fällt mir nichts auf, hier ist alles bis zu dem Punkt, an dem der Listener angibt, gestartet zu sein:

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/maxscalegibt den Fehlercode 99 wie oben zurück. Wenn ich curl 127.0.0.1:8989/v1/maxscaledas mache, wird ein anderer Fehlercode 111 zurückgegeben.

<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 zeigt, dass absolut nichts über die Leitung kommt, was wirklich seltsam ist. Ich habe es mit beiden Curl-Methoden wie oben versucht tcpdump -v -i ens192 'port 8989'und tcpdump -v -i lo 'port 8989'das gleiche Ergebnis erhalten:

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

Antwort1

MaxCtrl verwendet dieMaxScale REST APIBefehle auszuführen. In den meisten Fällen tritt Fehler 99 auf der Clientseite auf, wenn das System nicht in der Lage ist, weitere TCP-Sockets zu erstellen. Dieser Fehlertyp sollte vorübergehend sein und sich mit der Zeit bessern. Die Überprüfung der Anzahl der TCP-Sockets und ihres Status sollte Aufschluss darüber geben, ob dies der Fall ist.

Die üblichen Debugging-Schritte für die Maxscale REST-API sind:

  • Überprüfen Sie die MaxScale-Fehlerprotokolle unter /var/log/maxscale/maxscale.logund vergewissern Sie sich, dass das Abhören auf dem richtigen Port erfolgreich gestartet wurde.
  • Testen Sie, ob HTTP-Verbindungen funktionieren, indem Sie einen anderen Client verwenden, z. B.curl localhost:8989/v1/maxscale
  • Erfassen Sie den Netzwerkverkehr tcpdump -v -i lo 'port 8989'und untersuchen Sie ihn auf Hinweise

Wenn keiner dieser Schritte das Problem löst, können Sie jederzeit einen Fehlerbericht auf derMariaDB Jira im Rahmen des MaxScale-Projekts.

Antwort2

Mein System war für die Verwendung eines HTTP-Proxys eingerichtet, und der Proxy ließ die Verbindung über Port 8989 nicht zu.

Ich /etc/environmenthatte:

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

Als ich diese entfernte, die SSH-Sitzung schloss und zurückkam, maxctrl list serversfunktionierten Befehle wie „Jetzt“. Ich muss an einer Lösung für den Proxy arbeiten.

verwandte Informationen