дамп базы через сеть с архивированием

Как по поводу просто настроить replication?

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

Самый простой вариант — добавить флаг '-C' в комманду ssh.

1. pg_dump умеет в сжатие 2. postgres умеет в репликацию

ssh user@host "pg_dump -c -U user base|xz" |unxz| psql -U user base

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

master slave реплика + резервирование со slave стороны решает.

Появилась мысль сжимать файл перед передачей но гугление флагов tar для чтения с stdin и архивацию в stdout результата не принесло.

http://www.linuxquestions.org/questions/linux-general-1/tar-tar-cvf-|-cd-root-%3B-tar-xvf-353132/

Совсем забыл что ssh сжимать умеет спс

-C или -c?

Наверно можно и тем и другим поигратся. Я имел в виду Compression. Как оно на скорости скажется — не знаю, не пробовал.

-с ощутимых результатов не дало, -C увеличело скорость в 3 раза

я бы на твоем месте на удаленной машинке кронтабом сделал задачу, которая делает бекап, жмет базу компрессором xz и например wput отправляет бекап на какой нибуть ФТП. Или примонтировать какую нибуть папку удаленной машинки и туда ложить бекапы, а еще лучше используй rsync.

Это не бекап. просто копирование базы на локальный комп для разработки и тестов.

ну как вариант еще можно rsync, он тоже сжимать умеет, при чем можно самому протестить каким компрессором будет быстрее.

Правильное решение — репликация.

Простое — быстрый дамп в файл, а потом уже с любой скоростью и низким приоритетом сжатие и передача по ssh.

Категорически неправильное — как в топикстарте. Это самый тяжёлый для сервера случай. И компрессия ssh тут поможет мало.

Простое — быстрый дамп в файл, а потом уже с любой скоростью и низким приоритетом сжатие и передача по ssh.
Категорически неправильное — как в топикстарте. Это самый тяжёлый для сервера случай. И компрессия ssh тут поможет мало.

Так в топикстарте и есть быстрый дамп только не в файл а в поток вывода и его передача по ssh. Почему это самый тяжелый случай и чем он принципиально отличается от «Простое»?

Почему это самый тяжелый случай и чем он принципиально отличается от «Простое»?

Потому что в «простом» случае произойдёт самый быстрый дамп и сервер будет залочен минимальное время.

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

Понятно, что если дамп длится считанные минуты, да ещё когда-нибудь ночью, разница будет невелика. А если там гигабайт? Десять гигабайт?

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

Это можно как нибудь проверить?

И тогда непонятная ситуация с дамп базы через сеть с архивированием (комментарий) Ведь до выполнения xz pg_dump уже должен отработать.

Это можно как нибудь проверить?

Пока идёт дамп большой таблицы попробуй туда что-то записать. А потом — ещё раз. Запросы должны встать в очередь. Я не в курсе тонкостей залочки в postrgre, но по логике должно быть так.

Ведь до выполнения xz pg_dump уже должен отработать

Нет. Пайп буферизируется, но он не примет все гигабайты. Так что pg_dump будет висеть почти до конца процесса упаковки, отдавая понемногу данные, которые будет также понемногу паковать xz и также понемногу передавая в сеть.

резонно

Просто я на этих граблях натанцевался много лет назад ещё в mysql. А сейчас они уже что-то типа FAQ'а по оптимизации. В результате пошёл сперва именно по простому пути (дамп и потом сжатие), а когда и оно не стало справляться (только дамп в файл длится минут 10—20), то перешёл на репликацию.

Правда, сейчас открыл для себя Percona XtraBackup, оно работает прямо с файлами базы данных и потому очень быстро, но там есть много своих капризов, которые пока не дают использовать на практике (например, штатно оно восстанавливает целиком всю БД, а мне часто надо вытаскивать отдельные таблицы).

Пока идёт дамп большой таблицы попробуй туда что-то записать. А потом — ещё раз. Запросы должны встать в очередь.

Нет, в postgres будет всё работать параллельно, и резервное копирование таблиц и их чтение/запись. Единственное что будет заблокировано, это alter table и т.п. копируемой таблицы.

Правда, сейчас открыл для себя Percona XtraBackup, оно работает прямо с файлами базы данных и потому очень быстро

У postgres один из штатных режимов резервного копирования такой есть, на уровне файлов с последующим их восстановлением по WAL при запуске копии.