Телеграмм чат группы pgsql страница 10179

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pgsql – PostgreSQL

4680 membersпожаловаться на группу

2020 June 26

МШ

Михаил Шурутов... in pgsql – PostgreSQL

Дмитрий Лукьянов

Народ, подскажите, в чём может быть проблема? Визуально стендбай актуален, гэп небольшой.

2020-06-26 13:44:55.383 MSK [28931] FATAL:  terminating connection due to conflict with recovery
2020-06-26 13:44:55.383 MSK [28931] DETAIL:  User query might have needed to see row versions that must be removed.
2020-06-26 13:44:55.383 MSK [28931] HINT:  In a moment you should be able to reconnect to the database and repeat your command.

Я уже увеличил следующие параметры с 30s до 90s, но эффекта нет.

2020-06-26 13:42:11.312 MSK [28618] LOG:  parameter "max_standby_archive_delay" changed to "90s"
2020-06-26 13:42:11.312 MSK [28618] LOG:  parameter "max_standby_streaming_delay" changed to "90s"

hot_standby_feedback - выставить в ON. Но надо помниить, что длинные запросы ведут к распуханию.

источник

13:55пожаловаться #1

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL

Михаил Шурутов

hot_standby_feedback - выставить в ON. Но надо помниить, что длинные запросы ведут к распуханию.

Хммм... Чёт хзхз... Тоже мутная тема... 🤔

источник

13:59пожаловаться #2

MM

Maksim Milyutin in pgsql – PostgreSQL

Дмитрий Лукьянов

Хммм... Чёт хзхз... Тоже мутная тема... 🤔

тогда проставляйте max_standby_streaming_delay в длительность деадлайна запросов в реплику

источник

14:05пожаловаться #3

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL

Maksim Milyutin

тогда проставляйте max_standby_streaming_delay в длительность деадлайна запросов в реплику

Я правильно понимаю, что этот параметр не влияет на сам накат (данные будут актуальны), а лишь на время жизни старых версий строк? Или нет?

источник

14:08пожаловаться #4

LC

Lexa Core in pgsql – PostgreSQL

Помогите решить данную проблему.

В конфиге postgresql.conf прописал : 
# Активация режима журналирования, для снятия горячих копий
wal_level = archive

# Количество хранящихся в директории "pg_xlog" файлов журнала WAL, ротируемых по мере появления свежих данных
wal_keep_segments = 32

# Ограничиваем число обслуживаемых соединений передачи данных в режиме "репликации"
max_wal_senders = 2

В конфиге  pg_hba.conf прописал : 
# Replication connections login by host trust
local   replication  postgres           peer

после чего рестартнул постгрес, он норм взлетел, но бэкапы не бэкапят по прежнему :(

источник

14:09пожаловаться #5

S

Semyon in pgsql – PostgreSQL

Коллеги, а есть чатик по питону для аналитиков (нампи, пандас)?

источник

14:12пожаловаться #6

YS

Yaroslav Schekin in pgsql – PostgreSQL

Дмитрий Лукьянов

Народ, подскажите, в чём может быть проблема? Визуально стендбай актуален, гэп небольшой.

2020-06-26 13:44:55.383 MSK [28931] FATAL:  terminating connection due to conflict with recovery
2020-06-26 13:44:55.383 MSK [28931] DETAIL:  User query might have needed to see row versions that must be removed.
2020-06-26 13:44:55.383 MSK [28931] HINT:  In a moment you should be able to reconnect to the database and repeat your command.

Я уже увеличил следующие параметры с 30s до 90s, но эффекта нет.

2020-06-26 13:42:11.312 MSK [28618] LOG:  parameter "max_standby_archive_delay" changed to "90s"
2020-06-26 13:42:11.312 MSK [28618] LOG:  parameter "max_standby_streaming_delay" changed to "90s"

А прерываемые запросы как долго выполняются, в среднем?

источник

14:15пожаловаться #7

MM

Maksim Milyutin in pgsql – PostgreSQL

Дмитрий Лукьянов

Я правильно понимаю, что этот параметр не влияет на сам накат (данные будут актуальны), а лишь на время жизни старых версий строк? Или нет?

на актуальность как раз и влияет, мы даём право реплике быть более устаревшей

источник

14:15пожаловаться #8

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL

Yaroslav Schekin

А прерываемые запросы как долго выполняются, в среднем?

В лог не пишется тайминг.. где глянуть? В pg_stat_statements?

источник

14:17пожаловаться #9

EA

Erlan A in pgsql – PostgreSQL

в ручную выполните

источник

14:20пожаловаться #10

YS

Yaroslav Schekin in pgsql – PostgreSQL

Дмитрий Лукьянов

В лог не пишется тайминг.. где глянуть? В pg_stat_statements?

Пишется, если включить (см. log_min_duration_statement, log_statement).
Ну или так.

> Хммм... Чёт хзхз... Тоже мутная тема... 🤔

Перенаправление readers на реплику, особенно асинхронную — "мутная тема" сама по себе (это подходит, когда актуальность и консистентность данных не очень важны). ;)

