того файла уже нет, но есть более свежий, с теми же проблемами производительности

Коллеги, добрый день! помогите, пожалуйста, в решением такой вот задачи имеется pgsql 9.6 имеется 2 сетевых интерфейса (внешний и внутренний), в данный момент в /etc/postgresql/9.6/main/postgresql.conf listen_addresses = '10.10.10.2’ те разрешено для внутренней сети появилась необходимость додавить в listen_addresses внешнюю сеть в документации правильного синтаксиса для 2-х и более адресов не нашел пробовал через запятую и пробел - не момогло ставить ‘*’ - очень уж не хочется подскажите, плз, как сделать правильно и как указать в listen_addresses IP адреса 2-х сетевых интерфейсов спасибо

Коллеги, добрый день! помогите, пожалуйста, в решением такой вот задачи имеется pgsql 9.6 имеется 2 сетевых интерфейса (внешний и внутренний), в данный момент в /etc/postgresql/9.6/main/postgresql.conf listen_addresses = '10.10.10.2’ те разрешено для внутренней сети появилась необходимость додавить в listen_addresses внешнюю сеть в документации правильного синтаксиса для 2-х и более адресов не нашел пробовал через запятую и пробел - не момогло ставить ‘*’ - очень уж не хочется подскажите, плз, как сделать правильно и как указать в listen_addresses IP адреса 2-х сетевых интерфейсов спасибо

Всё-таки через запятую

[nikor@hill data]$ grep listen postgresql.conf listen_addresses = '192.168.122.1,127.0.0.1' # what IP address(es) to listen on; [nikor@hill data]$ netstat -an | grep 5432 tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN tcp 0 0 192.168.122.1:5432 0.0.0.0:* LISTEN unix 2 [ ACC ] STREAM LISTENING 74911 /tmp/.s.PGSQL.5432 [nikor@hill data]$

[nikor@hill data]$ grep listen postgresql.conf listen_addresses = '192.168.122.1,127.0.0.1' # what IP address(es) to listen on; [nikor@hill data]$ netstat -an | grep 5432 tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN tcp 0 0 192.168.122.1:5432 0.0.0.0:* LISTEN unix 2 [ ACC ] STREAM LISTENING 74911 /tmp/.s.PGSQL.5432 [nikor@hill data]$

может дело было в пробеле?

может дело было в пробеле?

А с какой диагностикой не получается?

А с какой диагностикой не получается?

у меня был пробел listen_addresses = '192.168.122.1, 127.0.0.1' после этого рестартанул и к pgsql пропала коннекция

у меня был пробел listen_addresses = '192.168.122.1, 127.0.0.1' после этого рестартанул и к pgsql пропала коннекция

Серверный порт с точки зрения клиента доступен?

Серверный порт с точки зрения клиента доступен?

ставил с пробелом, порт 5432 при этом “закрылся”

кстати, на разных адресах разные порты, такое возможно?

Т.е. на сервере порт 5432 сейчас никто не слушает?

Т.е. на сервере порт 5432 сейчас никто не слушает?

поднял в сторонке pgsql, а на проде вернул в зад сейчас потренируюсь)

Т.е. на сервере порт 5432 сейчас никто не слушает?

да, при пробеле - 5432 никто не слушал

да, при пробеле - 5432 никто не слушал

Странно [nikor@hill data]$ netstat -an | grep 5432 tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN tcp 0 0 192.168.122.1:5432 0.0.0.0:* LISTEN unix 2 [ ACC ] STREAM LISTENING 64378 /tmp/.s.PGSQL.5432 [nikor@hill data]$ grep listen postgresql.conf listen_addresses = ' 192.168.122.1, 127.0.0.1 ' # what IP address(es) to listen on; [nikor@hill data]$

на что обращать внимание в выводе?

На наличие DROP, TRUNCATE, ALTER TABLE

привет, ребят кто сталкивался с такой ошибкой при бекапировании? 2018-08-22 15:44:28,976 [35707] barman.backup ERROR: Backup failed copying files. DETAILS: 'ascii' codec can't encode characters in position 15-24: ordinal not in range(128) PostgreSQL 9.6.10 Debian 9.5 Barman 2.4.1

Что-то с кодировкой не то

На наличие DROP, TRUNCATE, ALTER TABLE

Нет, ни одного изменения схемы

большьая часть записей - INSERT_LEAF, мало UPDATE

На наличие DROP, TRUNCATE, ALTER TABLE

Гриша, там же это будет инсертом в каталогог, а не в виде явного DDL

большьая часть записей - INSERT_LEAF, мало UPDATE

там посмотреть в какой датафайл идёт обновление

большьая часть записей - INSERT_LEAF, мало UPDATE

можете прислать ссылку на копипаст выхлопа waldump?

можете прислать ссылку на копипаст выхлопа waldump?

да

