Должны по идее

После расширения диска и отключения свапа постгресс select count(*) на путсую таблицу выполняет минуту. В какую сторону смотреть*?

Из таблицы точно не удалялось много данных и не делалось много апдейтов?

Размер то какой?

В байтах

Из таблицы точно не удалялось много данных и не делалось много апдейтов?

Удалялось 20 гигабайт

Ну смотри в сторону вакуума фул

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

И почитай про pg mvcc

Чтоб понимать как это работает

на пустой таблице то mvcc ?

Спс

на пустой таблице то mvcc ?

Не знаю что это такое, буду читать

Не знаю что это такое, буду читать

просто версионность

на пустой таблице то mvcc ?

Не понял вопроса

на пустой таблице то mvcc ?

она не совсем пустая, если ее не вакуумировали

Доброво всем дня. Хочу улучшить текущее обслуживание БД. На данный момент имеется скрипт ВАКУУМА который старутет ежедневно в час ночи. Выглядит так: /vacuumdb -a -z -v -U postgres. Что как я считаю не правильно в это же время на всех БД работает КРОН и создается много записей в базах. Самый последний крон заканчивает работу в раене 5 утра. Моя мысль перенести этот ВАКУУМ на 5 утра чтобы обслуживание БД шло после всех операций по вставке и удалению данных кроном. Также на данный момент не выполняется VACUUM FULL. Правильно ли я понимаю что по хорошему нужно его раз в неделю запускать в часы когда нету никакой активности? Как я представляю его вынести на выходные дни после ночного крона. Правильно ли я рассуждаю и на сколько необходим VACUUM FULL?

она не совсем пустая, если ее не вакуумировали

ну да, просто хреновато как-то это, но за все конечно надо платить

Подскажите как правильно (в смысле последовательности выполняемх команд) под Linux Ubuntu 16.04 выполнить обновление с 9.6.2.1 на 9.6.3.1 PostgresPro ?

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

Трункейт помог

Да точно. Про него забыл

Большое спасибо. Сам бы неделю искал в чем проблема

Доброво всем дня. Хочу улучшить текущее обслуживание БД. На данный момент имеется скрипт ВАКУУМА который старутет ежедневно в час ночи. Выглядит так: /vacuumdb -a -z -v -U postgres. Что как я считаю не правильно в это же время на всех БД работает КРОН и создается много записей в базах. Самый последний крон заканчивает работу в раене 5 утра. Моя мысль перенести этот ВАКУУМ на 5 утра чтобы обслуживание БД шло после всех операций по вставке и удалению данных кроном. Также на данный момент не выполняется VACUUM FULL. Правильно ли я понимаю что по хорошему нужно его раз в неделю запускать в часы когда нету никакой активности? Как я представляю его вынести на выходные дни после ночного крона. Правильно ли я рассуждаю и на сколько необходим VACUUM FULL?

А чем autovacuum не помогает? FULL хорошо, да, когда активности нет

А чем autovacuum не помогает? FULL хорошо, да, когда активности нет

он то может и помогает - но хотел прояснить недостатки и правильности логики по текущему конфигу.

рукми vacuum запускать не надо

Соглашусь с Игорем , вакуум должен работать без шаловливых ручек сам))

В pgpro EE есть компрессионое хранилище. Жмет в том числе и btree, GiST индексы.

compress у gist, например, из полигона делает бокс. это не gzip.

иначе просто невозможно сделать spgist индекс для геометрий

а в spgist нет compress

и индекс по боксам есть и клёвый, а по цельным геометриям - нет :(

салют. кто-нибудь пробовал автоматизировать переключение режима базы из потоковой репликации в боевой режим?

т.е. логика такова: нет ответа от боевого сервера: переключить режим базы на резервном хосте хосте

что будет, если боевой сервер на самом деле жив и его видит примерно половина клиентов?

хороший вопрос. я не знаю :) но почему локальная машина в той же подсети не будет видеть соседнюю боевую машину - тоже вопрос

да хоть гц в штуке, через которую почему-то проходит трафик

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

с репликацией понятно, но как это автоматизировать - не очень понятно

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

patroni?

https://github.com/2ndQuadrant/repmgr

