"Мигающий" хост в кластере при запросе к Distributed-табличке (разный count на одной и той же таблице)

[Stepan Semiokhin]

Добрый день!

Столкнулся со странной проблемой, сценарий: 

1) есть несколько ReplicatedMergeTree таблиц на кластере из 6 машин,

2) Подключаюсь к одной из тачек

3) Выполняю подряд несколько раз select count(*) из распределенной таблицы

4) Получаю мигающее значение, т.е. если всего, например, 10 записей, то получаю то 10, то 8 записей.

Выяснил, что выпадает одна из тачек, условно с номером 3: один раз я делаю запрос к распределенной таблице и данные с этой 3-ей тачки передаются, другой раз нет.

Причем, если я подключаюсь к этой третьей тачке - значение уже не мигает и все ок.

Я понимаю, что это история про сеть, одна она в принципе стабильна, может какой таймаут увеличить непосредственно в настройках КХ? Можете подсказать, в какую сторону копать? В логах никаких ошибок странных не нашел.

[Николай Кочетов]

Здравствуйте!

Можно посмотреть в табличку system.replicas. В частности, значение absolute_delay - отставание от лидирующей.
Также в табличке system.replication_queue может быть полезная информация о возможных ошибках.

четверг, 7 сентября 2017 г., 14:37:20 UTC+3 пользователь Stepan Semiokhin написал:

[Stepan Semiokhin]

Добрый вечер, Николай!

Спасибо за ответ.

absolute_delay равен 0, в system.replication_queue ничего. А почему вы решили, что дело в репликах? Ощущение, что такое может произойти и с обычными MergeTree.

Наверное, я немного коряво объяснил: при запросе count(*) в распределенную таблицу у нас же выполняется каунт на всех локальных таблицах и затем результат суммируется на хосте с распределенной таблицей. В моем случае каунт с одного из хостов в кластере то учитывается, то нет, как повезет.

Я ожидал хоть какую-нибудь ошибку в логе, а так получается Distributed-таблица знает, что собрать результаты нужно со всех 6 тачках, с одной их получить не получилось, она забила и пошла дальше (хотя могла бы в реплику там сходить или хотя бы маякнуть, что дело не ок).

Вот и что-то нет идей, что это может быть...

[madm1ke]

У меня было что-то похожее в случае, когда структура Distributed-таблицы и таблиц на шардах немного отличалась - запрос к Distributed и везде локально, кроме одного шарда - давал пустой результат. А к одному шарду - непустой, ожидаемый. После синхронизации структуры все проблемы исчезли. В логах было пусто, глубоко не копал. CH был не апдейчен месяц-полтора.

Возможно, и тут то же самое - на одной реплике одного шарда структура отличается от всех остальных - и когда запрос приходит на нее - возникает ошибка. А на другой реплике - все корректно.

7 сентября 2017 г., 23:33 пользователь Stepan Semiokhin <drs...@gmail.com> написал:

--
You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/b2948dd0-077a-419a-a363-abcb9c98ad46%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[Stepan Semiokhin]

Спасибо, Михаил, Николай!

Действительно, оказалось, что реплика для этого хоста, который мигает, действительно оказалась пустая!

Сейчас буду разбираться, это уже что-то :)

[Stepan Semiokhin]

Николай, действительно, на вот реплике "плохого" оказался absolute_delay огромный, а в ошибках куча всего интересного:

Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer, e.what() = Connection reset by peer

А вот такое в поле postpone_reason:

Not executing log entry for part 20170609_20170627_200_222_2 because another log entry for the same part is being processed. This shouldn't happen often.

и

Not executing log entry for part 20170513_20170528_204_204_0 because another log entry for covering part 20170513_20170528_200_220_2 is being processed.

И еще куча частей на мерж с опять же кучей попыток (видимо, неудачных) сделать мерж

[Stepan Semiokhin]

И в логах, собсно, то же самое:

<Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer, e.what() = Connection reset by peer

Я так понимаю, это максимально общая ошибка типа "что-то про соединение"? Коннект между хостами есть, если что..

[Николай Кочетов]

Можно попробовать найти в логах урлы, по которым происходит ошибка скачивания. Они должны содержать в себе кусок "/?endpoint=DataPartsExchange". Далее попробовать скачать данные по этим адресам руками (через curl, например). Если скачать ничего не получается, то, скорее всего, проблемы с сетью.

Также возможны проблемы в силу того, что в ClickHouse вечный DNS кеш. Для того, чтобы его сбростиь, сейчас необходимо перезапустить сервер clickhouse.

пятница, 8 сентября 2017 г., 0:47:55 UTC+3 пользователь Stepan Semiokhin написал: