[Comm] 2 разные версии PostgreSQL
Yuri Khachaturyan
yukh на yukh.ru
Чт Фев 6 10:55:51 MSK 2020
Добрый день!
ср, 5 февр. 2020 г. в 22:35, <alexei на taf.ru>:
> Добрый день!
>
> Для справки, pg_upgrade это просто хитрое применение комбинации pg_dump
> и pg_restore из разных версий.
>
То есть при использовании pg_upgrade я не выиграю по времени ничего в
сравнении с pg_dump и pg_restore?
> Есть еще вариант с логической репликацией:
>
> 1. поднимаем логическую репликацию 9.6 -> 11 на стороннем сервере
> (для ускорения синхронизации баз на 11-ю версию заливаем снятый с 9.6
> дамп)
> 2. переклюдчаем пользователей на промежуточный сервер
>
Этим как раз собирался заняться сегодня. Вот только есть вопрос -
обязательно ли логическую репликацию? Я думал о WAL репликации всего
кластера целиком, а не логически каждую базу по-отдельности (баз у меня 35
шт, большинство из них - 1С).
> 3. Проводим обновление СУБД на боевом сервере. И это возможность что-то
> сделать
> с дисковой подсистемой, если это тот самый сервер из предыдущего
> обсуждения.
> RAID5 дает серьезную просадку производительности на запись, и
> маскировка его за
> RAID0 не поможет.
>
Нет, предыдущее обсуждение - это сервер для хранения резервных копий.
Здесь же, на pgsql собран аппаратный RAID10 и к его производительности
претензий нет.
> 4. запускаем логическую репликацию с промежуточного 11 на боевой 11 (тоже
> залив
> предварительно дамп)
> 5. переключаем клиентов.
>
> В результате процесс хоть и протяженной по времени, но простой будет
> только в моменты
> переключения между БД.
>
>
--
С уважением,
Хачатурян Юрий (yukh на yukh.ru)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/community/attachments/20200206/51796c76/attachment.html>
Подробная информация о списке рассылки community