☰

MariaDB Maxctrl no responde CentOS 7

tag-icon • tag-icon networking centos mariadb
MariaDB Maxctrl no responde CentOS 7

Estoy trabajando en la configuración de un clúster de nodos MariaDB de 3 y usando Maxscale como proxy. Había configurado una configuración de práctica en algunas máquinas KVM locales y funcionó sin problemas. Así que fui a activar los servidores de producción y aparece un error al que no puedo entender. Si ejecuto algún comando, maxctrlarroja el mismo error:

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 estaba usando el puerto 8989antes de Maxscale, verifiquemos con lsof -i -P -n | grep 89:

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

SELinux está configurado en Permisivo para pruebas, Firewalld está desactivado para pruebas.

Alguien sugirió que podría ser un problema de IPv6 ya que dice conexión a ::1 pero no veo cuál sería la diferencia entre mis máquinas de prueba y profesionales, ya que ambas tienen la misma configuración predeterminada del adaptador de loopback loy ambas tienen los mismos alias. en/etc/hosts

¿Sugerencias para la depuración?

EDITAR: Probar algunas de las recomendaciones de markusjm a continuación: 1) No hay nada en los registros que me llame la atención, aquí está todo hasta que el oyente afirma haber 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/maxscaledevuelve el código de error 99 como se indica arriba. Si lo hago curl 127.0.0.1:8989/v1/maxscale, devuelve un error 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 muestra que no pasa absolutamente nada por el cable, lo cual es realmente extraño. Probé tcpdump -v -i ens192 'port 8989'y tcpdump -v -i lo 'port 8989'luego ambos métodos curl como se indica arriba y obtuve el mismo 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

Respuesta1

MaxCtrl utiliza elAPI REST MaxScalepara ejecutar comandos. La mayoría de las veces, el error 99 aparece en el lado del cliente cuando el sistema no puede crear más sockets TCP. Este tipo de error debe ser transitorio, por lo que debería desaparecer con el tiempo. La inspección del número de sockets TCP y su estado debería indicar si este es el caso.

Los pasos habituales de depuración de la API REST de Maxscale son:

  • Verifique los registros de errores de MaxScale en /var/log/maxscale/maxscale.logy verifique que haya comenzado a escuchar correctamente en el puerto correcto.
  • Pruebe que las conexiones HTTP funcionan utilizando un cliente diferente, por ejemplocurl localhost:8989/v1/maxscale
  • Capture el tráfico de la red tcpdump -v -i lo 'port 8989'e inspecciónelo en busca de pistas.

Si ninguno de estos pasos resuelve el problema, siempre puede abrir un informe de error en elMariaDB Jira bajo el proyecto MaxScale.

Respuesta2

Mi sistema estaba configurado para usar un proxy HTTP y el proxy no permitía la conexión en el puerto 8989.

En /etc/environmenttuve:

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

Cuando los eliminé, cerré la sesión SSH y volví a maxctrl list serversusar comandos como ahora. Tendremos que trabajar en una resolución en torno al proxy.

información relacionada