У меня проблема, аналогичная упомянутой здесь: xinetd 'сброс соединения одноранговым узлом'
Я установил percona-clustercheck (который поставляется с пакетами Percona XtraDB Cluster) с xinetd, и я получаю сообщение об ошибке при попытке УДАЛЕННО свернуть clustercheck. (Обратите внимание, что он отлично работает локально.)
Вот как это выглядит ЛОКАЛЬНО:
[root@db1 tmp]# for i in {1..1000}; do curl http://db1.ourdomain.local:9200; sleep 2; date; done Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:16 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:18 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:20 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:22 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:24 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:26 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:28 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:30 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:32 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:30:34 EDT 2013
Percona XtraDB Cluster Node is synced.
и УДАЛЕННО:
[root@db2 ~]# for i in {1..1000}; do curl http://db1.ourdomain.local:9200; sleep 2; date; done Percona XtraDB Cluster Node is synced.
Fri May 3 07:32:23 EDT 2013
curl: (56) Failure when receiving data from the peer <----- error
Fri May 3 07:32:25 EDT 2013
curl: (56) Failure when receiving data from the peer <----- error
Fri May 3 07:32:27 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:32:29 EDT 2013
curl: (56) Failure when receiving data from the peer <----- error
Fri May 3 07:32:31 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:32:33 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:32:35 EDT 2013
Percona XtraDB Cluster Node is synced.
Fri May 3 07:32:37 EDT 2013
Решение в предыдущем сообщении заключалось в установке «Content-Length:», но сценарий, который я использую, уже пытается установить длину содержимого:
if [[ "${WSREP_STATUS}" == "4" ]] || [[ "${WSREP_STATUS}" == "2" && ${AVAILABLE_WHEN_DONOR} == 1 ]]
then
# Percona XtraDB Cluster node local state is 'Synced' => return HTTP 200
# Shell return-code is 0
echo -en "HTTP/1.1 200 OK\r\n"
echo -en "Content-Type: text/plain\r\n"
echo -en "Connection: close\r\n"
echo -en "Content-Length: 40\r\n"
echo -en "\r\n"
echo -en "Percona XtraDB Cluster Node is synced.\r\n"
exit 0
else
# Percona XtraDB Cluster node local state is not 'Synced' => return HTTP 503
# Shell return-code is 1
echo -en "HTTP/1.1 503 Service Unavailable\r\n"
echo -en "Content-Type: text/plain\r\n"
echo -en "Connection: close\r\n"
echo -en "Content-Length: 44\r\n"
echo -en "\r\n"
echo -en "Percona XtraDB Cluster Node is not synced.\r\n"
exit 1
fi
Я попытался изменить длину содержимого на ноль, как было рекомендовано. echo -en "Content-Length: 0 \ r \ n" в операторах if и else, но в моем случае это не помогло.
Вот что я вижу, когда запускаю curl в подробном режиме:
Fri May 3 08:34:33 EDT 2013
* About to connect() to db1.ourdomain.local port 9200 (#0)
* Trying 1.2.3.4... connected
* Connected to db1..local (1.2.3.4) port 9200 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: db1.ourdomain.local:9200
> Accept: */*
>
< HTTP/1.1 200 OK
* Closing connection #0
* Failure when receiving data from the peer
curl: (56) Failure when receiving data from the peer
Если я использую curl локально или удаленно по telnet, все работает правильно. Проблема в том, что это просто завиток удаленно. К сожалению, используемый нами аппаратный балансировщик нагрузки требует, чтобы я выполнял проверку http (без telnet).
Как я могу решить эту проблему дальше?
Спасибо! Брэд
РЕДАКТИРОВАТЬ - Добавление содержимого скрипта xinetd:
cat /etc/xinetd.d/mysqlchk
# default: on
# description: mysqlchk
service mysqlchk
{
# this is a config for xinetd, place it in /etc/xinetd.d/
disable = no
flags = REUSE
socket_type = stream
port = 9200
wait = no
user = nobody
server = /usr/bin/clustercheck
log_type = FILE /var/log/xinetdlog
log_on_failure += USERID
only_from = 0.0.0.0/0
# recommended to put the IPs that need
# to connect exclusively (security purposes)
per_source = UNLIMITED
}
Что я заметил в вашем сеансе отладки, так это то, что ваш curl закрывает соединение сразу после того, как получает первую строку ответа. Он не получает заголовок Content-Length и, следовательно, не использует его (поэтому не имеет значения, если вы установите его в 0). У меня это выглядит так:
* About to connect() to vm0010 port 9200 (#0)
* Trying 1.2.3.4... connected
* Connected to vm0010 (1.2.3.4) port 9200 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: vm0010:9200
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Connection: close
< Content-Length: 40
<
Percona XtraDB Cluster Node is synced.
* Closing connection #0
Как ваш xinetd настроен для этого скрипта?
Проблема в том, что этот сценарий проверки отвечает на HAproxy как на единый поток без соблюдения протокола HTTP. Введение сна - это то, что, кажется, работает в моей настройке.
then
# Cluster node state is 'OK' => return HTTP 200
/bin/echo -en "HTTP/1.1 200 OK\r\n"
sleep 0.1
/bin/echo -en "Content-Length: 26\r\n"
sleep 0.1
/bin/echo -en "Content-Type: text/plain\r\n"
sleep 0.1
/bin/echo -en "\r\n"
sleep 0.1
/bin/echo -en "Cluster Node is GOOD.\r\n"
sleep 0.1
/bin/echo -en "\r\n"
exit 0
else
# Cluster node local state is 'BAD' => return HTTP 503
/bin/echo -en "HTTP/1.1 503 Service Unavailable\r\n"
sleep 0.1
/bin/echo -en "Content-Length: 0\r\n"
sleep 0.1
/bin/echo -en "Content-Type: text/plain\r\n"
sleep 0.1
/bin/echo -en "Connection: close\r\n"
sleep 0.1
/bin/echo -en "\r\n"
sleep 0.1
/bin/echo -en "Cluster Node state is BAD.\r\n"
sleep 0.1
/bin/echo -en "\r\n"
sleep 0.1
exit 1