대용량 SQL 덤프 (2GB)를 Mac의 로컬 mysql로 가져 오려고합니다. 과거 에이 작업을 수행 할 수 있었지만 (MAMP를 사용 중임) 이제 7758 줄에 ERROR 2006 (HY000)이 표시됩니다. 덤프를 가져올 때마다 MySQL 서버가 사라졌습니다. 데이터베이스는 innodb 테이블을 포함합니다.
my-innodb-heavy-4G.cnf 파일을 my.cnf로 복사하여 해당 설정이 도움이되는지 확인했지만 운이 없었습니다.
조정할 내용에 대한 아이디어가 있습니까?
"Mac OS X 버전 10.6 (x86, 64 비트), DMG 아카이브"를 여기에서 사용하고 있습니다. http://dev.mysql.com/downloads/mysql/
답변:
MySQL Connections의 자동 킬러 중 하나는 MySQL Packet입니다. MySQL 복제의 I / O 스레드조차도 이로 인해 피해를 입을 수 있습니다.
MySQL 문서 에 따르면
올바르지 않거나 너무 큰 서버로 쿼리를 보내면 이러한 오류가 발생할 수도 있습니다. mysqld가 너무 크거나 순서가 잘못된 패킷을 받으면 클라이언트에 문제가 있다고 가정하고 연결을 닫습니다. 큰 쿼리가 필요한 경우 (예 : 큰 BLOB 열을 사용하는 경우) 기본값이 1MB 인 서버의 max_allowed_packet 변수를 설정하여 쿼리 제한을 늘릴 수 있습니다. 클라이언트 쪽에서 최대 패킷 크기를 늘려야 할 수도 있습니다. 패킷 크기 설정에 대한 자세한 내용은 C.5.2.10 절.“패킷이 너무 큼”에 나와 있습니다.
많은 행을 삽입하는 INSERT 또는 REPLACE 문도 이러한 종류의 오류를 일으킬 수 있습니다. 이 명령문 중 하나는 삽입 될 행 수에 관계없이 단일 요청을 서버로 보냅니다. 따라서 INSERT 또는 REPLACE 당 전송되는 행 수를 줄임으로써 종종 오류를 피할 수 있습니다.
최소한 mysqldump'd에서 온 머신과로드하는 머신의 패킷 크기가 동일해야합니다.
취할 수있는 두 가지 접근 방식이있을 수 있습니다.
접근법 # 1 : --skip-extended-insert를 사용하여 mysqldump를 수행
이렇게하면 MySQL 패킷에 여러 BLOB, TEXT 필드가 넘치지 않게됩니다. 이렇게하면 SQL INSERT가 한 번에 하나씩 수행됩니다. 주요 단점은
접근법 # 2 : max_allowed_packet 증가
이것을 구현하는 것은 mysql을 다시 시작하기 때문에 선호되는 접근법 일 수 있습니다. MySQL 패킷이 무엇인지 이해하면이를 분명히 알 수 있습니다.
"MySQL 내부 이해"(ISBN 0-596-00957-7)의 99 페이지 에 따르면 , 1-3 항에 설명되어 있습니다.
MySQL 네트워크 통신 코드는 쿼리가 항상 합리적으로 짧다는 가정하에 작성되었으므로 서버에서 하나의 청크로 서버로 보내고 처리 할 수 있습니다 .이를 MySQL 용어 로 패킷 이라고합니다 . 서버는 패킷을 저장하기 위해 임시 버퍼를위한 메모리를 할당하고이를 완전히 맞추기에 충분한 요청을합니다. 이 아키텍처는 서버에 메모리가 부족하지 않도록주의해야합니다.이 옵션은 패킷 크기를 제한합니다.
이 옵션과 관련하여 관심있는 코드는 sql / net_serv.cc에 있습니다. 한 번 봐 가지고 my_net_read ()를 , 다음의 호출에 따라 my_real_read을 () 와에 특히주의 ) (net_realloc .
이 변수는 또한 많은 문자열 기능의 결과 길이를 제한합니다. 자세한 내용은 sql / field.cc 및 sql / intem_strfunc.cc 를 참조하십시오.
이 설명을 감안할 때 대량 INSERT를 만들면 MySQL 패킷이 다소 빠르게로드 / 언로드됩니다. max_allowed_packet이 주어진 데이터로드에 비해 너무 작을 때 특히 그렇습니다.
결론
대부분의 MySQL 설치에서 나는 보통 이것을 256M 또는 512M으로 설정합니다. 데이터로드에서 "MySQL이 사라졌습니다"오류가 발생하면 더 큰 값으로 실험해야합니다.
시간이 초과되기 전에 얼마나 오래 걸립니까? 첫 번째 단계는 wait_timeout및 interactive_timeout설정을 확인하여 가져 오기에 충분히 큰지 확인하는 것입니다.
SHOW VARIABLES LIKE '%_timeout';
SET SESSION wait_timeout=28800;기본값은 8 시간 (28800)이므로 문제가되지 않습니다. 이 문제에 대한 다른 표시는 여기 에서 찾을 수 있습니다 . 눈에 띄는 것은 이것입니다.
다른 호스트에서 실행되는 클라이언트 응용 프로그램에는 해당 호스트에서 MySQL 서버에 연결하는 데 필요한 권한이 없습니다.
먼저 권한을 확인한 다음 잠재적 인 문제 목록을 살펴보십시오.
그것은 "올바른"것이 아닐 수도 있지만 효과가있을 수 있습니다 (그렇지 않습니까?).
큰 덤프를 여러 파일로 나누고 한 번에 하나씩 순서대로 실행하십시오. 내 접근 방식은 반으로 나누고 테스트하는 것입니다. 그런 다음 각 절반을 반으로 나누고 다시 테스트하십시오.
상자에 넣은 RAM의 양이 이것과 관련이 있는지 궁금합니다. MySQL은 덤프를 실행할 때 전체 덤프를 메모리에로드합니까? 모르겠습니다 ...하지만 2GB의 RAM 만 있고 일부가 OS 및 기타 응용 프로그램을 실행 중이면 문제 가 될 수 있습니다.
다른 제안들에 성공하지 못한 사람들은 BigDump PHP staggered MySQL dump importer 스크립트를 살펴볼 수 있습니다 .
대용량 데이터베이스 덤프를 MySQL로 가져 오기위한 해결 방법입니다. 큰 MySQL 덤프를 로컬 개발 환경으로 가져 오기 위해 성공적으로 사용했습니다 (이 경우 MAMP를 사용하고 있습니다).
max_allowed_packet900M으로 설정을 시도했지만 사용하고--skip-extended-insert(그리고 당신이 옳습니다-huuuge db-dumps를 만듭니다), 여전히 실패합니다. 나는 아마도 해결할 수 있다고 덤프에서 특정 줄을 의심하고 있습니다. 그러나 여전히 이상합니다. CentOS 서버에서 덤프를 올바르게 가져올 수 있습니다.