MyISAM을 사용하는 MySQL의 REPAIR TABLE 중에 데이터가 손실되는 원인은 무엇입니까?

Question

는

REPAIR TABLE에 대한 MySQL의 문서는

그것은 테이블 수리를 작업을 수행하기 전에 테이블 의 백업을하는 것이 가장 좋습니다한다고; 일부 상황에서는 작업으로 인해 데이터가 손실 될 수 있습니다. 가능한 원인은 을 포함하지만 파일 시스템 오류로 제한되지 않습니다.

파일 시스템 오류 외에 다른 데이터 손실 원인이 있는지 알고 싶습니다. 이걸 야생에서 본 사람 있어요? 파일 시스템 오류가없는 경우 복구로 인해 데이터가 손실 될 가능성은 얼마나됩니까?

제 구체적인 상황은 다음과 같습니다. Sun T5120 서버에서 Solaris 10 (SPARC)을 실행 중이고 MySQL 5.1.30을 사용 중입니다. 가끔 손상되는 MyISAM 엔진을 사용하는 테이블이 있습니다. 테이블이 손상된 경우는 UPS가없는 개발 시스템의 예기치 않은 정전으로 인한 것입니다. 모든 부패가 정전으로 인한 것인지 확신 할 수 없기 때문에 이러한 일이 발생하는 몇 가지 추가적인 이유가있을 수 있습니다. 같은 원인이 나열된 here.

생산 시스템에서 "추가 원인"이 의심되거나 생산 UPS가 실패 할 경우 자동 복구 솔루션을 설치하고 싶습니다. 내가 this answer에 제안 된 것과 같이 mysqlcheck --auto-recover을 실행하도록 cron 작업을 설정하거나 손상을 감지했을 때 REPAIR TABLE EXTENDED 명령을 즉시 수행하도록 해당 테이블에 삽입하는 프로세스를 수정할 수 있습니다. 그러나 두 방법 모두 REPAIR TABLE을 사용하므로 데이터 손실의 위험이 있습니다.

설명서에 나와 있듯이 복구하기 전에 테이블을 백업 할 수는 있지만 테이블이 너무 커서 백업을위한 공간을 확보 할 수 있을지 확신하지 못합니다. 일부 검색을 수행 한 적이 있지만 REPAIR TABLE이 설명서에 언급 된 것 이외의 데이터 손실을 초래하는 이유에 대한 설명을 찾지 못했습니다. 그래서 당신이 사운드 파일 시스템을 가지고있을 때 수리가 데이터를 잃을 가능성이 있습니까, 아니면 단지 신중한 문서입니까?

Answer 1

MySQL 설명서에 나열된 가능한 원인 중 하나는 소프트웨어의 버그입니다. 버전 정보에서 릴리즈 노트/변경 내역을 읽어 복구 테이블 코드의 버그가 수정되었는지 확인하고 새로운 버전의 릴리즈 노트를 읽어야합니다.

관심 분야로, 데이터를 삽입하는 프로세스가 손상을 어떻게 감지합니까?

데이터 손실을 방지하기 위해 수행 할 수있는 추가적인 조치는 백업을 수행하고 복제 로그를 사용하는 것입니다. 실패한 경우 백업에서 복원 한 다음 복제 로그를 사용하여 데이터베이스를 손상된 상태로 되돌릴 수 있습니다.

궁극적으로 이것이 프로덕션 시스템 인 경우 좋은 전원 공급 장치를 분류하고 복제본 역할을하는 두 번째 시스템을 필요로합니다.

Answer 2

REPAIR TABLE이 데이터를 손상시킬 수는 있지만 물론 보장 할 수는 없습니다. 그것은 단지 불행일지도 모르지만, MySQL이 거의 모든 파일 시스템을 예외적으로 거의 처리하지 못하는 경험이 있습니다. 디스크 공간이 부족하면 REPAIR TABLE이 이상한 일을 할 것으로 예상되는 상황 중 하나입니다.

Answer 3

MySQL fixed bugs 및 known issues 목록을 버전 5.1 이상에서 그리고 이전 버전과 약간의 폭넓게 검색했습니다. 테이블 복구로 인해 데이터가 손실되는 몇 가지 이유를 발견했습니다. 그들 중 누구도 나의 특별한 상황에 적용되지 않는 것 같아서, 나는 너무 많이 걱정할 필요가 없을 것입니다. 바라기를이 정보는 다른 사람에게 유용한 정보가 될 것입니다.

---

버그 # 338

REPAIR table USE_FRM results in data loss if killed

버전에 미치는 영향 : 정말 버그가 아니기 때문에 모든

이 고정되지 않았다. 고유 한 (완전히 이해할 수있는) 시스템 제한 사항입니다. 많은이 된 후에 4.1.11

이 제로 항목 에 테이블을 절단 수리의 기록은 다음과 같습니다

---

버그 # 10437

After large delete repair table causes data loss!!!

버전에 미치는 영향 테이블에있는 삭제 중. 이 버그의 마지막 활동은 2005 년 5 월에 발생했으며 문제 은 4.1.14에서 재현 할 수 없으므로 이미 해결되었을 수 있습니다. 5.1.20

만의 MySQL 5.1.20 이전 버전에서 일어날 것 같은데, 오직 당신은을 지정할 때 :

---

버그 # 29980

5.1.20 ate my table

버전이 미치는 영향 USE_FRM 옵션. 또한, 그 경우에 손상의 원인은 이고 MySQL 버전 5.1.20으로 업그레이드되었으므로이 문제가 발생할 가능성이 거의 없다고 생각합니다. 이 테이블의 이름이 "확장 된 문자"및의 이름이 포함 된 경우 발생할 수 5.1.30

:

---

버그 # 41385

Crash when attempting to repair a #mysql50# upgraded table with triggers

버전에 미치는 영향 데이터베이스는 MySQL 5.0에서 5.1로 업그레이드하는 동안 발생하는 # mysql50 #이라는 접두사가 붙어 있습니다. 수정이 5.1.31 릴리스로 푸시되었으므로이 문제가 저에게 문제가되어서는 안됩니다. 내가 버그 추적기에서 찾을 수 없습니다 MySQL의 포럼에

---

게시 할 수 있습니다.수리가에 진행되는 동안 당신이 병합 테이블에서 선택하면 5.0.37

분명히, 여러 하위 테이블 병합 테이블 데이터가 손실 될 수 있습니다

Repair on merge table causes data loss

버전이 미치는 영향 서브 테이블.

---

관련 맛있는 가벼운 음식 :

는 다양한 I 모두 읽어 discussions 및 how-tos는 하드웨어 문제가 테이블 손상의 주요 관심사입니다 나타내는 것 같다. 또한 마틴 (Martin)은 his answer에 대한 의견에서 언급했듯이 대량의 동시 연결로 인해 손상 될 수 있습니다.

또주의해야 할 것은 여유 공간입니다. 수리를 위해 수리중인 테이블의 크기에 충분한 여유 공간이 필요하다는 의견을 보았습니다. 나는 그것이 제 위치에서 수리를 수행 할 것이라고 생각 했었습니다. 아마도 MySQL의 현재 버전이 이것을 수행하지만, 백업을위한 여분의 공간이 필요하지 않을 수도 있습니다.