설정

나는 지금 꽤 오랫동안 프로그래머 였지만 여전히 깊고 내부적 인 것들에 대해서는 약간 모호하다.

지금. 나는 다음 중 어느 것도 좋지 않다는 것을 잘 알고있다.

1. 프로세스를 죽이십시오 -9 (나쁜)
2. 실행중인 컴퓨터 나 서버의 전원 플러그를 자발적으로 당기십시오 (심각한 경우)

그러나 때로는 평범해야합니다. 때로는 프로세스가 수행 한 작업에 관계없이 응답하지 않고 때로는 컴퓨터가 수행 한 작업에 관계없이 응답하지 않는 경우가 있습니다.

mod_wsgi를 통해 Apache 2, MySQL 5, PHP 5 및 Python 2.6.5를 실행하는 시스템을 가정 해 봅시다.

참고 : 여기서 Mac OS X에 대해 가장 관심이 있지만 UNIX 시스템과 관련된 답변이 도움이 될 것입니다.

내 관심사

이 중 하나, 특히 두 번째 중 하나를 수행해야 할 때마다 일정 기간 동안 무언가가 깨 졌다는 것이 매우 걱정됩니다. 어딘가에 파일이 손상되었을 수 있습니다. 누가 어떤 파일을 알고 있습니까? 컴퓨터에 1,000,000 개가 넘는 파일이 있습니다.

OS X를 자주 사용하므로 디스크 유틸리티를 통해 "디스크 확인"작업을 실행합니다. 아무 문제도보고하지 않지만 여전히 우려하고 있습니다.

어딘가에 일부 구성 파일이 망가지면 어떻게 될까요? 또는 바이너리 파일이 손상된 경우 어떻게해야합니까? 또는 어딘가에 스크립트 파일이 손상되었습니다. 일부 하드웨어가 손상된 경우 어떻게합니까?

부패 나 피해가 재앙을 일으키는 중대한 시나리오에서 다음 달까지 그 사실을 알지 못하면 어떻게해야합니까?

또는 귀중한 데이터가 이미 손실 된 경우 어떻게해야합니까?

내 희망

나는 이러한 우려와 걱정이 근거가 없다는 것을 희망한다. 결국, 여러 번이 작업을 수행 한 후에도 아직까지는 전혀 나쁜 일이 없었습니다. 최악의 경우 일부 MySQL 테이블을 복구해야했지만 데이터가 손실되지 않은 것 같습니다.

그러나 내 걱정이 근거가없고 상황 1 또는 2에서 실제 피해가 발생할 수 있다면, 그것을 감지하고 예방할 수있는 방법이 있기를 바랍니다.

내 질문

현대 운영 체제는 이러한 시나리오에서 아무것도 손실되지 않도록 설계 되었기 때문일 수 있습니까? 현대 소프트웨어가 손실되지 않도록 설계 되었기 때문일 수 있습니까? 현대 하드웨어 디자인은 어떻습니까? 전원 플러그를 뽑을 때 어떤 조치가 취해 있습니까?

내 질문은 두 시나리오 모두에 대해 정확히 무엇이 잘못 될 수 있으며 문제를 해결하기 위해 취해야 할 조치는 무엇입니까?

잘못 될 수있는 한 가지는 일부 프로그램이 디스크로 데이터를 플러시하지 않았을 수 있으므로 디스크에 기록되어야하는 최신 데이터 (예 : 전원 풀기 몇 초 전) )가 손실 될 수 있습니다. 그러나 그 이상은 어떻습니까? 5 초의 데이터 손실 문제로 시스템이 망가질 수 있습니까?

하드 드라이브의 거대한 파일 포리스트 어딘가에 임의의 파일이 숨겨져있는 경우는 어떻습니까?

하드웨어 손상은 어떻습니까?

가장 도움이 될 것

1. 프로세스를 종료 (-9)하거나 전체 시스템의 전원을 끌 때 내부적으로 진행되는 작업에 대한 자세한 설명. (즉시처럼 보이지만 누군가 나를 위해 속도를 늦출 수 있습니까?)

2. 이러한 시나리오에서 잘못 될 수있는 모든 문제에 대한 설명과 함께 (물론) 가능성이 있습니다 (즉, 가능성은 거의 없지만 가능성이 높습니다) ...

3. 이러한 시나리오가 발생할 때 손상 또는 손상을 방지하기 위해 최신 하드웨어, 운영 체제 및 소프트웨어에 적용된 조치에 대한 설명. (나를 위로하기 위해)

