Физическое расположение объектов в базе данных PostgreSQL?

Мне интересно получить физическое расположение таблиц, представлений, функций, данных/контента, доступных в таблицах PostgreSQL в ОС Linux. У меня есть сценарий, что PostgreSQL можно установить на SD-карту и на жесткий диск. Если у меня есть таблицы, представления, функции, данные на SD, я хочу получить их физическое расположение и объединить/скопировать на свой жесткий диск, когда захочу заменить место для хранения. Я надеюсь, что хранение базы данных должно быть с точки зрения архитектуры простых файлов.

Кроме того, можно ли просмотреть содержимое файлов? Я имею в виду, могу ли я получить к ним доступ?


postgresql database-design data-storage
person siva    schedule 03.05.2012    source источник
comment
возможный дубликат Где файлы базы данных Postgres сохраняются в Ubuntu?   -  person Bruno    schedule 03.05.2012
comment
@Bruno: Не совсем тот же вопрос и явно не те же ответы.   -  person Mike Sherrill 'Cat Recall'    schedule 04.05.2012
comment
@Catcall, ты действительно прав.   -  person Bruno    schedule 04.05.2012

Ответы (3)


arrow_upward
7
arrow_downward

Кевин и Майк уже предоставили указатели, где найти каталог данных. Для физического расположения таблицы в файловой системе используйте:

SELECT pg_relation_filepath('my_table');

Не связывайтесь с файлами напрямую, если вы точно не знаете, что делаете.

база данных в целом представлена ​​подкаталогом в PGDATA/base:

Если вы используете табличные пространства, все становится сложнее. Подробнее читайте в главе Макет файла базы данных в руководство:

Для каждой базы данных в кластере есть подкаталог в PGDATA/base, названный в честь OID базы данных в pg_database. Этот подкаталог является расположением по умолчанию для файлов базы данных; в частности, там хранятся его системные каталоги.

...

Каждая таблица и индекс хранится в отдельном файле. Для обычных отношений эти файлы называются по номеру filenode таблицы или индекса, который можно найти в pg_class.relfilenode.

...

Функция pg_relation_filepath() показывает полный путь (относительно PGDATA) любого отношения.

Мой жирный шрифт.
Руководство по функции pg_relation_filepath().

person Erwin Brandstetter    schedule 03.05.2012
comment
+1, потому что я не знал об этой функции. Но pg_relation_filepath() не работает с базами данных. Для баз данных, я думаю, вам все равно нужно смотреть на табличное пространство. - person Mike Sherrill 'Cat Recall'; 04.05.2012
comment
@Catcall: я немного добавил к своему ответу, чтобы охватить базы данных и указать на руководство для более сложной ситуации, связанной с табличными пространствами. - person Erwin Brandstetter; 04.05.2012
comment
Извини, Эрвин. Я уже проголосовал за вас один раз. Если хочешь больше очков, тебе придется научить меня чему-то еще, чего я не знаю. - person Mike Sherrill 'Cat Recall'; 04.05.2012
comment
@Catcall: На самом деле все наоборот: я должен воспользоваться вашим предложением, чтобы улучшить свой ответ. Ориентирован на широкую публику и ОП. Не ожидал найти больше пробелов в ваших обширных знаниях PostgreSQL на сегодняшний день. ;) - person Erwin Brandstetter; 04.05.2012

arrow_upward
5
arrow_downward

Запрос show data_directory; покажет вам основной каталог данных. Но это не обязательно говорит вам, где вещи хранятся.

PostgreSQL позволяет вам определять новые табличные пространства. Табличное пространство — это именованный каталог в файловой системе. PostgreSQL позволяет хранить отдельные таблицы, индексы и целые базы данных в любом допустимом табличном пространстве. Поэтому, если бы база данных была создана в определенном табличном пространстве, я полагаю, что ни один из ее объектов не появился бы в каталоге данных.

Для получения надежной информации во время выполнения о том, где что хранится на диске, вам, вероятно, потребуется запросить pg_database, pg_tablespace или pg_tables из системных каталогов. Информация о табличном пространстве также может быть доступна в представлениях information_schema.

Но для слияния или копирования на жесткий диск использование этих файлов почти наверняка Плохо. Для такой работы pg_dump — ваш друг.

person Mike Sherrill 'Cat Recall'    schedule 03.05.2012

arrow_upward
3
arrow_downward

Если вы говорите о копировании файлов на диске как о форме резервного копирования, вам, вероятно, следует прочитать это, особенно раздел о непрерывном архивировании и восстановлении на момент времени (PITR):

http://www.postgresql.org/docs/current/interactive/backup.html

Если вы думаете о том, чтобы попытаться получить прямой доступ и интерпретировать данные в файлах на диске, минуя систему управления базами данных, это очень плохая идея по многим причинам. Во-первых, схема хранения очень сложная. Во-вторых, он имеет тенденцию меняться в каждом новом крупном выпуске (выпускается один раз в год). В-третьих, призрак Э.Ф. Кодд, вероятно, будет преследовать вас; см. правила 8, 9, 11 и 12 из 12 правил Кодда.

person kgrittn    schedule 03.05.2012