кластер из 3 нод. shard1(node1, node2), shard2(node3)
На каждой ноде есть distributed таблица (все настроены одинаково) и шардированные с replicatedMergeTree
Закидываю данные напрямую в шардированную таблицу (к примеру в node2)
Произвожу select в distrbuted таблицу из разных node и получаю следующее:
console_node_1: никогда не возвращаются данные. (может быть отставание по репликации??)
console_node_2: всегда возвращаются данные. (наверное потому что хранятся на этой ноде)
console_node_3: иногда возвращаются данные. (скорее всего потому что распределенный запрос попадает либо на 1, на 2-ую ноду, поэтому данные либо есть, либо нет)
Как можно отследить/исправить подобного рода проблемы?
а где проблема-то? что всегда ходит в реплику на node2 если делать запросы с node2 ? так это специально сделано, чтобы экономить сеть, можно отключить
я ожидаю всегда получать данные со всех nodes ну т.е. созданная вставка должна же засинкаться с node1. А тут почему-то этого не происходит, раз данные недоступны
так у вас 2 шарда. shard1(node1, node2) вы получаете данные с 2х шардов.
разберитесь сначала что репликация работает. Делайте запросы / проверяйте консистетность напрямую в replicatedMergeTree, отложите пока distrbuted
да. верно. Но при SELECT в распределенную таблицу, которая находится на node1 я ведь тоже должен получить результат, хоть изначально данные были записаны в node2? Я понимаю, что клик предпочитает ходить в локальный шард для экономии, но все равно.
отложите пока distrbuted
да. я опытным путем и пришел к тому, что поведение не то, что я ожидаю. Если делать запросы в шардированные таблицы, то на node2 данные есть, а на node1 их нет. Стало быть эти ноды в шарде не засинкались.
Обсуждают сегодня