спасибо, сейчас почитаю

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

github.com/zalando/patroni

а кто-нибудь уже Postgres 10 поставил?

Add conditional branch support to psql (Corey Huinker) The new syntax uses \if, \elif, \else, and \endif. This is particularly helpful for scripting.

там, похоже, вкусные вещи :)

Ссыкотно ставить 10 пока

а он с каким статусом? альфа?

beta

Я в апреле до 9.6 обновился тока

https://www.postgresql.org/about/news/1749/

салют. кто-нибудь пробовал автоматизировать переключение режима базы из потоковой репликации в боевой режим?

Я в своё время на heartbeat это делал. Однажды ему (хирбиту) снесло башню, и он туда-сюда мне переключал активный узел. Но так, как автоматизация была не совсем автоматическая, то фатальных последствий не было. :)

у вас видимо был splitbrain, нужно 3 мастера) В системах автоматизации с фейловером я лично не верю, т.к. они все работают до первого пиздеца (простите) и понятия не имею, как обеспечить отказоустойчивость (продолжать принимать запись) и сохранить консистентность.

Ээээ... Каких-таких три мастера?! Какой сплитбрейн, если хирбиту снесло башню на почве сети, и он то видел соседние узлы, то нет. Соответственно, переключал их, по, например, разному.

у вас видимо был splitbrain, нужно 3 мастера) В системах автоматизации с фейловером я лично не верю, т.к. они все работают до первого пиздеца (простите) и понятия не имею, как обеспечить отказоустойчивость (продолжать принимать запись) и сохранить консистентность.

В целом согласен, но в частности у Patroni очень грамотная архитектура. Теоретический split brain может быть в рамках 30 сек - время жизни записи "кто здесь мастер" (по умолчанию) при нештатной ситуации.

А > понятия не имею, как обеспечить отказоустойчивость (продолжать принимать запись) и сохранить консистентность. обеспечивается кворумом, отдельной сущностью, которая решает

привет

подскажите пожалуйста

поставил постресс, в пользователя постгрес и psql заходит

у - успех

поставил постресс, в пользователя постгрес и psql заходит

Поздравляем вновь прибывшего в стан postgresql

http://dpaste.com/1WYJ7E1

сделал пароль

ERROR: S client not available

postgres=# \password postgres

но проблема в том, что ему пофиг на пароль

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

https://github.com/2ndQuadrant/repmgr

единственное, что я не понял: repmgr должен быть на мастере, или на отдельном хосте вообще?

я конечно туплю сильно, ибо у нас каламбур сейчас(дедлайн)

у тебя программист заходит под системным юзером в базу?

pg manager lite

у тебя программист заходит под системным юзером в базу?

да, под postgres

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

тоже не работает

единственное, что я не понял: repmgr должен быть на мастере, или на отдельном хосте вообще?

repmgrd должен быть на всех postgresql машинах. Кроме мастера

Ну не знает еще человек про ACL в postgres, может они только потрогать поставили

так, то есть демоны должны быть везде, но под управляющий repmgr должен быть отдельный хост, правильно?

Локации – это дата центры очевидно

так, то есть демоны должны быть везде, но под управляющий repmgr должен быть отдельный хост, правильно?

Отдельный хост нужен только под Witness ноду. Для предотвращения Split Brain

Ну не знает еще человек про ACL в postgres, может они только потрогать поставили

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

Ну не знает еще человек про ACL в postgres, может они только потрогать поставили

на виртуалке, на бубунте, заходят именно так

http://dpaste.com/1WYJ7E1

и в результате пишется psql: ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Peer)

хотя пароль верный, я его недавно ставил

и в результате пишется psql: ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Peer)

Вы пытаетесь зайти в БД пользователем postgres, в то время, как системый у вас совершенно более другой.

?ну на бубунте и версии 9,5,2 у людей заходит

peer - насколько я помню, не требует апроля у идентичного пользователя, а вот пускать других... Не знаю, не знаю.

и в результате пишется psql: ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Peer)

отредактируйте pg_hba.conf, поcтавьте md5 вместо peer

и потом reload

reload где?

restart сервиса?

ну можно restart, если не жалко