неа

в свободном доступе только 9.4

9.6 не дают

9.5 тоже

кроме того отсутствие раздела backup в офф документации bdr наводит на нехорошие мысли

можно конечно рискнуть и бекапить по феншую отдельную ноду, а потом из нее восстанавливаться так как в офф доке ПГ прописано

но чёт всёравно ссыкотно

кстати

тут вроде был знаток BDR

Я про bdr тоже послушал бы

тут вроде был знаток BDR

А как у вас она используется?

никак

у нас ее разрабы хотят

идиоты...

ая пока больше минусов вижу чем плюсов

А зачем они её хотят?

специфика...

не могу сказать

просто поступил заказ :)

продавили решение так сказать...

50 Гб пару часов? Странно, это что же за конфигурация железа (память, диски) такая? А так - у пг_базебекап есть ключик -X, если указать ему значение stream, то pg_basebackup в параллельном соединении будет вытаскивать необходимые для старта и догона мастера WAL-ы. Но таки archive_mode = on & archive_command = 'чего-то там, откуда сможет забрать слейв' надёжнее.

так через интернет же )

вобщем запускал сейчас так - на слейве - pg_basebackup —host=10.2.0.108 —username=repluser —pgdata=/var/lib/postgresql/9.6/main —xlog-method=stream —write-recovery-conf —slot=replica_slot —progress

в логах :

2018-03-27 11:23:46.361 MSK [8672] СООБЩЕНИЕ: работа системы БД была прервана; последний момент работы: 2018-03-27 11:15:30 MSK 2018-03-27 11:23:46.589 MSK [8672] СООБЩЕНИЕ: переход в режим резервного сервера 2018-03-27 11:23:46.634 MSK [8672] СООБЩЕНИЕ: запись REDO начинается со смещения AF/F93AC230 2018-03-27 11:23:46.690 MSK [8675] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет 2018-03-27 11:23:47.214 MSK [8678] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:47.721 MSK [8681] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:48.228 MSK [8684] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:48.735 MSK [8687] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:49.242 MSK [8690] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:49.749 MSK [8693] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:50.255 MSK [8696] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:50.763 MSK [8699] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:51.270 MSK [8703] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:51.777 MSK [8706] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:52.284 MSK [8709] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:52.288 MSK [8671] СООБЩЕНИЕ: получен запрос на "вежливое" выключение 2018-03-27 11:23:52.299 MSK [8673] СООБЩЕНИЕ: выключение 2018-03-27 11:23:52.345 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/69CC1D30 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.345 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6929414_vm 2018-03-27 11:23:52.360 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/6A5D78F8 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.360 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6929820_vm 2018-03-27 11:23:52.875 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/F721EAE8 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.875 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6957741_vm 2018-03-27 11:23:52.918 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/229AB5F0 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.918 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6962200_vm 2018-03-27 11:23:52.922 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/83E89E30 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.922 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6962313_vm 2018-03-27 11:23:53.195 MSK [8671] СООБЩЕНИЕ: система БД выключена

специфика...

наши хотят кластер с простоем 0 сек. озадачили на postgesXL сижу думаю а надо ли))))

наши хотят кластер с простоем 0 сек. озадачили на postgesXL сижу думаю а надо ли))))

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

2018-03-27 11:23:46.361 MSK [8672] СООБЩЕНИЕ: работа системы БД была прервана; последний момент работы: 2018-03-27 11:15:30 MSK 2018-03-27 11:23:46.589 MSK [8672] СООБЩЕНИЕ: переход в режим резервного сервера 2018-03-27 11:23:46.634 MSK [8672] СООБЩЕНИЕ: запись REDO начинается со смещения AF/F93AC230 2018-03-27 11:23:46.690 MSK [8675] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет 2018-03-27 11:23:47.214 MSK [8678] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:47.721 MSK [8681] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:48.228 MSK [8684] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:48.735 MSK [8687] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:49.242 MSK [8690] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:49.749 MSK [8693] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:50.255 MSK [8696] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:50.763 MSK [8699] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:51.270 MSK [8703] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:51.777 MSK [8706] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:52.284 MSK [8709] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-27 11:23:52.288 MSK [8671] СООБЩЕНИЕ: получен запрос на "вежливое" выключение 2018-03-27 11:23:52.299 MSK [8673] СООБЩЕНИЕ: выключение 2018-03-27 11:23:52.345 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/69CC1D30 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.345 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6929414_vm 2018-03-27 11:23:52.360 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/6A5D78F8 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.360 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6929820_vm 2018-03-27 11:23:52.875 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/F721EAE8 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.875 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6957741_vm 2018-03-27 11:23:52.918 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/229AB5F0 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.918 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6962200_vm 2018-03-27 11:23:52.922 MSK [8673] ПРЕДУПРЕЖДЕНИЕ: xlog min recovery request B0/83E89E30 is past current point B0/1CCE3BB8 2018-03-27 11:23:52.922 MSK [8673] КОНТЕКСТ: запись блока 0 отношения base/540548/6962313_vm 2018-03-27 11:23:53.195 MSK [8671] СООБЩЕНИЕ: система БД выключена

