Есть ли какие-либо отрицательные недостатки в производительности или функциональности при использовании pg_upgrade с опцией --link?

Question

Я собираюсь обновить довольно большой кластер PostgreSQL с 9.3 до 11.

Обновление

Размер кластера составляет около 1,2 ТБ. База данных имеет дисковую систему, состоящую из быстрого массива HW RAID 10 из 8 твердотельных накопителей DC-издания с 192 ГБ оперативной памяти и 64 ядрами. Я выполняю обновление, реплицируя данные на новый сервер с потоковой репликацией, а затем обновляю его до 11.

Я протестировал обновление, используя pg_upgrade с --link вариант, это займет не более минуты. Я также регулярно проверял обновление (без --link) с большим количеством рабочих мест, что занимает несколько часов (+4).

Вопросы

Теперь у меня есть очевидный выбор: --link вариант, однако все это заставляет меня задуматься - есть ли какие-либо недостатки (с точки зрения производительности или функциональности) по сравнению с обычным более медленным методом? Я не знаю внутреннюю работу структур данных postgresql, но у меня есть ощущение, что после обновления может возникнуть разница в производительности между полной перезаписью данных и просто использованием hard links - что бы это ни значило?

Соображения

Единственное что я могу найти в документации про недостатки --link Недостатком является невозможность доступа к старому каталогу данных после выполнения обновления. https://www.postgresql.org/docs/11/pgupgrade.htm Однако это всего лишь проблема безопасности, а не недостаток производительности. Это действительно применимо в моем случае репликации данных в первую очередь. Единственное, о чем я могу думать, это освободить пространство, с какими бы ни были улучшениями производительности. Однако, насколько я понимаю, это также может быть достигнуто путем запуска VACUUM FULL DATABASE (или же CLUSTER?) команда после --link база данных была обновлена? Также, как я понимаю, освобождение места не очень влияет на производительность SSD.

Я ценю, если кто-нибудь может помочь пролить свет на это.

Answer 1

Нет абсолютно никаких недостатков в использовании жестких ссылок (за исключением того, что вы отметили, что старый кластер мертв и должен быть удален).

Жесткая ссылка ничем не отличается от обычного файла.

"Файл" в UNIX на самом деле является "индексом", структурой, содержащей метаданные файла. Запись в каталоге является (жесткой) ссылкой на этот индекс.

Если вы создадите еще одну жесткую ссылку на inode, один и тот же файл будет находиться в двух разных каталогах, но это никак не повлияет на поведение файла.

Конечно, вы должны убедиться, что вы не запускаете как единственный, так и новый сервер. Это приведет к мгновенному повреждению данных. Вот почему вы должны удалить старый кластер как можно скорее.