Комментарии 16
замечу, что если при восстановлении из PITR бекапа, поставить шаред в 16М, то она всосет все на порядки быстрее. проверено на боевых.
п.с. для ленивых. это когда она восстанавливает БД из WAL файликов, коих может быть много, очень много и просто дохрена
п.с. для ленивых. это когда она восстанавливает БД из WAL файликов, коих может быть много, очень много и просто дохрена
А без башизмов (#!/bin/bash) в скриптах никак не обойтись (#!/bin/sh)?
Нелепица какая-то.
Вместо архивирования WAL — сетевое хранилище, куда мастер пишет (!) WAL-логи. К чёрту производительность!
Для надёжности надо ленточные библиотеки использовать.
Вместо архивирования WAL — сетевое хранилище, куда мастер пишет (!) WAL-логи. К чёрту производительность!
Для надёжности надо ленточные библиотеки использовать.
С производительностью все в порядке. Сам процесс PostgreSQL не записывает WAL-файлы в сетевое хранилище, это делается периодически rsync-ом. Можно это прописать в команде archive_command, но я решил делать это независимо. Извиняюсь, что не расписал это, но у меня ведь не пошаговая инструкция, а описание концепции с некоторыми деталями.
Не хочу показаться грубым, но концепция не представляет из себя ничего нового — это стандартный подход к резервному копированию БД.
Это, конечно, всяко лучше обзора телефончика, но всё же — зачем этот пост нужен?
В нём нет ничего нового, и если уж он является описанием «концепции», то почему нет полной схемы организации резервного копирования?
Это, конечно, всяко лучше обзора телефончика, но всё же — зачем этот пост нужен?
В нём нет ничего нового, и если уж он является описанием «концепции», то почему нет полной схемы организации резервного копирования?
Он для меня допустим нужен. Для людей кто ещё не работает с большими проектами, но хочет эту тему изучить. Такие небольшие статьи с описанием ярлыков «вот есть то и это» как раз и помогают понять суть, а детали уже потом. Может автор и напишет статью для другой аудитории =)
П.С. Спасибо за труд, сохранил, восспользуюсь! Добра вам! =)
П.С. Спасибо за труд, сохранил, восспользуюсь! Добра вам! =)
Не хочу показаться грубым, но концепция не представляет из себя ничего нового — это стандартный подход к резервному копированию БД.
Если еще когда-нибудь захотите не показаться грубым, то можно просто кинуть ссылки на хабр статью, где тоже самое рассказывается. Тогда это поможет автору показать что именно нового он привнес.
А пока, статья для меня имела практический смысл
Не совсем понятен мотив создания потабличных дампов. В общем случае их накатить все равно невозможно из-за ограничений целостности.
С ними легко работать, когда нужно восстановить данные конкретной таблицы. Можно восстановить эту таблицу в другой базе и получить оттуда данные (вручную или скриптом). А можно накатить ее сразу в рабочую базу, изменив предварительно имя таблицы, и одним запросом восстановить утраченные данные. Такая процедура займет всего несколько минут (в зависимости от размера таблицы). Разворачивание же дампа всей БД может затянуться на часы.
Еще эти дампы помогают понять, когда (в какой день) изменилось какое-то поле — при разборе полетов может пригодиться.
Еще эти дампы помогают понять, когда (в какой день) изменилось какое-то поле — при разборе полетов может пригодиться.
Но у дампа есть большой минус — процесс блокирует таблицы, и другие процессы уже не могут с ними работать
Из документации:
pg_dump does not block other users accessing the database (readers or writers).
PG версионник, pg_dump ничего не блокирует, это будет слепок БД на момент запуска pg_dump. Другой момент что при бекапе большой БД, (да и еще если в несколько птоков, что позволяет 9.3) — тормозить уже будет дисковая подсистема, а значит и БД.
Насчет восстановления нужной версии, с недавнего времени делаю бекап просто по крону pg_dump + сжатие и копирование файла в Dropbox. Попробую проанализировать способ копирования самих файлов, спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не потерять данные в PostgreSQL