Я пытаюсь полюбить PostGreSQL. Я продвигаю это в своей компании. Я хочу, чтобы мы применяли его для новых и новых проектов. Но я лично озадачен проблемой резервного копирования / восстановления. Я все думаю, если бы это был MS-SQL, это не было бы проблемой ...
Мы не можем восстановить резервные копии нашей базы данных - не с помощью pg_dump и pg_restore. Это не удается по многим причинам. Я искал довольно много - часы и часы - без единого средства. Большая часть базы данных восстанавливается, но ключевые части - нет.
Как многие знают, в MS-SQL можно отключить базу данных и сделать копию файлов MDB и LDB, а затем снова подключить ее. Затем я могу перенести эти два скопированных файла на любой другой компьютер и повторно подключить их, и, исключив, возможно, отсутствующие учетные записи пользователей, по нашему опыту, у нас не было проблем.
Но pg_dump и pg_dumpall (которые в большинстве случаев просто итеративно вызывают pg_dump) сбрасывают команды SQL для воссоздания базы данных. Не побайтовую копию состояния базы данных. Учитывая, что восстановление нашей базы данных с помощью команд, которые pg_dump выплевывает для ее создания, не работает, есть ли какая-либо альтернатива, более близкая к решению для копирования на уровне байтов из мира MS-SQL, которую я могу использовать?
Какая цель? Помимо очевидного (возможность восстановить базу данных в случае сбоя), я пытаюсь развернуть среду разработки Vagrant. Итак, у нас есть одна главная копия базы данных, которую наш разработчик базы данных устанавливает в своей виртуальной среде разработки. Затем я и другие хотят иметь возможность получать периодические снимки базы данных после серьезных изменений и загружать снимки в бродяг на наших машинах.
Если бы мы могли легко сделать резервную копию и восстановить базу данных, это не было бы проблемой. Это будет работать нормально. Я бы предпочел не копировать всю виртуальную машину, чтобы поделиться изменениями в базе данных.
Единственное, что я пробовал отличаться от игры с pg_dump [all] и pg_restore, - это SymmetricDS, но он сломал базу данных ... возможно, из-за неправильной конфигурации или, возможно, потому, что он пытается делать то же самое, что и pg_dump. Точно сказать не могу.
Я подозреваю, что меня будут спрашивать, почему pg_restore не работает. Итак, чтобы кратко прояснить, это связано с пользовательскими типами данных, операторами и функциями, установленными сторонним программным обеспечением и нами, во взаимозависимые схемы (ArcSDE и PostGIS), которые не создаются в правильном порядке, поскольку pg_dump считает, что они должны быть созданы. Я также считаю (хотя и не могу доказать), что search_path, установленный в начале резервного копирования pg_dump, неверен, что не помогает процессу восстановления, уже затрудненному взаимозависимостями схем.
Вы можете делать резервные копии на физическом уровне / на уровне файлов на PostgreSQL, хотя это не стандартная практика (я очень постараюсь, чтобы pg_dump работал; вы спрашивали в списке рассылки?)
В качестве другого варианта, рассматривали ли вы реплицированную установку, с "живым" резервным копированием / восстановлением на определенный момент времени?
В любом случае, чтобы сделать физическую резервную копию с минимальным временем простоя, вам необходимо:
/var/lib/pgsql)Поскольку создание снимка выполняется очень быстро, время простоя сводится к минимуму.
Чтобы восстановить базу данных на другом сервере PostgreSQL, сделайте следующее:
mv /var/lib/pgsql /var/lib/pgsql_original)mv mycopy /var/lib/pgsql)Обратите внимание, что такие резервные копии можно использовать только между той же версией PostgreSQL и та же самая арка (например: вы не можете восстановить резервную копию i386 / 32 бит на машине x86_64 / 64 бит).