Всем доброе время суток !

Ситуация следующая.

Есть база 1С работающая на Postgres 9.1.9
База БОЛЬШАЯ (более 100 Гб).
Предприятие работает практически 24/7 (перерыв в работе базы возможен на час-два).

Есть желание перейти на Postgres 9.4
Но есть проблема - бэкап базы с предыдущей версии Postgres не поднимается на более старшей версии.

Выгрузка - загрузка базы через DT займет очень долгое время.

У кого есть опыт перевода базы на другую версию Postgres просьба подсказать что можно использовать еще.

УРИБ

Делаешь копию на новом серваке, настраиваешь УРИБ, загружаешь измененные, прописываешь пользователям новые параметры, отвязываешь от УРИБ

Формирование узла уриб блокирует базу.
Выгрузка измененных блокирует базу

Обратитесь в постгре про, они помогут понять почему бэкап не поднимается

Может и патч какой выпустят

(3) я про Книга знаний: Альтернативное создание начального образа в УРБД

(3) нет

(4) нет

(7) да

Требуется монопольный режим для создания нового узла

(0) Проблема известная. Из-за нее (в том числе) Uber недавно свалил с Posgre на MySQL. В 9.5 добавили механизм для такой миграции.

1С рекомендует для 24x7 систем мигрировать через репликацию обменом, аналогично переходу с 8.1 и 8.0.

(10) Зачем?

(11) Правда готового механизма по такой миграции 1с не предоставляет

Пилить ВыгрузкаЗагрузкаXML или другую сериализацию. Для допереноса свежих изменений создать полный план обмена (РИБ не обязательно).

Кстати ,например, для больших независимых регистров сведений  использовал ВыгрузитьЗначениеВФайл/ЗагрузитьЗначениеИзФайла. Получалось быстрее чем через XML.

В Новогодние праздники сделать выгрузку/загрузку.

(15) и если не получится, то еще на год зависнуть?

Какая "загрузка базы через DT" при размере в 100 Гб???

Если dt

Если dt в принципе выгружается/загружается, можно создать копию на старой БД, выгрузить dt, загрузить в новую. А потом допереносить через XML по плану обмена.

(11) http://eax.me/postgresql-replication/

(0) Обратись к этим (https://postgrespro.ru/products/1c_build) ребятам. Они должны помочь.

Только не надо говорить, что у автора нет ежедневного создания бэкапов. Вы говорите что он и не говорил? А, ну, тогда всё гораздо проще: РИБ с альтернативным созданием начального образа из бэкапа.

Перед созданием очередного бэкапа, в рабочей базе добавить узел в план обмена. С этого момента начинается регистрация изменений.

Потом, за день/два/три, - короче не спеша, развёртываешь из бэкапа базу, выгружаешь и загружаешь в базу на новой версии и после этого настраиваешь обмен данными между рабочей и этой новой базой. Всё, новая база в любой момент готова занять место рабочей базы.

Еще вариант не разворачиванием бэкапа, а миграцией с одной версии на другую.
https://tresnet.ru/archives/1278

(22) Чукча не читатель?

Чукча графоман :) Более подробно расписал с акцентом, что процесс может не быть жёстко лимитирован по времени.

(25) Бэкап то не разворачивается

(26) Вам же от меня же по тому же месту - см. (24)

В (0) автор сказал "Выгрузка - загрузка базы через DT займет очень долгое время." - выгрузку/загрузку можно делать из бэкапа, поднятого рядом с рабочей базой и не переживать за потерянное время (то, что данные устаревают).

для 100гб базы выгрузка/загрузка в дт скорее всего совсем не пройдет

(26) Он предложил выгрузку, читай внимательнее.

(28) Чисто теоретически рассуждая, из принципа, я могу создать копию рабочей базы не используя ни выгрузку в .DT, ни создание начального образа (в т.ч. альтернативного) - только РИБ и ничего лишнего.

Можно многое умеючи...:) Помнится, восстанавливали базу: умер центр, бекап был недельной давности и была кучка живых переферийных баз и обмен с ними естественно не полный...

на хабре есть статья обновы 100гиг постгре 24/7

(28) И 500гб пройдет - проверено.

Вот здесь еще есть про переход на новую версию https://postgrespro.ru/docs/postgrespro/9.5/upgrading

делаем архив, разворачиваем копию на новой версии, всех резко туда перекидываем, а разницу перенести через выгрузкузагрузкухмл

Взял очень старый бэкап, сделанный на 9.1.9, восстановил при помощи pg_restore в 9.4.2 и в 9.5.4(для пробы). В обоих случаях восстановилось нормально, никаких ошибок и предупреждений не выдавалось, в базу можно зайти и работать. ТиИ выполняется, выгрузка/загрузка ИБ  тоже, документы открываются/сохраняются, отчеты формируются. База, конечно, пустяк, около 4 ГБ в PostgreSQL.
Непонятно, что именно у автора темы не пошло при восстановлении.

Вот тут обещают разобрать подобные вопросы: http://event.infostart.ru/2016/#item545008 правда, придется либо самому послушать, вроде есть видеотрансляция. Либо год подождать, пока в открытом доступе появится видео доклада. Возможно транскрибация будет раньше.

(0) Какая версия платформы? Откуда брался дистрибутив? ОС под которой запущен SQL сервер?

Проблема в том, что сервер 1С под старые и новые версии платформы 1С требует разных опций сборки Postgresql. Postgresql  9.1 (и более старые) от 1С собрана под старые платформы 1С (8.2 плюс первые 8.3) а 9.4 под новые (все последние 8.3). В принципе оно обходится, КМК под Linux попроще, под Windows посложнее. Если вы берёте ванильную Postgresql и патчи от 1С то вы в любом случае можете собрать то что вам нужно. Но сам я этого не делал.

P.S. Смысл смены версии? В связке с 1С переход на новую версию SQL производительность не повышает.

(38) Правильнее было бы:"проблема ВОЗМОЖНО в том, что сервер 1С..."
Если бэкап не удаётся восстановить то это одно. Если восстановить удаётся но база не работоспособна то это другое.