Что делать, если после pg_upgrade с использованием опции жестких ссылок есть два каталога табличного пространства

Некоторое время назад я запустил pg_upgrade PostgreSQL в базе данных PG11 до PG12, в которой есть табличное пространство, расположенное в /ssd.

Я использовал опцию --link в своей команде для создания жестких ссылок, чтобы не удваивать пространство, поскольку это огромная база данных.

К сожалению, я не удалил старый кластер после обновления.

С тех пор прошло несколько месяцев, и мы хотели сейчас перейти на PG15, но я заметил, что внутри /ssd все еще используются PG_11_201809051 и PG_12_201909212, с очень недавними датами изменения некоторых файлов в обоих каталогах.

При проверке наличия файлов я заметил, что в PG_11_201809051 есть файлы, которых нет в PG_12_201909212, и наоборот.

Итак, мой вопрос: если я сейчас обновлюсь до PG15, безопасно ли оно возьмет все необходимое из обоих этих каталогов и переместит все это в новый каталог PG_15 в /ssd?

Если нет, какие варианты я могу обеспечить успешное обновление и удаление старых кластеров?

Пробовал: Запустил обновление PostgreSQL с PG11 до PG12.

Ожидаемый результат: Ничего из PG11 больше не будет использоваться.

Фактический результат: PG_11_201809051 по-прежнему используется вместе с PG_12_201909212 в каталоге /ssd.

Конфигурация Postgres для табличного пространства:

temp_tablespaces = 'ssd'

Табличное пространство изначально было создано так:

CREATE TABLESPACE ssd OWNER postgres LOCATION '/ssd';
$ ls -lh /data/pg12/pg_tblspc/
total 0
lrwxrwxrwx. 1 postgres postgres 4 Jun 16  2023 16412 -> /ssd


$ ls -lh /ssd/
total 0
drwx------. 2 postgres postgres  6 Mar  6  2021 lost+found
drwx------. 4 postgres postgres 36 May 26  2023 PG_11_201809051
drwx------. 4 postgres postgres 36 Jun 17  2023 PG_12_201909212
 $ tree -d /ssd  
/ssd
 ├── lost+found
 ├── PG_11_201809051
 │   ├── 16420
 │   └── pgsql_tmp
 └── PG_12_201909212
     ├── 16414
     └── pgsql_tmp

Под «табличным пространством» вы подразумеваете явное табличное пространство или это просто каталог? Возможно, будет полезно поделиться дампом структуры каталогов вашей базы данных с tree -d /ssd.

Richard Huxton 08.03.2024 09:19

Я скопировал дерево в ваш основной вопрос + отформатировал его. Правильно ли я изложил?

Richard Huxton 08.03.2024 09:25

Идеально, да. Извините, я новичок в Stack Overflow:/

Keith2709 08.03.2024 09:26
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
3
126
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Вероятно, вам лучше изучить это в списке рассылки или в чате — многое зависит от деталей.

Мне кажется, вы просто не отвязали старую установку после перехода. Это последний шаг в инструкциях pg_upgrade, и его легко пропустить. («16. Удалить старый кластер»).

Позвольте мне показать вам небольшой пример с жесткими ссылками:

$ date > foo
$ date > bar
$ ln bar baz
$ ls -l
total 12
-rw-rw-r-- 2 richard richard 29 Mar  8 08:28 bar
-rw-rw-r-- 2 richard richard 29 Mar  8 08:28 baz
-rw-rw-r-- 1 richard richard 29 Mar  8 08:28 foo
# wait for a couple of minutes...
$ date > bar
$ ls -l
total 12
-rw-rw-r-- 2 richard richard 29 Mar  8 08:29 bar
-rw-rw-r-- 2 richard richard 29 Mar  8 08:29 baz
-rw-rw-r-- 1 richard richard 29 Mar  8 08:28 foo

Вы можете увидеть «2» для связанных файлов и «1» для файла, на который нет ссылок. Кроме того, временные метки связаны, поскольку на самом деле это один и тот же файл.

Итак, проверьте номер ссылки на эти, возможно, дублированные файлы табличного пространства, а также проверьте, что stat говорит о них. Если это действительно копии, вы можете быть в безопасности unlink с ними.

У вас также могут быть старые связанные файлы, например /var/lib/postgresql/12/... (расположение будет зависеть от ваших настроек).

ПРИМЕЧАНИЕ. Лично я бы остановил postgresql и перед этим сделал полную резервную копию всех файлов файловой системы. Это зависит от того, сколько у вас данных, насколько они важны, наличия недавних резервных копий и т. д.

Я попробую. Большое спасибо! Ценить это

Keith2709 08.03.2024 10:46

Другие вопросы по теме