Последние 8 часов я пытался импортировать вывод «mysqldump --compatible = postgresql» в PostgreSQL 8.4.9, и я прочитал по крайней мере 20 различных потоков здесь и в других местах уже об этой конкретной проблеме, но не нашел реальный полезный ответ, который работает.
MySQL 5.1.52 сбрасывает данные:
mysqldump -u root -p --compatible=postgresql --no-create-info --no-create-db --default-character-set=utf8 --skip-lock-tables rt3 > foo
Сервер PostgreSQL 8.4.9 в качестве места назначения
Загрузка данных с помощью 'psql -U rt_user -f foo' сообщает (многие из них, вот один пример):
psql:foo:29: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
Согласно следующему, во входном файле нет символов NULL (0x00).
database-dumps:rcf-temp1# sed 's/\x0/ /g' < foo > nonulls
database-dumps:rcf-temp1# sum foo nonulls
04730 2545610 foo
04730 2545610 nonulls
database-dumps:rcf-temp1# rm nonulls
Аналогично, другая проверка с Perl не показывает NULL:
database-dumps:rcf-temp1# perl -ne '/\000/ and print;' foo
database-dumps:rcf-temp1#
Как упоминается в разделе «СОВЕТ» в сообщении об ошибке, я пытался всеми возможными способами установить «client_encoding» в «UTF8», и мне это удалось, но это никак не отразилось на решении моей проблемы.
database-dumps:rcf-temp1# psql -U rt_user --variable=client_encoding=utf-8 -c "SHOW client_encoding;" rt3
client_encoding
-----------------
UTF8
(1 row)
database-dumps:rcf-temp1#
Идеально, но:
database-dumps:rcf-temp1# psql -U rt_user -f foo --variable=client_encoding=utf-8 rt3
...
psql:foo:29: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
...
За исключением правильного ответа «Согласно Хойлу», который было бы замечательно услышать, и зная, что я действительно не забочусь о сохранении каких-либо не-ASCII символов для этих редко упоминаемых данных, какие у вас есть предложения?
Обновление: я получаю ту же ошибку с версией файла дампа только для ASCII во время импорта. Поистине ошеломляющий:
database-dumps:rcf-temp1# # convert any non-ASCII character to a space
database-dumps:rcf-temp1# perl -i.bk -pe 's/[^[:ascii:]]/ /g;' mysql5-dump.sql
database-dumps:rcf-temp1# sum mysql5-dump.sql mysql5-dump.sql.bk
41053 2545611 mysql5-dump.sql
50145 2545611 mysql5-dump.sql.bk
database-dumps:rcf-temp1# cmp mysql5-dump.sql mysql5-dump.sql.bk
mysql5-dump.sql mysql5-dump.sql.bk differ: byte 1304850, line 30
database-dumps:rcf-temp1# # GOOD!
database-dumps:rcf-temp1# psql -U postgres -f mysql5-dump.sql --variable=client_encoding=utf-8 rt3
...
INSERT 0 416
psql:mysql5-dump.sql:30: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encod.
INSERT 0 455
INSERT 0 424
INSERT 0 483
INSERT 0 447
INSERT 0 503
psql:mysql5-dump.sql:36: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encod.
INSERT 0 502
INSERT 0 507
INSERT 0 318
INSERT 0 284
psql:mysql5-dump.sql:41: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encod.
INSERT 0 382
INSERT 0 419
INSERT 0 247
psql:mysql5-dump.sql:45: ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encod.
INSERT 0 267
INSERT 0 348
^C
Одна из рассматриваемых таблиц определяется как:
Table "public.attachments"
Column | Type | Modifie
-----------------+-----------------------------+--------------------------------
id | integer | not null default nextval('atta)
transactionid | integer | not null
parent | integer | not null default 0
messageid | character varying(160) |
subject | character varying(255) |
filename | character varying(255) |
contenttype | character varying(80) |
contentencoding | character varying(80) |
content | text |
headers | text |
creator | integer | not null default 0
created | timestamp without time zone |
Indexes:
"attachments_pkey" PRIMARY KEY, btree (id)
"attachments1" btree (parent)
"attachments2" btree (transactionid)
"attachments3" btree (parent, transactionid)
У меня нет свободы изменять тип для какой-либо части схемы БД. Это может повредить будущие обновления программного обеспечения и т. Д.
Вероятный проблемный столбец - это «содержимое» типа «текст» (возможно, другие в других таблицах). Как я уже знаю из предыдущего исследования, PostgreSQL не допустит NULL в «текстовых» значениях. Тем не менее, смотрите выше, где sed и Perl не показывают NULL-символов, а затем далее, где я удаляю все не-ASCII-символы из всего файла дампа, но это все еще barfs.
источник
head -29 foo | tail -1 | cat -v
может быть полезным.Ответы:
Одно или несколько из этих символьных / текстовых полей МОГУТ иметь 0x00 для своего содержимого.
Попробуйте следующее:
Если это возвращает какую-либо строку, попробуйте обновить эти символьные / текстовые поля:
Затем попробуйте другой MYSQLDUMP ... (и метод импорта PostgreSQL).
источник
colname LIKE concat('%', 0x00, '%')
. Нашел их в полях, содержащих сериализованные массивы PHP.У меня была та же проблема с использованием MySQL версии 5.0.51 и Postgres версии 9.3.4.0. Я решил проблему «недопустимой последовательности байтов для кодирования« UTF8 »: 0x00» после того, как увидел комментарий Даниэля Верите о том, что «mysqldump в режиме postgresql будет выводить нулевые байты как \ 0 в строках, так что вы, вероятно, захотите найти эту последовательность символов».
Конечно же, grep наконец-то показал NULL-символы.
Я заменил NULL-символы, используя следующую команду
После этого Postgres смог успешно загрузить dump.sql
источник
Вы можете получить эту ошибку без какого-либо NULL-байта или любого не-ascii символа в файле. Пример в базе данных utf8:
будет давать:
mysqldump в режиме postgresql будет сбрасывать нулевые байты как \ 0 в строках, поэтому вы, вероятно, захотите найти эту последовательность символов.
источник
Я наполовину помню такую проблему. Я думаю, что я закончил миграцию схемы, затем выгрузил данные как csv и загрузил данные из файла csv. Я помню, что мне приходилось обновлять файл csv (используя инструменты Unix, такие как sed или unixtodos) или использовать open office calc (excell), чтобы исправить некоторые элементы, которые были ошибками на этапе импорта - это может быть так же просто, как открыть и повторно сохранить файл.
источник