Возможно ли или целесообразно направить / передать вывод pg_dump в S3?
Мы выгружаем большие наборы данных в наш экземпляр, а размер базы данных большой. Поэтому пытаемся оптимизировать пространство на локальном диске (избегать временного пространства для дампа) и создавать резервную копию прямо на S3.
У нас есть PostgreSQL v9.6.3 на Ubuntu 16.04.
Потоковая передача pg_dump непосредственно на S3, похоже, работает нормально. У меня база данных 350 ГБ, и я не хочу создавать временные дополнительные диски. Вы должны убедиться, что размер многоэлементного блока достаточно велик, иначе я столкнулся с проблемой «слишком много сегментов». С помощью интерфейса командной строки AWS команды:
aws configure set default.s3.multipart_chunksize 200MB
time sudo -u postgres pg_dump -Z 9 -v DB_NAME |aws s3 cp - s3://BUCKET/DB_NAME.dump.gz
С моим db это заняло около 8 часов, и в результате получился файл 130 ГБ в S3. Теперь восстановление должно выполняться с помощью psql, поскольку pg_restore не любит простые дампы sql, которые создает команда выше. Я не мог использовать там собственный формат, так как он хочет создать каталоги, которые нельзя (вероятно?) Передать по конвейеру.
Окончательное восстановление таким же образом, без промежуточного сохранения файла. Обратите внимание, что мне пришлось распаковать данные перед psql с помощью zcat:
wget -O - 'https://S3-URL/BUCKET/DB_NAME.dump.gz' |zcat |sudo -u postgres psql DB_NAME
Восстановление, похоже, занимает примерно то же время (~ 8 часов), что и сброс, вероятно, зависит от того, где и насколько велик ваш сервер (AWS или где-то еще, мой находится за пределами AWS).
Вы можете использовать s3 функция многокомпонентной загрузки для потоковой передачи дампа по мере его создания. Однако это может быть подвержено ошибкам и менее чем надежно. Лучше всего создать временный том EBS и сбросить на него базу данных. А затем загрузите сжатую резервную копию в s3 / Glacier, если это нужно.
Если вам нужна резервная копия для восстановления на определенный момент времени, выполните pg_basebackup на том EBS и архивирование потока WAL с момента после резервного копирования означает, что вы можете сократить время до восстановления без сохранения полного узла реплики. Если вас беспокоит доступность, то лучше всего настроить репликацию. Хотя вам все равно понадобятся резервные копии.
Репликация не является резервной копией, если кто-то отбросит таблицу в Origin, она будет отброшена в Replica; так что вам все еще нужны резервные копии PITR или контрольных точек.
Нет, это неразумно. Вместо этого установите фактическое воспроизведение который PostgreSQL поддерживает. Я бы использовал модель подписчика, но вы также можете выполнить доставку WAL-журнала в s3, если хотите использовать archive_command.
Однако в большинстве случаев в этом нет необходимости. Я бы не стал рассматривать это, если бы у меня не было более специального варианта использования.
Я бы обновился до 10.1 и переходите к логической репликации с абонентской моделью.