4. 드라이브 어딘가에 손상이나 손상이 없는지 확인하기 위해 "디스크 확인"을 넘어서 kill -9 또는 power pull 후 수행 할 작업에 대한 지침.

5. 컴퓨터 설치를 강화하기 위해 취해야 할 조치로 무언가를 죽이거나 전원을 꺼야 할 경우 잠재적 인 손상이 완화됩니다.

6. 이진 파일에 대한 일부 정보-아파치 이진 파일 또는 일부 라이브러리의 중간에 임의의 바이트가 손상되어 나중에 나오지 않고 나중에 문제가 발생한다는 사실이 사실이 아닙니까? 파워 풀이나 킬로 인해 이런 일이 발생하지 않았다고 어떻게 확신 할 수 있습니까?

정말 고마워!

전원을 끄면 모든 경고 메시지없이 비행이 중단됩니다. kill -9는 단일 프로세스에 동일한 영향을 미치며 SIGKILL 로 강제 종료합니다 .

커널이나 정전으로 프로세스가 종료되면 정리 작업을 수행하지 않습니다. 즉, 절반으로 작성된 파일, 불일치 상태 또는 캐시 손실이 발생할 수 있습니다. 일반적으로 저널링, 종료 상태 및 배터리 백업으로 인해 걱정할 필요가 없습니다.

/ tmp의 임시 파일은 tmpfs에있는 경우 자동으로 사라지지만 firefox의 경우 lock 및 .parentlock과 같이 제거 할 응용 프로그램 별 잠금 파일이 여전히있을 수 있습니다.

대부분의 소프트웨어는 성공적인 종료 상태를 기록하지 않으면 트랜잭션을 재 시도 할 수있을 정도로 똑똑합니다. 이에 대한 좋은 예는 일반적인 메일 시스템입니다. 메시지가 배달되고 있지만 중간에 잘 리면 보낸 사람이 성공할 때까지 나중에 다시 시도합니다.

파일 시스템이 저널링되었을 수 있습니다. 파일을 이동하거나 쓰는 중이고 파일이 스트림 중반에 종료되는 경우 저널 파일 시스템은 여전히 ​​원본을 참조합니다. 저널 파일 시스템은 기존 사본을 남겨두고 비파괴 적으로 변경 한 다음 이전 사본이 디스크에서 차지한 공간을 확보하기 전에 마지막 단계로만 새 사본을 참조합니다.

이제 RAID 어레이가있는 경우 모든 종류의 메모리 버퍼가있어 성능을 높이고 정전시 안정성을 제공합니다. 파일 시스템은 장치의 캐시와 상태에 대해 알지 못하므로 변경 사항이 디스크에 커밋되었다고 생각하지만 여전히 RAID 캐시에 있습니다. 전원이 꺼지면 어떻게 되나요? RAID 인클로저에 기능 배터리가 있고이를 모니터링하기를 바랍니다. 그렇지 않으면 fsck에 손상된 파일 시스템이 있습니다.

예, 바이너리에서 몇 비트가 손상 될 수 있지만 최신 하드웨어에서는 그다지 걱정하지 않습니다. 정말 편집증이라면 적절한 도구를 사용하여 디스크와 RAID의 상태를 모니터링 할 수 있지만 어쨌든 그렇게해야합니다. 정기적 인 백업을 수행하고 무정전 전원 공급 장치를 받으십시오.

예기치 않게 종료 된 경우 손상 될 파일은 쓰기 위해 열려있는 파일뿐입니다. 특정 시점에 대부분의 시스템에서 파일에 쓰지 않을 수 있습니다. 아마.

1 명 처치 -9

POSIX SIGKILL이며 구현에 따라 다릅니다. 이 신호를받는 프로세스에는 처리 할 기회가 없습니다.

1 전원 차단

하드웨어에 따라 다릅니다. 드라이브 모멘텀 하에서 헤드가 자동 파킹되고 쓰기 캐시의 모든 항목이 DRAM 새로 고침을 잃고 몇 초 내에 돌이킬 수없는 손상이 발생합니다. 시스템 메모리, CPU 캐시, 레지스터 등에 대해서도 마찬가지입니다.

wdc.com에서 (google : site : wdc.com 보호 헤드 파킹)

전원 손실 : 하드 드라이브가 재설정되었습니다. 스핀들 에너지를 사용하여 착륙 구역에 헤드가 파킹됩니다. 스핀들 모터가 정지했습니다.

2-잘못 될 수있는 것

