Всем привет. Можете чисто теоритически посоветовать как ускорить миграцию? Переезд кластера postgresql10

размером 3,5 Тб c Ubuntu 10.8 на redhat 7
Имеем 2 инстанса на разных портах на Ubuntu (2 Тб с 53_мя БД и 1,5 Тб с 1_ой БД),
надо все это смигрировать в один кластер в redhat
Задумка была такова:
1. Останавливаем все сервисы на 2_ух терабайтном кластере
2. Делаем полный дамп и загружаем его на другом сервере.
Со второго инстанса снимаем скрит с ролями, а затем делаем дамп БД
a) 'экспорт'
pg_dumpall -p 5454 -s | gzip -c | ssh pgХХХ 'gunzip -c > /optx/dumpall.sql'
pg_dumpall -p 5455 -r | gzip -c | ssh pgХХХ 'gunzip -c > /optx/role.sql'
pg_dump -p 5455 -d <db> | ssh pgXXX 'pg_restore -d db -j 12 /optx/<DB>.sql'
б) 'импорт'
psql -f /optx/dumpall.sql
psql -f /optx/role.sql
pg_restore -d db -j 12

выгрузка и копирование дампа (dumpall) заняла 4 часа
Загрузка полного дампа заняла 13,5 часов

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

Спасибо. Вопрос, расположение базы данных в разных каталогах повлияет как-то на логическую репликацию? И второе. Придется на каждую БД создавать подписку?

А физической репликацией / backup не получится (они несовместимы, да?)? Просто уточняю.

Вот мой ответ на похожый вопрос, который мне пока что нравится: https://t.me/pgsql/335316 Там, правда, про downtime, а не про скорость как таковую.

А, не посмотрел, что вы ещё и реально изменяете расположэние данных. Тогда могу, чисто теоретически, делать слияние на одном сервере. То есть загрузить всё как есть, а потом вливать второй в первый. Но вообще, конечно, кардинальные изменения структуры не делаются просто, и это нормально.

Я не проверял, т.к. другая ОС, другое расположение данных + как я писал барман бэкапит около 10 часов, значит восстановление 5-6 часов. А это одно и тоже время

> т.к. другая ОС Там не так уж много ключевых моментов (архитектура, locales) — можно было бы посмотреть / проверить. > другое расположение данных В смысле? В data directory же всё равно расположение одинаковое (где-то выносят config-и и log-и, но это мелочи)? > как я писал барман бэкапит около 10 часов А как так выходит, что дамп у Вас снимается быстрее, чем backup? Много индексов (или mat.views)?

Железо. И его никто менять не будет

> Имеем 2 инстанса на разных портах на Ubuntu (2 Тб с 53_мя БД и 1,5 Тб с 1_ой БД), > надо все это смигрировать в один кластер в redhat А, увидел, извините.

> как я писал барман бэкапит около 10 часов, значит восстановление 5-6 часов. А это одно и тоже время Хотя это к конкретной задаче мало относится — Вы тут что-то сильно путаете. ;) "Восстановление" backup-а, снятого с кластера, который не находится под нагрузкой, всегда происходит практически мгновенно (потому что это просто запуск PostgreSQL на указанной data directory, а время recovery мало, т.к. только что был checkpoint, и WAL для "накатывания" больше нет). А по вопросу — почему Вы пытаетесь минимизировать время миграции, а не downtime, как это обычно делают, в самом деле?

Для меня это одно и тоже. Остановка сервисов будет осуществлена на время проведения работ и хотелось бы уложиться за ночь

Я бы не сказал, что происходит мгновенно (восстановление бэкапа). Конечно 5-6 часов я загнул, но за 2-3 часа не меньше.

Ну, чтобы тэрабайт восстановился за 15 минут -- нужна скорость записи в гигабайт/секунду. И скорость чтения с (другого) носителя с бэкапом такая жэ. Это ужэ не мгновенно, и это на довольно приличном жэлезе.

Да, но зачем вообще в этой задаче этап с другими носителями? Я бы ожидал, что pg_basebackup (или аналог) будет выполняться сразу в целевую data directory. И тогда время "восстановления" — околонулевое.

Можно ещё подумать чтобы восстанавливать бэкап в процэссе переливки, при помощи tee или tail -f .

Ну а я бы сказал, см. https://t.me/pgsql/337760 . ;)

Нашел логи восстановления 400 Гб бэкапа. Кусочек лога:IMPORTANT These settings have been modified to prevent data losses postgresql.conf line 709: archive_command = false postgresql.auto.conf line 3: recovery_target_timeline = None WARNING You are required to review the following options as potentially dangerous postgresql.conf line 65: unix_socket_directories = '/var/run/postgresql, /tmp' # comma-separated list of directories Recovery completed (start time: 2020-12-23 09:26:55.649496, elapsed time: 56 minutes, 27 seconds) Your PostgreSQL server has been successfully prepared for recovery!

Тожэ вариант.

Так вариант с логической репликацией как раз и используют, чтобы разделить downtime и время миграции. Т.е. кому какое дело, что DBA что-то там настроил, и оно работает себе день, или даже неделю? С т.з. пользователей только нагрузка на базу возросла, и всё. А вот когда "оно" (логическая репликация) отработает (синхронизируется), за ней следует очень быстрая миграция.

Я чуток не понял, basebackup отработает и перенесет мне инстанс с унбунту на ред хат?

Так Вы же написали, что железо несовместимо, я правильно понял? Если в самом деле так — нет, не перенесёт. :(

В общем -- да. Правда, все индэксы текстовых полей, для которых имеет смысл collation -- лучшэ будет переиндэксировать. Но это только на ту жэ мажорную версию postgres, плюс никаких слияний баз.

К сожалению мажорные версии тоже будут отличаться. На ред хате 10.18, на другой 10.8

Это минорные. ;)

Это одна версия, там начиная как раз с 10 -- стало играть роль только первое число.

очепятался. Вы рекомендуете мне настроить логическую репликацию? Я правильно Вас понял?

1) Не то, чтобы я что-то рекомендую. Чтобы давать рекомендацыи в таких вещах мне, разумеется, надо гораздо лучшэ понимать вашу ситуацыю. Жэлательно погрузиться в это дело, выписать требования, оцэнить возможности, прикинуть риски. А тут я так, вспоминаю свой былой опыт помаленьку. 2) Логическая репликацыя (любая из трёх) -- действительно можэт свести к минимуму даунтайм, да и риски того, что что-то пойдёт не так и выйдет за отведенное время. Довольно безопасное решэние. Но у неё, конечно, потребуется поработать на настройку и проверку, что всё работает. Одно перечисление таблиц некоторое время займёт. Схемы, опять жэ, руками заливать. В случае встроенной репликацыи -- скрипты для обновления sequence. А если в таблицах есть row security -- то по-моему вообще всё будет тяжко.

Спасибо БОЛЬШОЕ. С логической репликацией знаком (создавал ее на 3 серверах и опплевался) Это муторное и очень долгое занятие, еще если не будет первичных ключей, то ... Я пока исхожу из того, чтобы мне как меньше было работы. Еще раз сасибо.

Кстати, Вы не в курсе? Логическую репликацию можно создать на весь кластер, а не по БД и их схемам?

Вряд ли. Точнее, по схемам-то необязательно -- одна публикацыя можэт передавать сколько угодно таблиц в разных схемах. И одна подписка. А вот на каждую базу данных -- всё своё, конечно, должно быть.

Зачем удалять индексы? Ничего не понятно