내 장치에는 디스크 온 모듈 또는 컴팩트 플래시 저장소를 사용하는 TinyCore(3.6) Linux 배포판이 있습니다.
파일 시스템은 ext2입니다.
나는 이 장치에 LAMP 스택을 가지고 있고 400개가 넘는 테이블(myisam)을 포함하는 MySQL 데이터베이스를 가지고 놀고 있습니다. 쓰기 작업은 15분마다 체계적으로 발생합니다.
이 테이블은 설정 요구 사항에 따라 웹 애플리케이션에서 생성됩니다.
이제 전원 부족으로 인해 이 장치가 갑자기 종료될 수 있습니다.
updateMySQL이 일부 쓰기 작업(예 : , delete, ) 을 수행하는 경우 insert일부 데이터와 인덱스 파일이 손상될 수 있습니다.
확실히 큰 문제는 아니지만 repair table작업을 수행하는 것이 그렇게 나쁘지는 않습니다. 불행하게도 일부 데이터가 손실되더라도(제 경우에는 허용될 수 있음) 테이블이 복구되고 애플리케이션이 계속 실행될 수 있습니다.
문제는 종종 갑작스러운 종료가 발생할 때 여러 mysql 테이블 파일(FRM, MYI 또는 MYD)이 "입력/출력 오류" 상태에 있고 내 MySQL 프런트 엔드에서 "스토리지 엔진 오류 5"(I/ O 오류) 해당 테이블에 대한 것입니다. 데이터베이스를 사용하는 애플리케이션은 분명히 올바르게 실행될 수 없습니다.
이러한 이벤트(어느 정도는 피할 수 없다고 생각함)를 방지하는 대신 위에서 설명한 시나리오에서 파생된 파일 I/O 오류 상황을 올바르게 자동으로 복구할 수 있는 방법에 대해 생각하고 싶습니다.
어떤 아이디어가 있나요?
편집하다: 불행하게도 ext3으로 전환할 수 없습니다. ext2를 고수해야 합니다. ext3이 솔리드 스테이트 메모리 쓰기 주기에 큰 영향을 미치기 때문입니다.
답변1
CF를 사용하고 있다면 사용할 가능성이 없다고 생각합니다.DM-다중 경로또는 기타 고가용성 기능을 사용하는 경우 수명을 연장하려면 최소한 "noatime" 옵션을 사용하여 해당 파일 시스템을 마운트해야 합니다(자신의 스크립트에 atime을 사용하지 않는 경우 등...).
그 외에는 가장 강력한 플랫폼처럼 들리지 않습니다.