SQL 덤프에서 데이터베이스를 복원하는 동안 바이너리 모드 활성화

저는 MySQL을 처음 접했고 Windows에서 실행하고 있습니다. MySQL의 덤프 파일에서 데이터베이스를 복원하려고하는데 다음 오류가 발생합니다.

$ >mysql -u root -p -h localhost -D database -o < dump.sql
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'SQLite format 3'.

--binary-modeini 파일 을 넣으려고 시도 했지만 여전히 동일한 오류가 발생합니다. 어떻게해야합니까? 도와주세요.

최신 정보

Nick이 그의 의견에서 제안한 것처럼 시도 $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sql했지만 다음과 같은 결과를 얻었습니다 ERROR at line 1: Unknown command '\☻'. . 500 Mb 덤프 파일이며 gVIM을 사용하여 내용을 보면 이해할 수없는 표현과 데이터 만 볼 수 있습니다.

파일의 압축을 푼 다음 다시 가져옵니다.

덤프 파일을 복원하는 Windows에서 동일한 문제가 발생합니다. 내 덤프 파일은 다음과 같이 Windows powershell 및 mysqldump로 생성되었습니다.

mysqldump db > dump.sql

문제는 powershell의 기본 인코딩이 UTF16으로 인해 발생합니다. 더 자세히 살펴보기 위해 GNU의 "파일"유틸리티를 사용할 수 있으며 여기에 Windows 버전이 있습니다 .
내 덤프 파일의 출력은 다음과 같습니다.

CRLF 줄 종결자가있는 매우 긴 줄이있는 Little-endian UTF-16 유니 코드 텍스트입니다.

그런 다음 코딩 시스템의 변환이 필요하며이를 수행 할 수있는 다양한 소프트웨어가 있습니다. 예를 들어 emacs에서

M-x set-buffer-file-coding-system

그런 다음 utf-8과 같은 필요한 코딩 시스템을 입력하십시오.

그리고 앞으로 더 나은 mysqldump 결과를 얻으려면 다음을 사용하십시오.

mysqldump <dbname> -r <filename>

출력은 mysqldump자체적 으로 처리 되지만 powershell의 리디렉션이 아닙니다.

참조 : /dba/44721/error-while-restoring-a-database-from-an-sql-dump

Windows 컴퓨터에서 이전 단계를 따르십시오.

1. 메모장에서 파일을 엽니 다.
2. 다른 이름으로 저장을 클릭하십시오.
3. 인코딩 유형 UTF-8을 선택합니다.

이제 db를 소싱하십시오.

Tar 아카이브 도구를 사용하여 파일을 추출하십시오. 다음과 같이 사용할 수 있습니다.

tar xf example.sql.gz

Notepad ++ (또는 다른 편집기)에서 열고 UTF-8로 변환 / 저장해 보셨습니까?

참조 : 메모장 ++ ansi 인코딩 파일을 utf-8로 변환

또 다른 옵션은 textwrangle을 사용하여 파일을 UTF-8로 열고 저장하는 것입니다. http://www.barebones.com/products/textwrangler/

다음 mysqldump과 같이 Windows PowerShell에서 실행 한 후이 오류가 한 번 발생했습니다 .

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF > db_objects.sql

내가 한 일은 이것을 다음과 같이 변경하는 것입니다 (Set-Content 대신 파이프).

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF | Set-Content db_objects.sql

그리고 문제는 사라졌습니다!

dump.sql에 파일 시작 부분에 가비지 문자가 있거나 시작 부분에 빈 줄이있을 수 있습니다.

공간이 충분하지 않거나 압축을 푸는 데 시간을 낭비하지 않으려면이 명령을 시도하십시오.

gunzip < compressed-sqlfile.gz | mysql -u root -p

compression-sqlfile.gz를 압축 파일 이름으로 바꾸는 것을 잊지 마십시오.

.gz 복원은 위에서 제공 한 명령 없이는 작동하지 않습니다.

파일은 dump.sql 문제 여야합니다. Sequel Pro를 사용하여 파일 ecoding을 확인합니다. dump.sql의 가비지 문자 여야합니다.

나는 같은 문제가 있었지만 덤프 파일이 실제로 MySQL이 아닌 MSSQL Server 백업이라는 것을 알았습니다.

때로는 레거시 백업 파일이 우리를 속이는 경우가 있습니다. 덤프 파일을 확인하십시오.

터미널 창에서 :

~$ cat mybackup.dmp 

결과는 다음과 같습니다.

TAPE??G?"5,^}???Microsoft SQL ServerSPAD^LSFMB8..... etc...

cat 명령 처리를 중지하려면 다음을 수행하십시오.

CTRL + C

zcat /path/to/file.sql.gz | mysql -u 'root' -p your_database

가져 오려는 파일은 zip 파일입니다. 파일의 압축을 풀고 다시 가져 오십시오.

Linux에서 gunzip을 사용하여 파일 압축을 풉니 다.

vi unzipsqlfile.sql

esc dd를 사용하여 첫 번째 바이너리 줄을 제거하고 esc shift g를 사용하여 파일 맨 아래로 이동합니다. dd를 사용하여 마지막 바이너리 줄을 제거합니다. esc x 파일을 저장합니다. 그런 다음 다음을 사용하여 mysql로 ​​다시 가져옵니다.

mysql -u 사용자 이름 -p new_database <unzipsqlfile.sql

jetbackup cpanel mysql 백업의 20go sql 파일로 수행했습니다. vi가 큰 파일에 대한 작업을 수행하기를 기다리십시오.

파일 확장자는 .sql이어야하며 (.zip, .gz .rar) 등은 지원하지 않습니다. 예 : dump.sql

이것을 사용하여 오류를 수정할 수 있습니다.

zcat {address_sql_database(.tar.gz)} | mysql -u root -p {database_name} --binary-mode

원래 포스터 질문이 해결되었음을 알고 있지만 Google을 통해 여기에 왔고 다양한 답변을 통해 결국 SQL이 가져 오기에 사용 된 것과 다른 기본 문자 집합으로 덤프되었다는 사실을 알게되었습니다. 원래 질문과 동일한 오류가 발생했지만 덤프가 다른 MySQL 클라이언트로 파이프되었으므로 다른 도구로 열어서 다르게 저장하는 경로를 갈 수 없었습니다.

우리에게 솔루션은를 통해 가져 오는 호출뿐만 아니라 --default-character-set=utf8mb4의 호출에도 사용할 수있는 옵션으로 밝혀졌습니다 . 물론, 매개 변수의 값은 동일한 문제에 직면 한 다른 사람들에 따라 다를 수 있습니다. 서버 (또는 도구) 기본 설정이 임의의 문자 집합 일 수 있으므로 동일하게 유지하는 것이 중요합니다.mysqldumpmysql

오래되었지만 금!

내 이름을 변경했다 : 맥 OS (카탈 10.15.7)에 그것은 조금 이상한 dump.sql로를 dump.zip그리고 그 후, 나는 그것을 압축 해제 파인더 사용했다 (!). 단말기에 unzip dump.zip데르tar xfz dump.sql[or .gz .tar ...] 는 오류 메시지로 이어집니다.

마지막으로 파인더는 파일을 문제없이 가져올 수 있으므로 압축을 완전히 풀었습니다.