Миграция БД из 8.4 на *nix на win2003

В юниксах сделан бэкап БД через:
pg_dumpall > pgdump.db
(без cжатия .gz2)
архив получился примерно на 80гигов

Пытаюсь его развернуть на вин2003:
C:\Program Files\PostgreSQL\8.4\bin>pg_restore -C -d postgres E:\pgdump.db
pg_restore: [archiver] input file does not appear to be a valid archive

по-другому:
psql < pgdump.db
[..тут много-много восстанавливает..]
CREATE TABLE
ALTER TABLE
CREATE SEQUENCE
ALTER TABLE
ALTER SEQUENCE
setval
--------
1
(1 row)

ALTER TABLE
ALTER TABLE
ERROR: missing data for column "ntseverity"
КОНТЕКСТ: COPY systemevents, line 2368810: "354407099 \N 2011-06-09 23:05
:42 2011-06-09 23:05:42 2 4 server warning: valid_hostname
: invalid ch..."

т.е. опять вылетает с ошибкой.

Пробовал подменить DATA - не прокатывает, ругается на разные версии БД (904 против 836 или как-то так)

Помогите разбэкапить

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Делайте pgdump имя_базы,

Делайте pgdump имя_базы, тогда восстановится думаю через psql
Видимо, когда вы восстанавливаете системную БД, которая template1, PostgreSQL не находит поле ntseverity, потому что вы восстанавливаете UNIX версию на Windows, а для UNIX версии этого поля скорее всего нет.

Единственная проблема - пользователи! Вам нужно будет забакапить пользователей и групп отдельно и отдельно их восстановить.

почему-то не срабатывает =(

почему-то не срабатывает =(

$ psql -l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
----------------+----------+----------+-------------+-------------+-----------------------
base1 | user | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 |

делаю так (под pg_owner):

$ pg_dump -t base1 > db.db
pg_dump: No matching tables were found

Попробовал с другого бока подойти: еще раз подменить /data. Вылезает ошибка:

ожидание запуска сервера...FATAL: invalid value for parameter "lc_monetary": "ru_RU.UTF-8"

А доки по ключам кто читать будет?

Посмотрите, что такое -t

да знаю я )так делал тоже. в

да знаю я )
так делал тоже. в общем еще раз:

делаю:
#pg_dump base > db.db

на другой машине:
c:\> pg_restore: [archiver] input file does not appear to be a valid archive

или так:
psql < base.db

ALTER TABLE
[..]
ALTER TABLE
ERROR: missing data for column "data"
КОНТЕКСТ: COPY bodyparts, line 440: "239838 2317290 aebc471e6a33d44214653b1c
b0ce5a2a Rar!"

или так:
pg_dump base -E win1251 > db.db
вываливается с сообщением, что какой-то там символ нельзя перекодировать.

из pgadmin III бэкап, естественно, тоже не делается

Какие еще есть варианты?

pg_dump создаёт дамп БД в

pg_dump создаёт дамп БД в виде SQL-команд (если не указаны ключи создания в бинарном виде)
Этот дамп загружается обратно в базу через команду psql БАЗА < дамп.sql
Других вариантов предложить не могу. Проверьте ещё раз правильность выполняемых вами действий

может быть это прояснит

может быть это прояснит что-нибудь.. привожу ошибку создания бэкапа из PgAdminIII (правой кнопкой по базе -> резервная копия)

pg_dump.exe -i -h server -p 5432 -U postgres -F c -b -v -f "c:\db.db" base
pg_dump: server version: 8.4.1; pg_dump version: 8.3.0
pg_dump: proceeding despite version mismatch
pg_dump: reading schemas
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: reading procedural languages
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined operator classes
pg_dump: reading user-defined text search parsers
pg_dump: reading user-defined text search templates
pg_dump: reading user-defined text search dictionaries
pg_dump: reading user-defined text search configurations
pg_dump: reading user-defined operator families
pg_dump: reading user-defined conversions
pg_dump: reading user-defined tables
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: column "reltriggers" does not exist
LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
^
pg_dump: The command was: SELECT c.tableoid, c.oid, relname, relacl, relkind, relnamespace, (SELECT

rolname FROM pg_catalog.pg_roles WHERE oid = relowner) as rolname, relchecks, reltriggers,

relhasindex, relhasrules, relhasoids, d.refobjid as owning_tab, d.refobjsubid as owning_col,

(SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace,

array_to_string(c.reloptions, ', ') as reloptions from pg_class c left join pg_depend d on

(c.relkind = 'S' and d.classid = c.tableoid and d.objid = c.oid and d.objsubid = 0 and d.refclassid

= c.tableoid and d.deptype = 'a') where relkind in ('r', 'S', 'v', 'c') order by c.oid
pg_dump: *** aborted because of error

Процесс вернул код выхода 1.

Может у вас база УЖЕ битая?

Может у вас база УЖЕ битая? Тогда было бы понятно - невозможно сделать дамп и как следствие невозможно его восстановить.

дамп делается нормально. база

дамп делается нормально. база - рабочая, не битая. периодические делается VACUUM.

Тогда я не понимаю. Вы

Тогда я не понимаю.
Вы приводите ошибку дампа, потом говорите, что дамп делается нормально.
Ещё раз:
Делаете дамп на одном сервере
1. pg_dump база >dump.sql
Восстанавливаете дамп на другом сервере
2. createdb база
psql база < dump.sql

Да. Ошибки сыпятся при

Да. Ошибки сыпятся при попытке восстановить из сделанного дампа. Дамп делается под линуксами, попытка восстановить из него - на виндах.

вот только craetedb не делал - это принципиально?

А вы в следанном дампе видите

А вы в сделанном дампе видите команду CREATE DATABASE?
Если да, то непринципиально, но вот у меня, например, её нет.
И получается, что если база не создана, то psql начинает воссоздавать всё из дампа на текущей базе данных, которая сама имеет свои таблицы схемы и т.д. Оно вам надо?

смотреть я не стал..

смотреть я не стал.. попробовал еще раз уже с createdb - опять ошибка
ALTER TABLE
ERROR: missing data for column "data"
КОНТЕКСТ: COPY bodyparts, line 440: "239838 2317290 aebc471e6a33d44214653b1c
b0ce5a2a Rar!"

Есть ещё одна очень тупая

Есть ещё одна очень тупая идея, но может действительно дело в этом.
Текстовый формат у UNIX и DOS (WINDOWS) отличается. В UNIX строка заканчивается символом 0x0A, а в DOS и WINDOWS 0x0A,0x0D. Попробуйте полученный в UNIX дамп пропустить через конвертер, который добавит 0x0D. По идее это может как раз влиять на работу команды COPY, которая читает стандартный ввод и если она вместо ожидаемого разделителя строк получит что-то ещё - может начать ругаться.

не подскажите, как это

не подскажите, как это сделать?

Я же сказал - конвертер ищите

Я же сказал - конвертер ищите (перекодировщик). Ну или можете вот так попробовать:

pg_dump база | sed -e 's/$/\r/' >dump.sql

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023