стоит отдельно и состоит из 3 серверов.
на одной из реплик кх ночью отвалилась сессия с zk -
last_queue_update_exception: Code: 999. Coordination::Exception: Session expired (Session expired). (KEEPER_EXCEPTION) (version 22.1.3.7 (official build))
лог с zk -
2022-07-11 22:54:03,374 [myid:2] - INFO [SessionTracker:ZooKeeperServer@398] - Expiring session 0x300000016650005, timeout of 30000ms exceeded
2022-07-11 22:54:03,374 [myid:2] - INFO [SessionTracker:QuorumZooKeeperServer@157] - Submitting global closeSession request for session 0x300000016650005
дальше сделал на ноде кх рестарт реплики таблицы (движок таблицы - ReplicatedCollapsingMergeTree) -
system restart replica database.table;
и вот уже 6 с половиной часов этот запрос выполняется, в system.replication_queue есть 12 строк с
type: MERGE_PARTS
которые не меняются все 6 часов.
по запросу
SELECT
database,
table,
type,
max(last_exception),
max(postpone_reason),
min(create_time),
max(last_attempt_time),
max(last_postpone_time),
max(num_postponed) AS max_postponed,
max(num_tries) AS max_tries,
min(num_tries) AS min_tries,
countIf(last_exception != '') AS count_err,
countIf(num_postponed > 0) AS count_postponed,
countIf(is_currently_executing) AS count_executing,
count() AS count_all
FROM system.replication_queue
GROUP BY
database,
table,
type
ORDER BY count_all DESC
FORMAT Vertical
ответ такой -
Row 1:
──────
database: database
table: table
type: MERGE_PARTS
max(last_exception):
max(postpone_reason):
min(create_time): 2022-03-25 11:50:15
max(last_attempt_time): 2022-06-13 17:53:20
max(last_postpone_time): 1970-01-01 03:00:00
max_postponed: 0
max_tries: 1
min_tries: 1
count_err: 0
count_postponed: 0
count_executing: 12
count_all: 12
мне дальше ждать или предпринимать какие-то действия?
а progress меняется ? select * from system.merges
я бы перезрузил КХ и я бы обновился до 22.3.8
зафиксировал текущие значения progress , проверю через несколько минут
перезагрузка на всех нодах? эта очередь в replication_queue на всех трёх одинаковая
select * from system.replication_queue
12 строк такого вида - database: database table: table replica_name: node1 position: 11 node_name: queue-0027499653 type: MERGE_PARTS create_time: 2022-06-13 17:53:20 required_quorum: 0 source_replica: node3 new_part_name: 202112_0_420933_299_530665 parts_to_merge: ['202112_0_38524_157_530665','202112_38525_141124_203_530665','202112_141125_200161_179_530665','202112_200162_420933_298_530665'] is_detach: 0 is_currently_executing: 1 num_tries: 1 last_exception: last_attempt_time: 2022-06-13 17:53:20 num_postponed: 0 postpone_reason: last_postpone_time: 1970-01-01 03:00:00 merge_type: REGULAR
прошло 25 минут, progress не изменился ни у кого
спасибо, пойду пробовать
помогло, реплика теперь в строю, но в system.merges остались те же записи, с теми же progress. Но видно что у таблицы ещё много дел для репликации - queue_size: 77 inserts_in_queue: 65 merges_in_queue: 12
https://pastila.nl/ надо со всех серверов merges и replication_queueu --> format Vertical
https://pastila.nl/?025630eb/c2017e34405727c22ee74597050be96f
т.е. мержи висят на 100% и не могут завершиться, грепайте лог КХ, я не видел/не понмю такого, скорее всего там ошибки про зукипер
спасибо, после нескольких рестартов очередь пришла в прошлое состояние и реплика стала актуальной по данным. а те мержи, которые не могут завершиться, видимо, были ещё до поломки с зк
Обсуждают сегодня