[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