глянул в исходники — а там pg_dumpall вызывает pg_dump через system(). ужас какой

если бы pg_dumpall позволял задавать кастомные аргументы для pg_dump. было бы костыльно, но хоть как-то можно было извернуться

pg_dump -f /backup/<db_name> -Fd -j 8

кажется тут не хватает одного самого главного параметра ) зато d может быть весьма полезен, спасибо!

С полученной резервной копией можно работать штатными средствами Unix, например, несжатую копию можно сжать посредством gzip. Этот формат по умолчанию сжимается, а также поддерживает работу в несколько потоков.

так сжимается или надо сжимать самостоятельно?

если бы pg_dumpall позволял задавать кастомные аргументы для pg_dump. было бы костыльно, но хоть как-то можно было извернуться

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

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

Так и делаю

Так и делаю

-s ?

pg_dumpall - выгружаю роли, pg_dump - данные

-r значит

а еще -t есть. я запутался

-g эквивалентно -r -t

-s ?

-g

Вообще, да, беда с этими утилитами

expdp намного гибче

-g

чот както совсем ниочем. наверно всё же дополнительно -s надо

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

скажите пожалуйста если я хочу сделать pg_dump базы 390Гб, а в хоме есть лишь 300Гб то как лучше поступить? и как вообще оценить какого размера будет бекап?

а почему не pg_basebackup ?

потому что нуб наверно ?

попробуй, там и сжатие из коробки есть

а почему не pg_basebackup ?

Может, потому что pg_basebackup ни чего не знает про содержимое БД?

а как экстеншоны забекапить?

Если разработчик не позаботился об этом, то ни как.

Таблицы экстеншена не попадут в дамп

Павел Лузанов в своём блоге про это писал

даже "стандартные"?

а как тогда правильно бекапить бд с постгисом?

попробуй, там и сжатие из коробки есть

сложна

а как тогда правильно бекапить бд с постгисом?

и вопрос в том как потом правильно восстанавливать )

а как тогда правильно бекапить бд с постгисом?

кажется -s как раз то что нужно. т.е. первый этап выглядит так просто pg_dumpall -c -s | gzip > /var/lib/pgsql/9.6/backups/osm_int_schema.gz

кажется -s как раз то что нужно. т.е. первый этап выглядит так просто pg_dumpall -c -s | gzip > /var/lib/pgsql/9.6/backups/osm_int_schema.gz

спасибо, буду завтра на работе пробувать :)

Может, потому что pg_basebackup ни чего не знает про содержимое БД?

хватит людей пугать, у 99% даже чек суммы не включены или память не ECC

99,99

а зачем серьёзным СУБД чексуммы? чай не мускль какой

че тут, цензура?

совсем интернетик своей цензурщиной испахабили

а что, трут что-то? всё вроде на месте

запустил $ pg_dump -a -f /var/lib/pgsql/9.6/backups/osm_int_dat -Fd -j 4 osm_int вроде зипует, посмотрю как оно получится

осталась одна загадка - индексы. как они восстановятся?

заново перестроятся

заново перестроятся

но если дамп с опцией -a то попадут ли они вообще в бекап?

а, тогда нет. Только данные таблиц

Стикерпак хорош но я за цензуру

Кстати на бб и правда видно не было а с мобилы норм

Стикерпак хорош но я за цензуру

ПГТелеграмНадзор!

совсем обезумели!

Швабодка это же морковка для ослов

Швабодка это же морковка для ослов

https://ria.ru/religion/20170701/1497659639.html

извините

извините

Нет

:(

ура! наконецто!!))

запустил $ pg_dump -a -f /var/lib/pgsql/9.6/backups/osm_int_dat -Fd -j 4 osm_int вроде зипует, посмотрю как оно получится

@s80x24, докладываю! планета сжалась до 165Гб. в 4 потока получилось довольно быстро. запаковал всё это в tar и теперь по https перетаскиваю на другой сервак )

@s80x24, докладываю! планета сжалась до 165Гб. в 4 потока получилось довольно быстро. запаковал всё это в tar и теперь по https перетаскиваю на другой сервак )

А https по ГОСТу? )

А https по ГОСТу? )

Товарищ майор потом расскажет

ERROR: S client not available

Так сегодня и не выяснил как бекапить индексы

Буду сегодня выяснять ?

Бэкапить - basebackup

А если дампить - то снимаете дамп и в нем можно грепануть по create index

Будет только создание индексов

Все индексы и конструкция в post-data секции бэкапа. Можно дампить только её

*Constraints :-)

Бэкапить - basebackup

Да, прошу прощения за путаницу в терминологии. Просто моя база пока не меняется

Все индексы и конструкция в post-data секции бэкапа. Можно дампить только её

Что за секция, почему не встречал?

Павел Лузанов в своём блоге про это писал

А можно ссылку на этот пост... А то гугль во всякие новости от PgPro посылает вместо блога.

Насколько я понимаю, таблицы экстеншена создаются внутри БД. Почему они не сдампятся, не понятно. Чем они отличаются от других таблиц?

Та часть, которая в контрибах, либы и т.д, конечно не дампятся. Глупо было бы этого ожидать

http://pavelluzanov.blogspot.ru/2016/03/pgdump.html?m=1

Но при чем сдесь разработчик? Следить на том, чтобы контрибы везде были такие как надо, задача админа БД.

Спасибо.

Но при чем сдесь разработчик? Следить на том, чтобы контрибы везде были такие как надо, задача админа БД.

Ну, некоторые dba даже с репозитория postgresql.org СУБД не устанавливают, только из реп ОС-и.

Я к тому, что залётных экстеншенов там надеюсь нет :)

http://pavelluzanov.blogspot.ru/2016/03/pgdump.html?m=1

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

А как pg_dump узнаёт, что таблицы к экстеншену относятся? Есть какой-то признак?

А как pg_dump узнаёт, что таблицы к экстеншену относятся? Есть какой-то признак?

из pg_depend похоже

см. getExtensionMembership() в pg_dump.c

еще пгдэй не начался, а народ уже повалил)

еще пгдэй не начался, а народ уже повалил)

Хороший знак )

еще пгдэй не начался, а народ уже повалил)

откуда? :)

да спамерские твинки небось )

приве, а есть канал где можной позадавать поросы про mysql?

@mysql_ru

спасибо