Search
Write a publication
Pull to refresh
0
0
Андрей @wite27

Разработчик

Send message

Интересная и полная статья, спасибо. Появилась идея по прогреву локального кэша -- можно, как минимум, добавить распределенный кэш между локальным и источниками; а в максимуме -- по какому-нибудь gossip-like алгоритму распространять данные по локальным кэшам (но про это ничего не нагуглил :)), либо прямо через балансировщик запрашивать данные с уже прогретых (ready) сервисов

Извините, не мог пройти мимо

Консумер

А почему тогда не продусер? :)

Heartbeat отправляются всеми consumer в Kafka, при этом промежуток между двумя heartbeat не должен превышать max.poll.interval.

Здесь как раз не должен превышать именно session.timeout.ms. Про эти две настройки хорошо написано здесь

Решение: мы увеличили max.poll.interval до двух часов и Session timeout до 5 часов

...

Мы решили снизить max.pool.interval, а Session timeout оставить, как есть

Но как раз таки session.timeout.ms не должен быть таким большим. Осталось загадкой, понизили ли вы его до разумных в итоге, или нет :)

А насколько это хорошая идея - периодически запускать pg_repack (например, раз в день во время минимальной нагрузки), учитывая, что между запусками новые данные, получается, все равно будут "в конце"? Кажется, что все равно можно получить профит от этого, т. к. большая часть данных будет распределена по индексу, но я не до конца уверен. Или предполагается другое использование pg_repack?

Причина скорее всего в хранении конфигов именно рядом с исходным кодом, и смешивании конфигов для разных окружений. Можно хранить их в отдельном репозитории, или настроить дополнительные проверки (хуки, ревьюверы) при изменении продового конфига.

А как по этому тегу потом понять, какая версия кода выполняется (какой коммит конкретно был собран)?

Information

Rating
Does not participate
Registered
Activity