나는 aws ebs에 대해 많이 읽었으며 많은 사람들이 파일 시스템을 동결하도록 권장하는 것 같습니다.~ 동안스냅샷. 그러나 이 Amazon 문서는 다릅니다.
완료되는 동안 진행 중인 스냅샷은 볼륨에 대한 진행 중인 읽기 및 쓰기의 영향을 받지 않습니다.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
aws 문서에서는 스냅샷이 I/O의 영향을 받지 않는다고 나와 있는데 왜 많은 사람들은 스냅샷 중에 파일 시스템을 정지합니까?
내 파일 시스템이 FTP에 사용된다면 어떻게 될까요?
내 파일 시스템이 데이터베이스에 사용되면 어떻게 되나요?
답변1
짧은 답변:이는 실제로 인스턴스에서 실행 중인 애플리케이션의 종류에 따라 다릅니다.
긴 답변:기본적으로 실행 중인 시스템의 정지되지 않은 스냅샷을 찍는 것은 "전원 플러그를 뽑는 것"과 유사합니다. 즉, 갑작스럽고 즉각적인 예상치 못한 충돌이 발생하는 것입니다.
I/O 장벽을 활성화한 상태에서 실행할 때 최신 저널 파일 시스템은 충돌이 발생하더라도 일관성을 유지해야 합니다. 이것은~ 아니다이는 메모리 내 데이터가 손실되지 않음을 의미합니다. 오히려 커밋된 데이터는보장영구 저장소(예: 디스크)에 저장됩니다.
이는 실제로 적절하게 저널링된 애플리케이션, 특히 ACID 호환 데이터베이스(비포괄적 목록: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2, ecc)에 적용됩니다. 다시 말하지만, 이것은~ 아니다갑작스러운 정전(또는 복원된 정지되지 않은 스냅샷)이 발생하더라도 데이터 손실이 발생하지 않음을 의미합니다. 오히려 이는 (암시적일 수도 있는) COMMIT가 반환될 때 모든 관련 데이터가 안정적인 저장소에 있음을 의미합니다.
이러한 저널링된 애플리케이션을 사용하면 파일 시스템을 엄격하게 정지할 필요가 없습니다. 복원된 스냅샷 후 첫 번째 부팅 시 시스템은 해당 저널(파일 시스템 및 데이터베이스)에 응답하고 일관된 상태에 도달합니다.
그러나 이를 수행하는 응용 프로그램이 많이 있습니다.~ 아니다업데이트 내용을 적절하게 기록하고,필요하다fsck일관된 상태로 돌아가는 것과 같습니다 . 주요 예는 MySQL+MyISAM입니다. 이 (매우 일반적인) 데이터베이스 엔진은~ 아니다일반 I/O 장벽을 고려하지 않고 관련 없는 I/O 작업을 일괄 처리하여 뛰어난 쓰기 속도를 얻을 수 있으므로 ACID를 준수합니다. 부적절한 종료(예: 정전, 시스템 또는 mysql 충돌, 정지되지 않은 스냅샷)가 mysqlcheck/mysqlrepair수행될 때까지 MyISAM 데이터베이스가 작동하지 않을 수 있습니다.
다양한 가이드에서는 스냅샷을 찍기 전에 파일 시스템을 중지하라고 권장하고 있습니다. 일부 "준비되지 않은" 애플리케이션(읽기: MyISAM)은 갑작스러운 종료 및 후속 복원으로 인해 다소 손상될 수 있으므로 일관성 확인이 필요합니다.
요점:I/O 장벽이 활성화된 저널 파일 시스템을 사용하는 경우(ext4 및 XFS의 기본값)그리고ACID 호환 데이터베이스를 사용하면 정지되지 않은 스냅샷을 안전하게 촬영할 수 있습니다. 최악의 경우 스냅샷을 마운트할 때 치명적이지 않은 오류/경고가 표시될 수 있지만 저널 응답으로 인해 시스템이 일관된 상태가 됩니다. 그러나 MyISAM을 사용하는 경우 스냅샷을 찍기 전에 파일 시스템을 동결/정지하는 것이 좋습니다.
답변2
시스템이 실행되는 동안 Amazon 스냅샷을 촬영하면 그 자체로는 안전하지 않습니다. 스냅샷을 생성하기 전에 시스템을 종료하면 안전합니다. 운영 체제 버퍼나 애플리케이션 버퍼(예: 데이터베이스)에 캐시된 파일 시스템 데이터는 스냅샷에 포함되지 않습니다. 이로 인해 복구할 수 없는 손상이 발생할 수 있습니다.
Linux와 Windows 모두 시스템을 정지시키는 메커니즘을 제공하는 OS를 가지고 있습니다(애플리케이션에 데이터를 디스크에 플러시하도록 알립니다). 이 작업이 완료되면 응용 프로그램을 계속 사용할 수 있도록 해동이 수행됩니다. 동결과 해동 사이에 스냅샷이 생성됩니다. 참고: 대부분의 애플리케이션은 동결/해동을 지원하지 않으며 일부는 이를 잘못 구현합니다. 공급업체 문서를 주의 깊게 검토하세요.
또 다른 중요한 항목은 애플리케이션이 데이터를 저장하는 위치를 검토하는 것입니다. 모범 사례 설계에 따라 데이터베이스는 데이터, 로그 등을 다른 파일 시스템에 저장합니다. 이는 한 볼륨의 스냅샷을 다른 볼륨(애플리케이션 및 해당 데이터를 성공적으로 복원하기 위해 세트로 필요할 수 있음)의 스냅샷과 다른 시간에 시작할 수 있음을 의미합니다.
핵심은 충돌 일관성 스냅샷과 애플리케이션 일관성 스냅샷의 차이점을 이해하는 것입니다.
다음은 차이점을 설명하는 EBS 스냅샷에 대한 기사입니다.
[Michael의 댓글 이후 업데이트]
스냅샷은 COW(기록 중 복사)를 구현합니다. 스냅샷이 시작되면 파일 시스템을 수정할 수 있습니다. 파일 시스템이 디스크 블록에 쓰는 경우 COW 하위 시스템은 스냅샷 중에 파일 시스템을 수정할 수 있도록 원본 블록을 내부 캐시에 복사합니다.
스냅샷 중에 파일 시스템을 고정 상태로 유지할 필요는 없습니다. 스냅샷 생성 중에 필요한 볼륨 데이터 구조가 생성/복사되므로 동결을 유지할 필요가 없습니다. 시스템과 메모리에 캐시된 데이터의 양, OS 및 애플리케이션 저널의 크기 등에 따라 동결/스냅샷/해제 주기는 몇 초 정도 빠를 수 있습니다.
다음은 Copy-on-Write에 대한 설명이 포함된 다양한 스냅샷 기술에 대한 기사입니다.