Не вышло. Говорит не может подключиться к мастеру((

А мастер не локал хост слушает?

Для 9.3 пойдет. С 9.4 еще репликацию по слотам добавить надо https://habrahabr.ru/post/245847/

Спасибо, почитаю на трезвую годову

netstat -an|grep 5432

А мастер не локал хост слушает?

Неа, я психанул и указал listenip = *

Фаервол?

Listen_address = '*'

Неа

телнет проходит?

С будущей реплики на мастер

Потестирую завтра еще раз

С нуля

а без рестарта постгрес не перебиндить же?

да

Не, ну рестар же по умолчанию

А я еще психовал

Поэтому и виртуалки ребутал со злости

ну, мне бы бекапы настроить, но я не хочу бекапы на мастере снимать, так что сначала настрою реплику

А как бэкап снимать собираетесь?

думаю pgdump с слейва, или есть что-то более оптимальное?

Со слэйва будет небольшая проблемка - конфликт pg_dump с процессом восстановления.

Я по нему и делал

Я ж тебе дал статью.

думал вот ним https://wiki.postgresql.org/wiki/Automated_Backup_on_Linux

Со слэйва будет небольшая проблемка - конфликт pg_dump с процессом восстановления.

хм, те, я дамп на мастер в случае чего не залью?

думаю pgdump с слейва, или есть что-то более оптимальное?

Pg_basebackup

хм, те, я дамп на мастер в случае чего не залью?

Дамп не снимется просто, если на мастер много пишется

хм, те, я дамп на мастер в случае чего не залью?

Он не снимется просто - процесс восстановления его оборвет. Обходится выставлением параметре stream_timeout (точно название не помню), но тогда реплика отставать будет от мастера существенно

Не подходит если вы слэйв используете еще, например, для запросов на чтение.

не, слейв в данный момент просто для снятия бекапа

а может кто поделиться скриптом для бекапов который использует Pg_basebackup ?

Счастья всем

и ты тут))

и ты тут))

Не спрячетесь. :)

а то)))

Добрый день! Приглашаем выступить с докладом или мастер-классом на конференции по базам данных PG Day'17 Russia, которая состоится 5-7 июля в Санкт-Петербурге! Более подробная информация на нашем сайте: http://pgday.ru/ru/2017/for-speakers

Добрый день! Приглашаем выступить с докладом или мастер-классом на конференции по базам данных PG Day'17 Russia, которая состоится 5-7 июля в Санкт-Петербурге! Более подробная информация на нашем сайте: http://pgday.ru/ru/2017/for-speakers

Здравствуйте, Марьяна! А темы докладов еще не известны?

а может кто поделиться скриптом для бекапов который использует Pg_basebackup ?

pgBackRest - отличная штука. Barman даже не пытайся использовать

Здравствуйте, Марьяна! А темы докладов еще не известны?

Темы докладов еще не известны. Прием заявок будет открыт до середины апреля. Далее мы будем формировать окончательную программу конференции.

pgBackRest - отличная штука. Barman даже не пытайся использовать

О, Игорь, раз вы пользуетесь, не можете объяснить как это http://www.pgbackrest.org/configuration.html#section-general/option-checksum-page работает с такими данными, как например всякие файлы, которые не имеют чексуммы: clog или файлы экстеншенов (например pg_stat_statements)

Да Вы троль

И спасибо за информацию

А если я на слейве лочу таблицу, а потом разлочу. Она ж автоматически досинкает?

А если я на слейве лочу таблицу, а потом разлочу. Она ж автоматически досинкает?

лок логический, он живет в паралельной вселенной с физической репликацией. но есть такой параметр: max_standby_streaming_delay подробнее тут: https://postgrespro.ru/docs/postgrespro/9.6/runtime-config-replication

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

выборка будет чаще всего: объект, период и все показатели за него пока мысль такая: date (date), object_id (int), stat (hstore)

date - object_id первичный ключ

как в целом такой подход?

Если будет много данных, то таблицу стоит партиционировать. А так всё ок.

Я, правда, люблю когда первичный ключ сам по себе. А на эту штуку отдельный индекс повесить...

А зачем вам вообще первичный ключ?

Посмотрите, например, как в решающей аналогичную задачу таблице в Zabbix сделано: CREATE TABLE "public"."history_uint" ( "itemid" int8 NOT NULL, "clock" int4 DEFAULT 0 NOT NULL, "value" numeric(20) DEFAULT '0'::numeric NOT NULL, "ns" int4 DEFAULT 0 NOT NULL ) WITH (OIDS=FALSE) ; CREATE INDEX "history_uint_1" ON "public"."history_uint" USING btree ("itemid", "clock"); ALTER TABLE "public"."history_uint" CLUSTER ON "history_uint_1";

соответственно при отборе объект+период все берется из кластерного индекса с покрывающим условием

Ну и наконец, не кажется ли Вам, что Вы изобретаете велосипед? :) https://zabbix.com

заббикс ужасен

((

А что лучше?

заббикс ужасен

Вам никто не мешает написать свой мониторинг, с go и nosql-базой.

да тут скорее интерфейс

чем го и NoSQL

нравится решения от NewRelic и датадог

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

нет дэшборда на котором было бы сразу несколько графиков по одному или более хостов

нет мониторинга процессов отдельных

нет интеграции с приложениями

Чо?

в заббиксе

Чо?

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

я хочу посмотреть что сьело память — как?

кто

smem

https://github.com/galindro/zabbix-enhanced-templates ?

На самом деле ноды не умирают из-за процесса ntpd или udev А целевые процессы легко и непринужденно настраиваются на proc.mem Или простейшее дискавери

Или еще пример: сервер уронен запросом с декартовым произведением. Что вам даст имя или PID процесса, съевшего память?

А между прочим, коробочное решение от postgrespro сделано именно под zabbix

https://github.com/postgrespro/mamonsu

а использовать pgdump и высокое время в max_standby_streaming_delay очень костыль?

На аплай делей а не стриминг

Надо*

Надо*

Тут редактировать можно

Нужно.

я хз куда нажать в тилифоне чтобы редактировать

Можно на глаз например.

или на сообщение

Или на сообщение.

но лучше на глаз

Факт, лучше на глаз.

Какие вы синхронные

Сегодня в rude python полдня асинхронщину обсуждали. Естественно синхронные.