키캐시로 수리를 피하는 방법?

키캐시로 수리를 피하는 방법?

my.cnf 파일을 최적화한 경험이 있지만 데이터베이스에는 약 400만 개의 레코드(MyISAM)가 있습니다. mysq 덤프에서 복원하려고 하지만 그럴 때마다 결국 며칠이 걸릴 수 있는 무서운 "키캐시를 사용한 복구"를 얻습니다.이 문제를 극복하고 "Repair By Sorting"(리페어 바이 소팅)으로 처리할 수 있는 방법이 있습니까?

2GB RAM, 듀얼 코어, 추가 하드 드라이브 공간이 많습니다.

내 .cnf에서 잘라냅니다.

set-variable = max_connections=650
set-variable = key_buffer=256M
set-variable = myisam_sort_buffer_size=64M
set-variable = join_buffer=1M
set-variable = record_buffer=1M
set-variable = sort_buffer_size=2M
set-variable = read_buffer_size=2M
set-variable = query_cache_size=32M
set-variable = table_cache=1024
set-variable = thread_cache_size=256
set-variable = wait_timeout=7200
set-variable = connect_timeout=10
set-variable = max_allowed_packet=16M
set-variable = max_connect_errors=10
set-variable = thread_concurrency=8

정렬에 의한 복구는 파일 정렬 루틴을 사용하여 tmpdir에 여러 임시 파일(보통)을 만듭니다.

tmpdir에 공간이 충분하지 않으면 "키 캐시로 복구"로 돌아갑니다.이는 훨씬 느리고 최적의 인덱스를 덜 생성하기 때문에 매우 좋지 않습니다.

다른 조건들도 있지만 저는 그것들을 확인하지 못했습니다.

파일 sort()에 필요한 tmpdir의 크기를 구하는 것은 간단한 일이 아닙니다. 포맷 데이터가 파일 sort에 저장되는 것은 MYD 파일과 동일하지 않기 때문에 일반적으로 훨씬 더 많은 공간을 사용합니다.

따라서 tmpdir가 작은 /tmp(또는 tmpfs)를 가리키면 더 큰 /var/tmp로 변경할 수 있습니다.

MySQL은 테이블 인덱스의 가능한 최대 크기가 변수 myisam_max_sort_file_size의 값보다 클 때마다 MyISAM 테이블에 대해 키 캐시별 복구를 사용합니다.

인덱스의 최대 크기는 모든 인덱스의 모든 키에 대한 바이트 크기 값을 합산하고 테이블의 행 수를 곱하여 계산할 수 있습니다.

myisam_max_sort_file_size를 늘리면 slow keycache 메서드 대신 디스크 정렬을 사용하여 인덱스가 재구성됩니다.

fast reg.mysam_max_sort_file_size로 설정하지 않은 새 데이터베이스에서 실수로 수리 테이블을 빠르게 실행했는데, 이는 에 비해 너무 작았습니다.MID 파일(88279393280 바이트 크기, 약 88GB)데이터 파일은 85GB입니다.이 표는 12억 개의 기록으로 ID, 날짜 두 개, 작은 텍스트, 몇 개의 빅인트와 더블로 구성되어 있습니다.제 서버(윈도우 7 아래 박스에서 실행되는 2GB 가상 리눅스)는 윈도우 서버에 4개의 코어 중 하나만 있지만 3+GHZ를 실행하고 있습니다.저는 이 "열쇠 캐시에 의한 수리" 행사가 영원히 걸릴까 봐 두려웠습니다. 테이블이 훨씬 더 작은 공포 이야기들 때문입니다.

다행히 수리대 빠른 작동을 완료하는 데는 1일 10시간 20.72초가 걸렸습니다.

제가 가장 그리워하는 것은 그 mysql이 어디까지 작동하고 얼마나 빨리 끝날 수 있는지를 아는 방법입니다.이것은 아직 나에게는 알려지지 않았습니다.

나는 지금 내.ini 파일을 변경하고 df에 그 큰 임시 파일들을 위한 충분한 디스크 공간이 있는지 다시 한번 확인했습니다.

아무튼..내 요점은, 이 함정에 빠진 다음 남자에게 아주 유용한 지식일 수도 있다는 겁니다.사실은...당황하지 마세요! 느릴 수도 있지만, 10억 개 이상의 기록을 하루나 이틀 안에 정리할 수 있는 수준 이하의 하드웨어라면 가능합니다.하나는 날짜 필드, 하나는 비긴트 필드, 하나는 ID 필드에 있는 기본 인덱스 세 개가 있습니다.

