☰

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는 테스트를 위해 허용으로 설정되고, Firewalld는 테스트를 위해 꺼져 있습니다.

lo누군가 ::1에 대한 연결이라고 표시되어 있기 때문에 IPv6 문제일 수 있다고 제안했지만 테스트 컴퓨터와 프로 컴퓨터 모두 동일한 기본 루프백 어댑터 설정이 있고 둘 다 동일한 별칭을 갖기 때문에 차이점이 무엇인지 알 수 없습니다. ~에/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'동일한 결과를 얻었습니다.

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명령을 실행합니다. 대부분의 경우 오류 99는 시스템이 더 많은 TCP 소켓을 생성할 수 없을 때 클라이언트 측에 나타납니다. 이러한 유형의 오류는 일시적이어야 하므로 시간이 지나면 해결되어야 합니다. 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 serversnow work와 같은 명령으로 다시 돌아왔습니다. 프록시 주변의 해결 방법을 연구해야 합니다.

관련 정보