источник

14:20пожаловаться #11

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL

Yaroslav Schekin

Пишется, если включить (см. log_min_duration_statement, log_statement).
Ну или так.

> Хммм... Чёт хзхз... Тоже мутная тема... 🤔

Перенаправление readers на реплику, особенно асинхронную — "мутная тема" сама по себе (это подходит, когда актуальность и консистентность данных не очень важны). ;)

Ну, не важны в пределах пары минут. Если там будет отставание на десятки минут, то уже критично :)

источник

14:21пожаловаться #12

AZ

Aleksey Zhdanov in pgsql – PostgreSQL

/help@JohnRoebot

источник

15:01пожаловаться #13

MM

Max Mokryi in pgsql – PostgreSQL

Yaroslav Schekin

Ну а что ж поделаешь — слишком старая версия (сколько лет она уже не поддерживается?).

только что проверил работу pg_dump -> pg_restore
Уложился за 11 минут... До этого были тесты - 45 минут.... Дело в принимающей стороне... Железка со 128G RAM b NVMe показала себя хорошо.... Думаю, что 11 минут простоя смогу себе позволить

источник

15:01пожаловаться #14

YS

Yaroslav Schekin in pgsql – PostgreSQL

только что проверил работу pg_dump -> pg_restore
Уложился за 11 минут... До этого были тесты - 45 минут.... Дело в принимающей стороне... Железка со 128G RAM b NVMe показала себя хорошо.... Думаю, что 11 минут простоя смогу себе позволить

Так если Вам на самом деле был нужен upgrade, а не репликация, почему было на pg_upgrade сразу не посмотреть?

источник

15:05пожаловаться #15

MM

Max Mokryi in pgsql – PostgreSQL

Yaroslav Schekin

Так если Вам на самом деле был нужен upgrade, а не репликация, почему было на pg_upgrade сразу не посмотреть?

база на девятке с collation=C

источник

15:06пожаловаться #16

YS

Yaroslav Schekin in pgsql – PostgreSQL

база на девятке с collation=C

Ну и была бы на новой версии с collation=C... в чём проблема? ;)

источник

15:06пожаловаться #17

MM

Max Mokryi in pgsql – PostgreSQL

при pg_upgrade ругается, что на принимающей стороне база postgres с collation UTF-8. А при collation=C есть проблема с сортировкой кириллицы и ее поиском по ilike

источник

15:07пожаловаться #18

М

Максим in pgsql – PostgreSQL

Народ, обарбатываю большой массив данных, пуляю по 1му в БД
Каждую секунду импортируется 5 записей.
Этот лимит как-то можно увеличить?

источник

15:08пожаловаться #19

MM

Max Mokryi in pgsql – PostgreSQL

Народ, обарбатываю большой массив данных, пуляю по 1му в БД
Каждую секунду импортируется 5 записей.
Этот лимит как-то можно увеличить?

а можно подробнее? По одному чему?

источник

15:09пожаловаться #20