☰

MariaDB Maxctrl não responde CentOS 7

tag-icon • tag-icon networking centos mariadb
MariaDB Maxctrl não responde CentOS 7

Estou trabalhando na configuração de um cluster MariaDB de 3 nós e usando Maxscale como proxy. Eu configurei uma configuração prática em algumas máquinas KVM locais e trabalhei sem problemas. Então fui ativar os servidores de produção e estou recebendo um erro que não consigo entender. Se eu executar qualquer comando maxctrl, ele gerará o mesmo erro:

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, parece que algo estava usando a porta 8989antes do Maxscale, vamos verificar com lsof -i -P -n | grep 89:

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

SELinux está definido como Permissivo para teste, Firewalld está desativado para teste.

Alguém sugeriu que pode ser um problema de IPv6, pois diz conexão com ::1, mas não consigo ver qual seria a diferença entre minhas máquinas de teste e profissionais, pois ambas têm as mesmas configurações padrão do adaptador de loopback loe ambas têm os mesmos aliases em/etc/hosts

Sugestões para depuração?

EDIT: Experimentando algumas das recomendações do markusjm abaixo: 1) Nada nos logs que me chama a atenção, aqui está tudo até que o ouvinte afirme ter sido iniciado:

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/maxscaleretorna o código de erro 99 conforme acima. Se eu fizer curl 127.0.0.1:8989/v1/maxscaleisso, retornará um erro 111 diferente.

<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 mostra que absolutamente nada está passando pelo fio, o que é realmente estranho. Eu tentei tcpdump -v -i ens192 'port 8989'e tcpdump -v -i lo 'port 8989', em seguida, os dois métodos curl acima e obtive o mesmo resultado:

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

Responder1

MaxCtrl usa oAPI REST MaxScalepara executar comandos. Na maioria das vezes, o erro 99 aparece no lado do cliente quando o sistema é incapaz de criar mais soquetes TCP. Esse tipo de erro deve ser transitório, portanto deve desaparecer com o tempo. A inspeção do número de soquetes TCP e seu estado deve indicar se esse é o caso.

As etapas usuais de depuração da API REST Maxscale são:

  • Verifique os logs de erros do MaxScale em /var/log/maxscale/maxscale.loge verifique se ele começou a escutar com êxito na porta correta.
  • Teste se as conexões HTTP funcionam usando um cliente diferente, por exemplocurl localhost:8989/v1/maxscale
  • Capture o tráfego de rede tcpdump -v -i lo 'port 8989'e inspecione-o em busca de pistas

Se nenhuma dessas etapas resolver o problema, você poderá abrir um relatório de bug noMariaDB Jira no projeto MaxScale.

Responder2

Meu sistema foi configurado para usar um proxy HTTP e o proxy não estava permitindo a conexão na porta 8989.

Em /etc/environmenteu tive:

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

Quando os removi, fechei a sessão SSH e voltei em comandos como maxctrl list serversagora funcionam. Terá que trabalhar em uma resolução em torno do proxy.

informação relacionada