설정
나는 꽤 오랫동안 프로그래머로 활동해왔지만 여전히 심층적이고 내부적인 내용에 대해서는 약간 모호합니다.
지금. 나는 다음 중 하나가 좋은 생각이 아니라는 것을 잘 알고 있습니다.
- kill -9 프로세스 (나쁜)
- 실행 중인 컴퓨터나 서버의 전원 플러그를 자발적으로 뽑는 경우(더 나쁜 경우)
그러나 때로는 그렇게 해야 할 때도 있습니다. 때로는 사용자가 무엇을 하든 프로세스가 응답하지 않을 수도 있고, 때로는 사용자가 무엇을 하든 컴퓨터가 응답하지 않는 경우도 있습니다.
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초의 데이터 손실 문제가 시스템을 망칠 수 있습니까?
내 하드 드라이브의 거대한 파일 숲 어딘가에 숨어 있는 임의 파일의 손상은 어떻습니까?
하드웨어 손상은 어떻습니까?
나에게 가장 도움이 되는 것은 무엇인가?
프로세스를 종료하거나 전체 시스템의 전원을 끌 때 내부적으로 무슨 일이 일어나는지에 대한 자세한 설명입니다. (즉각적인 것 같지만 누군가 나를 위해 속도를 늦춰줄 수 있나요?)
이러한 시나리오에서 잘못될 수 있는 모든 것에 대한 설명 및 (물론 대략적인) 확률(예: 가능성이 매우 낮지만 가능성이 높음)...
이러한 시나리오가 발생할 때 손상을 방지하기 위해 최신 하드웨어, 운영 체제 및 소프트웨어에 적용되는 조치에 대한 설명입니다. (나를 위로하기 위해)
드라이브 어딘가가 손상되거나 손상되지 않았는지 확인하기 위해 "디스크 확인"을 넘어 kill -9 또는 전원 풀 이후 수행할 작업에 대한 지침입니다.
무언가를 죽이거나 전원을 뽑아야 하는 경우 잠재적인 손상을 완화할 수 있도록 컴퓨터 설정을 강화하기 위해 취할 수 있는 조치입니다.
바이너리 파일에 대한 일부 정보 - 아파치 바이너리 파일이나 일부 라이브러리의 중간에 임의의 바이트 한두 개가 손상되어 나중에까지 나오지 않고 문제를 일으킬 수 있다는 것이 사실이 아닙니까? 파워 풀이나 살해의 결과로 이런 일이 발생하지 않았다는 것을 어떻게 확신할 수 있습니까?
정말 고마워!
답변1
전원을 당기면 경고 없이 비행 중에 모든 것이 정지됩니다. kill -9는 단일 프로세스에 대해 동일한 효과를 가지며, 다음을 사용하여 강제로 종료합니다.시그킬.
커널이나 정전으로 인해 프로세스가 종료되면 정리 작업이 수행되지 않습니다. 이는 파일이 절반만 작성되었거나 상태가 일관되지 않거나 캐시가 손실될 수 있음을 의미합니다. 저널링, 종료 상태 및 배터리 백업 때문에 일반적으로 이에 대해 걱정할 필요가 없습니다.
/tmp의 임시 파일은 tmpfs에 있으면 자동으로 사라지지만, Firefox의 잠금 및 .parentlock과 같이 제거할 응용 프로그램별 잠금 파일이 여전히 남아 있을 수 있습니다.
대부분의 소프트웨어는 성공적인 종료 상태를 기록하지 못하는 경우 트랜잭션을 다시 시도할 만큼 똑똑합니다. 이에 대한 좋은 예는 일반적인 메일 시스템입니다. 메시지가 전달되고 있지만 중간에 끊어지면 보낸 사람은 성공할 때까지 나중에 다시 시도합니다.
파일 시스템이 저널링되었을 수 있습니다. 파일을 이동하거나 쓰는 중 스트림 중간에 종료되는 경우 저널 파일 시스템은 여전히 원본을 참조합니다. 저널 파일 시스템은 비파괴적으로 변경을 수행하여 이전 복사본을 남겨둔 다음 이전 복사본이 디스크에서 차지했던 공간을 회수하기 전 마지막 단계로만 새 복사본을 참조합니다.
이제 RAID 어레이가 있다면 성능을 향상하고 정전 시 안정성을 제공하기 위한 모든 종류의 메모리 버퍼가 있습니다. 대부분의 경우 파일 시스템은 장치의 캐시와 해당 상태를 알지 못하므로 변경 사항이 디스크에 커밋된 것으로 생각하지만 여전히 RAID 캐시 어딘가에 있습니다. 그렇다면 권력이 죽으면 어떻게 될까요? RAID 인클로저에 제대로 작동하는 배터리가 있고 이를 모니터링할 수 있기를 바랍니다. 그렇지 않으면 fsck에 손상된 파일 시스템이 있습니다.
예, 바이너리에서는 몇 비트가 손상될 수 있지만 최신 하드웨어에서는 그다지 걱정하지 않습니다. 정말 편집증이 있는 경우 적절한 도구를 사용하여 디스크와 RAID의 상태를 모니터링할 수 있지만 어쨌든 그렇게 해야 합니다. 정기적으로 백업을 수행하고 무정전 전원 공급 장치를 구입하세요.
답변2
예기치 않은 종료가 발생하면 쓰기 위해 열려 있는 파일만 손상되어야 합니다. 특정 순간에 대부분의 시스템에서는 아마도 파일에 쓰지 않을 것입니다. 아마.
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 커널 손상, 체크섬 부재 또는 업그레이드 중 충돌이 발생하는 경우, 바이너리 및 라이브러리는 읽기-쓰기로 열리지 않으므로 손상되지 않습니다. 그런 일이 발생하지만 드문 일입니다.
답변3
kill -9의 경우, 이는 그 자리에서 바로 "죽으라"는 신호를 프로세스에 보냅니다. 프로세스가 종료됩니다(중단할 수 없는 절전 모드에 있지 않는 한, 이 경우 좀비가 됩니다). 파일이 닫히지 않고 데이터가 기록되지 않으며 프로그램은 이 신호를 포착하여 다른 작업을 수행할 수 없습니다. 정리도 없고 아무것도 없습니다. 그냥 죽습니다.
오늘날의 파일 시스템은 매우 강력합니다. XFS, JFS, ext3 및 ext4와 같은 것에는 모두 파일 시스템 메타데이터를 그대로 유지하기 위한 저널 및 기타 항목이 있습니다.
Apache 자체 및 다른 바이너리와 같은 바이너리는 메모리에 있거나 읽혀지기 때문에 갑작스러운 전원 손실이나 시스템 종료로 인해 손상될 가능성이 없습니다. Apache HTTP가 시작되는 경우(예: Apache HTTP가 시작되는 경우) 전원 급증으로 인해 바이너리가 손상될 가능성이 있지만 그럴 가능성은 거의 없습니다.
나는 Mac Mini를 가지고 있는데 사람들은 추위를 차단하는 것을 좋아하는 것 같습니다(내가 몇 번이나 말하더라도.....). 그리고 그것은 계속 진행됩니다.
대부분의 경우 kill -9에 의존하지 않거나 정기적으로 전원을 끄지 않는 한 크게 걱정하지 않을 것입니다. 과거에는 상황이 훨씬 더 나빴습니다. 나는 솔라리스 10(등등)보다 솔라리스 2.6에 대해 더 걱정합니다.
답변4
"kill -9"는 보류 중인 IO 작업을 동기화하지 않습니다. 이는 대개 문제가 되지 않지만 시스템에 IO 로드가 많으면 데이터가 손실될 수 있습니다.
RAID 컨트롤러(배터리 지원 캐시 없음)가 쓰기를 캐시하고 데이터를 잃을 수 있는 서버에서는 더 많은 문제가 발생합니다.
편집하다: 한 가지 더... 네트워크에 마운트된 드라이브에 의존하고 파일 핸들이 열려 있는 경우 파일이 일관성이 없거나 손상될 가능성이 매우 높습니다. Windows에서 이를 볼 수 있는 전형적인 예는 사용자가 Outlook PST 파일을 공유에 마운트하고 전원이 끊기거나 네트워크 연결이 끊어지는 경우입니다.