열려있는 파일이 불완전하게 작성되었습니다. 쓰기 위해 파일을 열면 데이터가 손상됩니다. 최신 하드웨어의 파일 쓰기 속도가 빠르며 최신 PC에는 일반적으로 IO가 적용되지 않습니다. 조용한 시골 길을 눈가리개로 걷는 것과 같습니다. 대부분의 경우 괜찮을 것입니다.

3-대책

디스크의 기능에 대해서는 위를 참조하십시오.

저널 파일 시스템을 찾아보십시오. 이제 정상적인 상태입니다. http://en.wikipedia.org/wiki/Journaling_file_system

MS Word 또는 vi와 같은 소프트웨어는 원본이 아닌 임시 파일에 기록합니다. 디스크에 일관된 사본이없는 상태로 시스템을 두지 마십시오.

Windows는 레지스트리 사본을 보관합니다 (너무 중요합니다) Wikipedia : "Windows 2000은 레지스트리 하이브 (.ALT)의 다른 사본을 보관하고 손상이 감지되면이를 전환하려고 시도합니다." Win2k, 그래서 MS의 새로운 메커니즘이 무엇인지 잘 모르겠습니다)

4-해야 할 일

난이도에 따라 (쉬운 어려움)

• 백업 유지
• 마지막 작업 내용 확인
• 별도의 디스크에서 부팅하고 충돌시 시스템이 수행 한 작업을 파악하기 위해 마지막으로 수정 된 날짜 / 시간을 찾습니다.
• 별도의 디스크에서 부팅하고 모든 파일의 md5sum을 오프라인 복사본과 비교합니다.

백업 유지가 가장 적합한 답입니다. 백업을 잘 수행하면 이전에 수정 된 버전으로 돌아갈 수 있습니다.

5

중복 전원? 최종 사용자 교육? 전원 버튼 위에 테이프와 판지를 넣었습니까?

6

하드웨어 오작동, 손상된 디스크 드라이버, 손상된 OS 커널, 업그레이드 중 체크섬 또는 충돌이없는 경우, 바이너리 및 라이브러리는 읽기-쓰기로 열리지 않으므로 손상되지 않습니다. 발생하지만 드물다.

kill -9의 경우, 프로세스에 즉시 "다이 (die)"신호를 보냅니다. 프로세스가 중단됩니다 (무정전 수면 상태가 아닌 경우 좀비가 됨). 파일이 닫히거나 데이터가 기록되지 않으며 프로그램이이 신호를 포착하여 다른 작업을 수행 할 수 없습니다. 정리도없고 아무것도 없습니다 : 그냥 죽습니다.

오늘날의 파일 시스템은 매우 강력합니다. XFS, JFS, ext3 및 ext4와 같은 파일에는 모두 파일 시스템 메타 데이터를 그대로 유지하기위한 저널 및 기타 항목이 있습니다.

Apache 자체 및 기타와 같은 바이너리는 메모리에 있거나 읽기 때문에 갑작스런 전원 손실이나 시스템 종료로 인해 손상 될 가능성이 없습니다. 예를 들어 Apache HTTP가 시작 중일 때 읽히는 경우 전원 서지로 인해 이진이 손상 될 수 있지만 가능성은 거의 없습니다.

나는 Mac Mini 사람들이 차가워지는 것을 좋아하는 것 같습니다 (몇 번이나 말하더라도 .....). 계속 진행됩니다.

대부분의 경우 킬 -9에 의존하지 않거나 정기적으로 전원을 끄지 않는 한 크게 걱정하지 않아도됩니다. 과거에는 상황이 훨씬 나빴습니다. 솔라리스 10에 대한 것보다 솔라리스 2.6에 대해 더 걱정할 것입니다.

"kill -9"는 보류중인 IO 작업을 동기화하지 않습니다. 이것은 종종 문제가되지 않지만 시스템에 IO로드가 많은 경우 데이터가 손실 될 수 있습니다.

RAID 컨트롤러 (배터리 기반 캐시 없음)가 쓰기를 캐시하고 데이터를 잃을 수있는 서버에 더 많은 문제가 있습니다.

편집 : 한 가지 더 ... 네트워크 마운트 드라이브에 의존하고 열려있는 파일 핸들이있는 경우 파일이 일치하지 않거나 손상 될 수 있습니다. Windows에서 이것이 보이는 전형적인 예는 사용자가 Outlook PST 파일을 공유에 마운트하고 전원 또는 네트워크 연결이 끊어진 경우입니다.