Size: a a a

pgsql – PostgreSQL

2020 July 16

YB

Yelena Bunina in pgsql – PostgreSQL
Victor Yegorov
хм, зачем заново? если ей позволено отставать на, скажем, 6 часов, то WAL-ы всё время текут, просто не применяются.
не. нельзя на 6 часов
источник

YB

Yelena Bunina in pgsql – PostgreSQL
это уже сильно старые данные
источник

A

Alexander in pgsql – PostgreSQL
Почему 6 часов?  реплика чтоль тоже в том же облаке?
источник

YB

Yelena Bunina in pgsql – PostgreSQL
если есть примеры настройки репликации для аналитических запросов отстающей не более часа от мастера - была бы признательна посмотреть
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alexander
ну тут to /dev/null и binary(т.е. без преобразования, или я не правильно понимаю)?
» binary format, кстати — это тоже преобразование, не просто вывод "как есть"
;)
Ну и т.п., см. выше.
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Yelena Bunina
не. нельзя на 6 часов
а сколько занимает по времени OLAP запрос?
источник

A

Alexander in pgsql – PostgreSQL
Yaroslav Schekin
» binary format, кстати — это тоже преобразование, не просто вывод "как есть"
;)
Ну и т.п., см. выше.
упс, не
внимателен
источник

VY

Victor Yegorov in pgsql – PostgreSQL
если запрос занимает 1 час, то к концу выполнения он видит данные часовой “несвежести”. это допустимо?
источник

YB

Yelena Bunina in pgsql – PostgreSQL
Victor Yegorov
если запрос занимает 1 час, то к концу выполнения он видит данные часовой “несвежести”. это допустимо?
сейчас на текущей базе те запросы которые хотим вынести в BQ работают 5 часов. и да, это неприемлемо и деелать то же самое на реплике - не вариант
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Yelena Bunina
не. нельзя на 6 часов
Уезжайте с вашего виртуального сервера. И запросы будут намного быстрее выполняться и реплика не будет сильно отставать.
источник

YB

Yelena Bunina in pgsql – PostgreSQL
я поняла что вы советуете
источник

YB

Yelena Bunina in pgsql – PostgreSQL
ток мы до макс iops не дошли. то есть непонятно во что упираемся
источник

2_

2flower _ in pgsql – PostgreSQL
Yelena Bunina
сейчас на текущей базе те запросы которые хотим вынести в BQ работают 5 часов. и да, это неприемлемо и деелать то же самое на реплике - не вариант
c трудом представляю что можно переваривать 5 часов на современном железе без возможности разбивки на подзадания.
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Yelena Bunina
ток мы до макс iops не дошли. то есть непонятно во что упираемся
не одними iops меряется производительность. вам провайдер может обещать 15000 IOPS для async записи, а вам нужна синхронная. Или вообще обещать 15000 для чтения.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Yelena Bunina
ток мы до макс iops не дошли. то есть непонятно во что упираемся
А как Вы это установили? Может, это как раз и есть реальные максимальные IOPS, которые там дают?
Т.е. неплохо было бы сам этот диск протестировать на чтение, когда нагрузки нет — выдаёт он вообще обещанное или нет?
источник

YB

Yelena Bunina in pgsql – PostgreSQL
^
источник

YB

Yelena Bunina in pgsql – PostgreSQL
на нем не бывает что нет нагрузки. можно такой же заказать и там тестить. но это же явно не одно и то же будет
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Yelena Bunina
я поняла что вы советуете
представьте что ваш запрос будет отрабатываться за 5-10 минут. Разве предложение по переезду на бареметал не стоит этого?
источник

YB

Yelena Bunina in pgsql – PostgreSQL
Сергей Голод
представьте что ваш запрос будет отрабатываться за 5-10 минут. Разве предложение по переезду на бареметал не стоит этого?
стоит. рассмотрим этот вариант
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Yelena Bunina
на нем не бывает что нет нагрузки. можно такой же заказать и там тестить. но это же явно не одно и то же будет
Ну хорошо, ведь просто можно [очень] кратковременно устроить там пик чтения (хоть с помощью dd).
Выдаст он то, что должен, или нет?
источник