Некоторое время назад я запустил 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
Я скопировал дерево в ваш основной вопрос + отформатировал его. Правильно ли я изложил?
Идеально, да. Извините, я новичок в Stack Overflow:/
Вероятно, вам лучше изучить это в списке рассылки или в чате — многое зависит от деталей.
Мне кажется, вы просто не отвязали старую установку после перехода. Это последний шаг в инструкциях 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 и перед этим сделал полную резервную копию всех файлов файловой системы. Это зависит от того, сколько у вас данных, насколько они важны, наличия недавних резервных копий и т. д.
Я попробую. Большое спасибо! Ценить это
Под «табличным пространством» вы подразумеваете явное табличное пространство или это просто каталог? Возможно, будет полезно поделиться дампом структуры каталогов вашей базы данных с
tree -d /ssd
.