MySQL로 가져와야하는이 거대한 32GB SQL 덤프가 있습니다. 이전에 그런 거대한 SQL 덤프를 가져올 필요가 없었습니다. 나는 평소에했다 :

mysql -uroot dbname < dbname.sql

시간이 너무 오래 걸립니다. 약 3 억 개의 행이있는 테이블이 있으며 약 3 시간 만에 150 만 개에 이릅니다. 따라서 모든 것이 600 시간 (24 일)이 걸리고 비현실적인 것 같습니다. 그래서 내 질문은, 더 빠른 방법이 있습니까?

추가 정보 / 발견

1. 테이블은 모두 InnoDB이며 외부 키가 정의되어 있지 않습니다. 그러나 많은 인덱스가 있습니다.
2. 원래 서버와 DB에 액세스 할 수 없으므로 새로 백업하거나 "핫"복사 등을 수행 할 수 없습니다.
3. 여기에innodb_flush_log_at_trx_commit = 2 제안 된 설정 은 (명확하게 눈에 띄거나 지수 적으로) 개선되지 않는 것 같습니다.
4. (MySQL의 워크 벤치에서) 가져 오는 동안 서버 통계 : https://imgflip.com/gif/ed0c8 .
5. MySQL 버전은 5.6.20 커뮤니티입니다.
6. innodb_buffer_pool_size = 16M 및 innodb_log_buffer_size = 8M입니다. 이것들을 늘려야합니까?

Percona의 Vadim Tkachenko는 InnoDB의 훌륭한 그림 표현을 만들었습니다.

반드시 다음을 변경해야합니다

innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0

왜 이러한 설정이 필요합니까?

• innodb_buffer_pool_size 는 자주 읽은 데이터를 캐시합니다
• innodb_log_buffer_size : 버퍼가 클수록 트랜잭션 로그에 대한 쓰기 I / O가 줄어 듭니다.
• innodb_log_file_size : 로그 파일이 클수록 검사 점 및 쓰기 I / O가 줄어 듭니다.
• innodb_write_io_threads : .ibd파일에 대한 서비스 쓰기 작업 . 의 MySQL 설명서에Configuring the Number of Background InnoDB I/O Threads 따르면 각 스레드는 보류중인 I / O 요청을 최대 256 개까지 처리 할 수 ​​있습니다. MySQL의 기본값은 Percona Server의 경우 4, 8입니다. 최대 값은 64입니다.
• innodb_flush_log_at_trx_commit
  • 충돌이 발생하면 0과 2 모두 1 초의 데이터를 잃을 수 있습니다.
  • 단점은 0과 2가 모두 쓰기 성능을 향상 시킨다는 것입니다.
  • 0은 커밋 유무에 관계없이 초당 1 회 InnoDB 로그 버퍼를 트랜잭션 로그 (ib_logfile0, ib_logfile1)로 플러시하기 때문에 0보다 2를 선택합니다. 설정 2는 커밋시에만 InnoDB 로그 버퍼를 플러시합니다. 전 Percona 강사 인 @jynus가 언급 한 0을 설정하면 다른 이점이 있습니다 .

다음과 같이 mysql을 다시 시작하십시오.

service mysql restart --innodb-doublewrite=0

InnoDB 이중 쓰기 버퍼를 비활성화합니다.

데이터를 가져옵니다. 완료되면 정상적으로 mysql을 다시 시작하십시오.

service mysql restart

InnoDB Double Write Buffer를 재 활성화

시도 해봐 !!!

참고 : 최신 보안 패치를 사용하려면 5.6.21로 업그레이드해야합니다 .

실제로 전체 데이터베이스를 복원해야합니까? 당신이하지 않으면 내 2C :

"청크"에서 복원을 수행하기 위해 특정 테이블을 추출 할 수 있습니다. 이 같은:

zcat your-dump.gz.sql | sed -n -e '/DROP TABLE.*`TABLE_NAME`/,/UNLOCK TABLES/p' > table_name-dump.sql

한 번만 수행하면 필요한 테이블을 추출하는 데 10 분 정도 걸렸습니다. 전체 복원에는 13 ~ 14 시간이 걸렸으며 35GB (gzip 압축) 덤프가있었습니다.

/pattern/,/pattern/p와 -n그들을 포함하여 - 매개 변수는 '패턴 사이에 "조각을 만든다.

어쨌든 35GB를 복원하기 위해 AWS EC2 머신 (c3.8xlarge)을 사용하고 yum (Centos)을 통해 Percona를 설치하고 다음 줄을 추가 / 변경했습니다 my.cnf.

max_allowed_packet=256M
wait_timeout=30000

나는 숫자가 너무 높지만 내 설정에서 효과가 있다고 생각합니다.

데이터베이스를 가져 오는 가장 빠른 방법은 MyISAM 인 경우 (.frm, .MYD, .MYI) 파일을 직접 / var / lib / mysql / "database name"에 복사하는 것입니다.

그렇지 않으면 시도해 볼 수 있습니다. mysql > use database_name; \. /path/to/file.sql

데이터를 가져 오는 또 다른 방법입니다.

가져 오기 속도를 높이는 한 가지 방법은 가져 오는 동안 테이블을 잠그는 것입니다. --add-locks 옵션을 mysqldump에 사용하십시오.

mysqldump --add-drop-table --add-locks --database db > db.sql

또는 --opt를 사용 하여 유용한 매개 변수를 켤 수 있습니다 . 덤프에 유용한 여러 가지 항목이 켜집니다.

mysqldump --opt --database db > db.sql

서버에 다른 저장 장치가있는 경우 한 장치에서 다른 장치로 복사하는 것이 전송 속도를 높이는 방법입니다.

--ignore-table에 필요하지 않은 테이블을 필터링 할 수도 있습니다.