Я создал скрипт для выполнения физического резервного копирования базы данных PostgreSQL 9.0.8, следуя рецепту «Автономное горячее физическое резервное копирование базы данных» из PostgreSQL 9 Administration Cookbook (Riggs/Krosing), но адаптировал его для Windows Server 2008 R2.
Для шага рецепта №4, который использует rsync для копирования всех файлов данных (исключая каталог pg_xlog), я использую robocopy.exe (поскольку rsync — это утилита *nix, а я использую Windows). Проблема в том, что часто один из файлов не может быть скопирован и выдает сообщение «Доступ запрещен». Копирование файла вручную завершается ошибкой «Доступ запрещен»длинныйпосле сбоя сценария резервного копирования - так что это не какая-то временная проблема, которую можно повторить. Файл можно скопировать только после перезапуска процесса PostgreSQL. Это всегда другой файл. Прошлой ночью это был %PGDATADIR%\5432\base\24609\38122 .
Я хотел бы услышать, сталкивались ли вы с этим и что вы делали, чтобы это исправить. Я рассматриваю:
- Перезапустите сервер PostgreSQL непосредственно перед резервным копированием (признаю, что это хак)
- Использование какой-либо утилиты, которая может копировать открытые файлы, например VSHADOW, DISKSHADOW и hobocopy (примечание: не robocopy)
- Может быть, есть какой-то способ заставить PostgreSQL снять все блокировки?
- [добавлено] см. ниже - похоже, что добавление регулярного "вакуумирования" устраняет симптом
решение1
Ладно, сначала самое главное — отложите свою кулинарную книгу. Вместо этого идите читатьраздел руководства Postgres о резервном копировании. Прочитайте всю главу — она не такая уж и длинная.
(Вы, вероятно, заметите некоторое сходство между ней и книгой — большинство книг по Postgres представляют собой просто приукрашенные версии руководства — но вы всегда должны использовать руководство как основной источник информации.)
Вся терминология, которую я буду использовать ниже, взята из руководства (так что если вы думали, что можете пропустить задание по чтению, то это не так. Если вы это сделаете, то, скорее всего, будете ужасно запутаны).
Теперь о вашей реальной проблеме: решение Unix часто непереносимо напрямую в Windows, и это один из таких случаев: система *nix с радостью принимает файл, который подвергается манипуляциям, а Windows выдает ошибку, которую вы видите.
То, как вы с этим справитесь, зависит от того, какой тип резервного копирования вы делаете.
Резервное копирование на уровне файловой системы
Если вы делаете«резервное копирование на уровне файловой системы»тыдолженВыключите сервер. Точка, конец обсуждения, других вариантов нет. База данных должна быть выключена полностью, чтобы этот тип резервного копирования был надежным (а если резервная копия, которую вы получаете, ненадежна, какой в этом смысл?).
Непрерывное архивирование/Восстановление на определенный момент времени и подчиненные серверы
Если вы делаетерезервная базакак часть настройкиВосстановление на определенный момент времении доставка бревен у вас есть два варианта:
- Все равно выключите сервер.
- Используйте инструмент, который может копировать открытые файлы (вариант (2) из вашего вопроса)
Затем вы продолжаете в соответствии с остальной частью документации по Point-in-Time Recovery / Log Shipping, создавая подчиненный сервер.
Когда вы хотите скопировать сервер базы данных на диск, просто остановите подчиненный сервер, сделайте его резервную копию и перезапустите его — мир продолжает вращаться на вашем главном сервере, а подчиненный сервер наверстает упущенное при перезапуске.
Вы также можете использовать базовую резервную копию плюс свернутые журналы транзакций, которые вы обычно отправляете на подчиненный сервер в качестве надежной резервной копии базы данных. Это, по-видимому, ближе всего к тому, чего вы пытаетесь добиться в своем вопросе, но я бы рекомендовал резервную копию подчиненного сервера, которую я описал, вместо этого — больше преимуществ (у вас есть горячий резерв) и меньше работы для главного сервера (нет дополнительных контрольных точек для сворачивания журнала транзакций резервной копии).
Что-то другое
Если ничего из вышеперечисленного вам не подходит, то вам придется использоватьSQL-дампы.
Есть и недостатки: Postgres должен блокировать каждую таблицу, когда она выгружается (что означает, что запись в вашу базу данных будет заблокирована), а SQL-дампы медленнее других вариантов.
Если ваша база данных имеет какой-либо реальный размер, я бы не советовал этот метод.