Centos?

?

Centos?

debian 9

systemd гасит по таймауту похоже

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

Так миллиард они знают где потратить ORACLE, а им бесплатное подавай))))

Запусти БД через pg_ctl

Запусти БД через pg_ctl

на слэйве backup_label переименовался в backup_lebel.old, перед запуском обратно переименовать ?

или снова надо делать бэйзбэкап?

Он значения не имеет

Он значения не имеет

через pg_ctl запустилось, спасибо, буду теперь думать как запустить через systemd

милейший, вы что такое ужасное делаете?

Привет всем, мигрирую код с oracle на postgres. Есть вызов аггрегатов lag и lead с ignore nulls. Как можно сэмулировать ignore nulls для этих функций в postgres? Для lag нашел такое решение (https://stackoverflow.com/a/47775115), пытаюсь так же сделать для lead, но пока не пойму как получить следующее значение.

Привет всем, мигрирую код с oracle на postgres. Есть вызов аггрегатов lag и lead с ignore nulls. Как можно сэмулировать ignore nulls для этих функций в postgres? Для lag нашел такое решение (https://stackoverflow.com/a/47775115), пытаюсь так же сделать для lead, но пока не пойму как получить следующее значение.

CASE-выражение под агрегирующей функцией.

CASE-выражение под агрегирующей функцией.

спасибо, работает

А ты сам что ли пишешь эти агрегирующие функции новые?

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

чтобы не выискивать все индексы и не писать на них альтер на каждый

никак

через pg_ctl запустилось, спасибо, буду теперь думать как запустить через systemd

вобщем все решилось снятием таймаута в systemd юните - TimeoutSec=0

а ктонибудь мониторит postgresql munin'ом ?

а ктонибудь мониторит postgresql munin'ом ?

https://munin.openstreetmap.org/openstreetmap/errol.openstreetmap/index.html#postgresql

https://munin.openstreetmap.org/openstreetmap/errol.openstreetmap/index.html#postgresql

у меня это есть, не могу врубится как прикрутить плагин для мониторинга лага репликации

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

alter

доступ к нему надолго нужен будет?

alter

какой именно альтер сможет перенести таблицу вместе со всеми индексами?

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

просто я переносил еще в 9.4 через pgadmin

ALTER TABLE ALL IN TABLESPACE имя [ OWNED BY имя_роли [, ... ] ] SET TABLESPACE новое_табл_пространство [ NOWAIT ]

ALTER INDEX ALL IN TABLESPACE имя [ OWNED BY имя_роли [, ... ] ] SET TABLESPACE новое_табл_пространство [ NOWAIT ]

https://postgrespro.ru/docs/postgrespro/9.6/sql-alterindex

https://postgrespro.ru/docs/postgrespro/9.6/sql-altertable

это ты весь тейблспейс переносишь

а надо одну таблицу и все её индексы

ссылки почитай

работает и для одной

для одной таблицы, индексы остаются где были

ERROR: S client not available

их надо выискивать и по одному таскать

тебе перенести надо или перенести все за раз?

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

в итоге лежащая на ссд таблица остаётся с индексами на винчестере

ну напиши уже функцию

руками он переносит

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

таймаутами?

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

https://www.postgresql.org/docs/9.6/static/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT

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

почему отваливается приложение?

по разным причинам, может пользователь не дождался отчёта и вышел или просто отвалилось из-за говнокода

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

kill ?

ну да, конечно, но это делается руками, как автоматически это делать или вообще настроить в настройках какой нибудь опцией?

ну да, конечно, но это делается руками, как автоматически это делать или вообще настроить в настройках какой нибудь опцией?

можно так: https://postgrespro.ru/docs/postgrespro/10/runtime-config-client#GUC-STATEMENT-TIMEOUT

ну да, конечно, но это делается руками, как автоматически это делать или вообще настроить в настройках какой нибудь опцией?

idle_in_transaction_session_timeout...? (9.6+)

ребят

подскажите тулзу для реверса БД в ER диаграммы

лучше free

лучше free

DBeaver

реверс будет работать только если есть констрейты и/или хотя бы ключи называются одинаково

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

THNX!

ну да, конечно, но это делается руками, как автоматически это делать или вообще настроить в настройках какой нибудь опцией?

А вот, кстати, как автоматически завершать backend-ы, которые висят и ничего не делают (клиент "тихо" отвалился вне транзакции)?

подробностей не помню, но в общем - стукнуться в системную таблицу и поменять атрибут столбца вроде

пардон

не атрибут столбца

там есть табла с коннектами... вобщем через нее =))

Парни напомните плиз нужно ли рестартовать базу после того как на таблицу навесил индивидуальные параметры автовакума ?