[Comm] 2 разные версии PostgreSQL

alexei на taf.ru alexei на taf.ru
Чт Фев 6 11:12:11 MSK 2020



----- Исходное сообщение -----
> От: "Yuri Khachaturyan" <yukh на yukh.ru>
> Кому: "ALT Linux Community general discussions" <community на lists.altlinux.org>
> Отправленные: Четверг, 6 Февраль 2020 г 15:55:51
> Тема: Re: [Comm]	2 разные версии PostgreSQL

> Добрый день!
> 
> ср, 5 февр. 2020 г. в 22:35, < [ mailto:alexei на taf.ru | 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С).

Потоковая репликация возможна в рамках одной мажорной версии. Не ваш случай. И
для запуска репликации достаточно прописать 35 SQL запросов на стороне публикатора
и еще 35 на стороне подписчика. Не так уж и трудоемко.

> 3. Проводим обновление СУБД на боевом сервере. И это возможность что-то сделать
> с дисковой подсистемой, если это тот самый сервер из предыдущего обсуждения.
> RAID5 дает серьезную просадку производительности на запись, и маскировка его за
> RAID0 не поможет.
> Нет, предыдущее обсуждение - это сервер для хранения резервных копий. Здесь же,
> на pgsql собран аппаратный RAID10 и к его производительности претензий нет.
> 
> 
> 
> 4. запускаем логическую репликацию с промежуточного 11 на боевой 11 (тоже залив
> предварительно дамп)
> 5. переключаем клиентов.
> 
> В результате процесс хоть и протяженной по времени, но простой будет только в
> моменты
> переключения между БД.


Подробная информация о списке рассылки community