이것을 솔루션 중 하나에 대한 의견으로 게시하고 싶지만, 여기 사용자 인터페이스를 사용하면 어떻게 해야 할지 모르겠어서 솔루션으로 게시하겠습니다.저를 지지하지 마세요. 단지 제가 여기에 가지고 싶어했을 메모입니다. 일주일 이상 걸릴 수 있다고 생각했기 때문에 "키캐시별" 스레드를 거의 죽일 뻔했습니다. 10억 개당 2일은 관리할 수 있습니다.

편집: 그리고 지금은 같은 데이터베이스에 복구 테이블이 있지만 충분히 큰 mysiam_max_sort_file_size 설정으로 정렬하여 복구하는 데 10시간 20분이 걸렸습니다.가장 많이 사용된 디스크 공간은 약 250GB였지만 서버에서 실제로 사용 가능한 디스크 공간이 얼마나 되는지를 반영하여 myisam_max_sort_file_size를 훨씬 더 높게 설정했습니다.

진행 상황을 추적하는 것은 어렵습니다.개별 인덱스를 작성하는 동안 디스크 공간이 오르락내리락했지만, 디스크 공간 사용량과 같은 변경 사항이 없는 몇 시간 동안의 일시 중지가 있었습니다(df에서 보고한 바와 같이).

마크 감사합니다. 네, 그것이 바로 제가 시도한 것이고 로그를 보면 "키캐시를 사용한 복구"로 전환한 이유가 공간 부족 오류였습니다.

이것은 제가 해결책을 마련하기 위해 한 일입니다. 왜냐하면 그것이 가리키는 사실을 겪지 않을 것이기 때문입니다./tmp/mysqltmp/, 최대 2MB 밖에 없었습니다.

그래서 저는 이렇게 했습니다.

mkdir /home/mysqltmp

chown mysql:mysql /home/mysqltmp

내.conf의 tmp dir를 다음으로 변경했습니다. tmpdir=/home/mysqltmp/

이제 사용하면df -h /home/mysqltmp, 제가 보기에 dir는 285GB를 사용할 수 있습니다. 그래서 그것은 정말 보기 좋은 광경이었고, 충분한 여유 공간이 있었고, 또한 mysql이 20GB를 쉽게 원하는 것을 볼 수 있었습니다.그래서 지금까지 12시간이 걸렸던 것은 20분 안에 완료되었습니다. 인덱스에 삽입되는 300만개가 넘는 레코드입니다.

여기에 있는 솔루션 중 어느 것도 제게 적합하지 않았습니다. 아무리 증가시켜도myisam_sort_buffer_size변수 또는 내가 어디서 만들었는지.tmpdir변수는 항상 키캐시로 테이블을 수리했습니다.

명령 줄 유틸리티를 사용하는 것이 효과적이었습니다.myisamchk:

myisamchk --sort-recover --sort_buffer_size=14G /path/to/table

여기서:

• /path/to/table는 확장자가 없는 데이터베이스 파일의 경로입니다(따라서, 확장자가 없는 경우)..MYI마지막에).기본적으로 디렉토리에 있습니다./var/lib/mysql/your_database.

• 버퍼 크기를 다음에서 변경합니다.14G빈 공간이 어디든 상관없어요

추가 보너스로 데이터를 전환할 때 진행 중인 진행 상황도 표시합니다.

MySQL 참조 매뉴얼에 따르면 디스크 공간은 "원래 인덱스 파일이 있는 디렉터리를 포함하는 파일 시스템에서" 사용 가능해야 합니다(http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_myisam_max_sort_file_size) -- 이는 (적어도) v5.0 이상에 적용됩니다.이것은 tmp 디렉토리에 대한 디스크 공간을 늘리는 것이 도움이 된다는 위의 답변들 중 일부와 모순됩니다.

참조 매뉴얼에 설명된 동작을 확인할 수 있습니다. 임시 디스크 공간은 테이블의 데이터(*.MYD) & 인덱스 파일(*.MYI)에 저장되지만 에 저장되지는 않습니다.tmpdir.

언급URL : https://stackoverflow.com/questions/1067367/how-to-avoid-repair-with-keycache