Гриша, там же это будет инсертом в каталогог, а не в виде явного DDL

да, тупанул

15MB весит выхлоп

http://176.112.216.132/pglog.txt

http://176.112.216.132/pglog.txt

непохоже на DDL, вроде обычная вставка в данные и индекс

со 100% вероятностью утверждать, конечно, нельзя, любой из этих файлнодов может быть pg_class`ом

в памяти сколько в системе?

total 16G, shared buffers 8G стояли

maintaince_buffers увеличил до 512 MB

-OPC- -OPC- будет жить. Поприветствуем!

со 100% вероятностью утверждать, конечно, нельзя, любой из этих файлнодов может быть pg_class`ом

@tempik, тут я фигню написал, информация о создаваемых/удаляемых файлнодах содержится в COMMIT/ABORT записях, поэтому можно точно сказать, что DDL не было

пока выглядит так, что благодаря оптимизации с сравнением LSN и отсутствию нагрузки на запись в момент бэкапа, накат WAL до точки консистентности вышел дешевым

смущает, конечно, замедление в десятки раз

можно попробовать заюзать https://github.com/joyent/pg_prefaulter

пока выглядит так, что благодаря оптимизации с сравнением LSN и отсутствию нагрузки на запись в момент бэкапа, накат WAL до точки консистентности вышел дешевым

после завершения восстановления сервер так и остается в recovery режиме, нагрузки на запись нет

можно попробовать заюзать https://github.com/joyent/pg_prefaulter

спасибо, посмотрю

после завершения восстановления сервер так и остается в recovery режиме, нагрузки на запись нет

не понял, восстановление - это и есть recovery режим

не понял, восстановление - это и есть recovery режим

имел ввиду - после достижения точки консистентности

а что Вы подразумеваете под нагрузкой на запись? write нагрузка на диски?

наверное стоит обрисовать кейс - я пытаюсь завести standby сервер, непрерывно восстанавливающий wal из архива с целью трансфера продуктивной бд на stage стенд

а что Вы подразумеваете под нагрузкой на запись? write нагрузка на диски?

запросы INSERT/UPDATE

А выполните, пожалуйста, на мастере: select pg_current_wal_flush_lsn(); А на реплике: select pg_last_wal_replay_lsn();

@imozger будет жить. Поприветствуем!

Ребятки добрый день, подскажите плиз у меня есть такая структура JSON поля {model: 10, brand:15}, Как мне выбрать все записи, допустим {model: 10, brand: любое}?

а в select что написано ?

просто у вас уже приходит brend:15

это надо на уровне бд сделать типо select * from my_table

Делаю запрос в Django  в орм

ну можно посмотреть запрос

Мне нужно построить такой запрос {'model': 10, 'brand': 15 or 'brand': 0}

Делаю запрос в Django  в орм

У Орм есть поддержка условий по json?)

У Орм есть поддержка условий по json?)

Да конечно

я просто не знаю как делать в джанго так как работаю на yii2 . но если вы вызываете хранимые процедуры

Ребятки добрый день, подскажите плиз у меня есть такая структура JSON поля {model: 10, brand:15}, Как мне выбрать все записи, допустим {model: 10, brand: любое}?

select model,brand from bla_bla_table where model=10;

если согласно первому

скиньте код орм

я так понимаю это как AR в phpp

Народ, есть вопрос. Мы ходим перенести мастер-базу в другое место, но сохранить возможность обращаться к ней по старому адресу. Для постгреса есть прокси или типа того? Что-нибудь легковесное.

хм, может просто использовать ssh туннель?

No Name будет жить. Поприветствуем!

Народ, есть вопрос. Мы ходим перенести мастер-базу в другое место, но сохранить возможность обращаться к ней по старому адресу. Для постгреса есть прокси или типа того? Что-нибудь легковесное.

Haproxy, nginx tcp stream

Ну или pgbouncer, но он авторизацию портит

Ну или pgbouncer, но он авторизацию портит

мне указали на pgpool, есть мнение по этой штуке?

мне указали на pgpool, есть мнение по этой штуке?

Для данной задачи большой оверхед

Для данной задачи большой оверхед

Вот как. Есть более развёрнутый вариант?

Оно лезет в протокол как pgbouncer, но ещё не слишком устойчивый, по моему мнению

Ну или pgbouncer, но он авторизацию портит

я так понял, что pgbouncer сам ходит со своим логином в БД? В смысле клиентские логин и пароль не пробрасываются

я так понял, что pgbouncer сам ходит со своим логином в БД? В смысле клиентские логин и пароль не пробрасываются

Да, клиент логинится на pgbouncer а не на базе

Да, клиент логинится на pgbouncer а не на базе

то есть, придётся в pgbouncer заводить пару логин-пароль для клиентского подключения, но СУБД будет принимать логин-пароль, которые укажешь в pgbouncer для обращения к БД

нда, такая себе конструкция