서버 제공 ETag의 캐시를 저장하는 대신 클라이언트 측에서 ETag를 계산할 수 있습니까? 그러면 md5 검사를 수행하는 것과 거의 같지만 ListObjects 응답에서 사용 가능한 데이터를 사용합니다. ETag 알고리즘이 서버 측 상태에 의존하지 않는 한…

아: https://forums.aws.amazon.com/thread.jspa?messageID=203510&state=hashArgs%23203510

찾으셨습니다 :-)

-- 세브

2014년 1월 17일 16:26에 Jeff Waugh < [email protected] [email protected] >에 다음과 같이 썼습니다.

아: https://forums.aws.amazon.com/thread.jspa?messageID=203510&state=hashArgs%23203510

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/aws/aws-cli/issues/599#issuecomment -32668382에서 확인하세요.

Amazon EU Societe a responsabilite limitee, 5 Rue Plaetis, L - 2338 Luxembourg, RCS Luxembourg n B 101818, Capital social: EUR 37.500. Autorisation d establissement en qualite de commercante n 104408.

예, 멀티파트 업로드에 대한 ETag를 안정적으로 계산할 수 없습니다. 그렇지 않으면 훌륭한 솔루션이 될 것입니다.

시간 동작에 대해 새 플래그(또는 2개)를 추가할 수 있습니까? 옵션 1의 경우 --check-timestamps , 옵션 2의 경우 --update-local-timestamps 수 있습니다. 이렇게 하면 사용자가 변경 사항에 대해 보다 강력한 검사를 지정하고 동시에 결과를 수용할 수 있습니다.

예, 옵션 1과 2에 플래그를 추가하는 것이 합리적인 접근 방식이라고 생각합니다. 한 가지 잠재적인 문제는 기본(지정된 옵션 없음) 동작에 sync 가 예상대로 동작하지 않는 경우가 있지만 이러한 옵션 중 하나로 기본 동작을 변경하는 것이 좋은 것인지 확신할 수 없다는 것입니다. 여기에서 우리가 만들 수 있는 잠재적인 절충안이 있습니다.

@jamesls 생성된 정적 웹 사이트를 배포하기 위해 sync 명령을 사용하고 있습니다.

현재 버전에서는 콘텐츠가 재생성되지 않더라도 사이트가 재생성될 때 mtime이 변경되기 때문에 동기화할 때마다 모든 파일을 다시 업로드하고 있습니다.

내 목적을 위해(그리고 이 멋진 도구를 사용하여 정적 사이트를 업로드하는 건강한 많은 사람들이 있다고 생각합니다) #575에서 제안한 대로 ETag를 통해 동기화하는 것이 가장 굉장할 것입니다. 옵션.

그것을 제외하고는 정적 사이트의 목적을 위해 길이 검사(약간 위험할 수 있음)가 작동합니다.

또 다른 옵션은 멀티파트 업로드를 비활성화하고 #575를 사용하는 것입니다. 즉시 엄청난 절약 효과를 볼 수 있습니다.

나는 반대의 문제를 발견했다. 동일한 크기를 가진 S3에서 파일을 변경했지만 최신 타임스탬프와 s3 동기화가 파일을 풀다운하지 않습니다.

AWS s3 동기화 s3://bucket/path/ 디렉토리

S3의 데이터를 보니... 시간대 문제 때문인 것 같아요.
속성은 다음 시간을 보여줍니다.

마지막 수정 날짜: 2014년 2월 21일 오전 10:50:33

그러나 HTTP 헤더는

최종 수정일: 2014년 2월 21일 금요일 15:50:33 GMT

Last Modified 속성에는 시간대가 표시되지 않습니까?

내 s3 sync 명령이 파일을 넣은 위치와 다른 시간대의 다른 서버에서 실행 중이기 때문에 파일이 과거에 있다고 생각하고 가져오지 않습니다.

모든 파일을 가져오도록 s3 cp로 변경해야 했습니다.

첫 번째 단계로 --size-only 인수를 구현해야 한다고 생각합니다. 일반적인 경우에는 문제가 해결되지 않지만 특정 시나리오의 경우 이는 도움이 될 것이며 특히 s3에 동기화되는 정적 사이트와 함께 위에서 참조한 사용 사례를 이해/설명하기 쉽습니다.

동기화할 파일이 대상보다 최신인 경우 동기화에는 항상 파일을 동기화하는 옵션이 있어야 한다고 생각합니다. 우리는 시스템 A에서 S3로, 그 후에 S3에서 시스템 B로 파일을 동기화하고 있습니다. 파일 크기가 변경되지 않으면(하지만 내용은 변경됨) 이 파일은 시스템 B에 도달하지 않습니다. 이 동작은 중단됩니다. 많은 파일과 동기화해도 상관없지만 변경된 파일은 절대 빠지면 안 됩니다.

내 이전 게시물에 따르면 "최신"은 시간대도 고려해야 합니다.
현재 한 시간대에서 S3로 파일을 푸시한 다음 다른 시간대에서 동기화하면 파일이 최신인지 올바르게 감지하지 못합니다.

@jamesls --size-only 인수에 더하여 --name-only 인수를 사용하는 데 관심이 있습니다. 즉, 파일 크기나 마지막 수정 시간을 확인하지 마십시오. 소스에는 있지만 대상에는 없는 파일을 복사하기만 하면 됩니다. 이 시나리오에서는 s3에서 로컬로 동기화하고 파일을 다운로드한 후에는 s3에서 파일이 변경되지 않을 것으로 예상합니다. 이 옵션으로 인해 로컬(nfs) 파일 시스템에 대한 작업이 줄어들면 성능이 향상될 수 있습니다.

@jamesls --size-only et al을 1.3.6에서 사용할 수 있어야 합니까?

사례 186692581에 대한 제 AWS 지원 담당자가 제 제안을 귀하에게 전달했다고 말했습니다.
어쨌든 의견을 위해 여기에 게시할 것이라고 생각했습니다.

나는 간단한 해결책이 fuzz factor를 도입하는 것이라고 생각합니다.
일반적으로 로컬 -> S3 복사에 5분 이상 걸리지 않는다면,
그런 다음 후속 시간 비교에서 10분 퍼지 계수를 사용합니다.
10분 이내의 상대 시간을 동일하게 취급하십시오.
S3 시간이 10분 이상 지난 경우 S3 -> 로컬에서 동기화합니다.
옵션으로 "--fuzz=10m"을 추가할 수 있습니다.

@jamesls @adamsb6
https://github.com/aws/aws-cli/pull/575 적어도 단일 부분 업로드 파일에 대해 좋은 옵션이 아닌가요?

S3에서 파일의 ETAG 형식을 확인하면 파일이 단일("ETAG = "MD5 Hash") 또는 다중 파트(ETAG = "MD5 Hash" - "Number of Parts")로 업로드되었는지 여부가 다를 수 있습니다. 모든 파일 로컬 MD5를 ETAG와 비교할 수 있으며 파일이 멀티파트로 업로드된 경우 건너뛸 수 있습니다.

모든 AWS 리전의 ec2 인스턴스와 동기화되는 S3 버킷의 특정 폴더에 많은 비디오 클립이 있는 고객이 있습니다. 모든 파일은 단일 부분으로 업로드됩니다.
현재 s3cmd로 인해 일부 파일이 손상되는 문제가 있습니다. 전체 동기화를 다시 수행하면 14TB의 트래픽이 청구됩니다.

우리의 문제: 손상된 파일은 s3의 원본 파일과 정확히 같은 크기를 가지며 s3cmd를 통한 잘못된 타임스탬프로 인해 위에서 언급한 옵션을 사용할 수 없습니다. 이 경우 --compare-on-etag 는 모든 파일을 다시 동기화하는 것을 방지하는 훌륭한 솔루션입니다.

aws s3 sync는 변경된 파일만 동기화하기 때문에 일반 동기화의 경우에도 단일 부분 업로드 파일이 있는 경우 --compare-on-etag 옵션이 좋습니다.

나는 sync 명령을 사용하는 데 필요한 최소 권한을 찾기 위해 3시간 동안 더 많은 시간을 보냈습니다. 내가 얻은 오류는 다음과 같습니다.
A client error (AccessDenied) occurred when calling the ListObjects operation: Access Denied

실제로 오류가 발생했을 때:
A client error (AccessDenied) occurred when calling the ListBucket operation: Access Denied

각 명령에 대한 최소 권한이 있는 테이블을 보여주는 도움말 항목은 _매우_ 도움이 될 것입니다.

404는 _정말 좋은 생각_인 것 같습니다. 읽기 전까지 동기화가 이미 이 작업을 수행했다고 생각했습니다.

편집: 명확히 하기 위해 "aws s3 sync"에 rsync와 같은 동작을 추가하십시오. 보고된 그 문제는 내가 처음에 이해했던 것과 같지 않은 것 같습니다.

최신 AWS-CLI-bundle.zip에는 위에서 구현한 수정 사항이 포함되어 있지 않기 때문에 git clone을 했습니다. "customizations"라는 폴더에서 새 코드를 볼 수 있습니다. 그러나 이 코드를 사용하여 aws-cli 명령을 생성하는 방법이 명확하지 않습니다. make-bundle을 실행해야 합니까?

네. 다음 단계를 사용하여 새 서버(Ubuntu)에 설치합니다.

git clone https://github.com/andrew512/aws-cli.git
cd aws-cli
pip install -r requirements.txt
sudo python setup.py install

좋아요.
버전 1.3.18에서 수정된 코드를 봅니다.
내 --exact-timestamps 매개 변수를 허용합니다.
이전에 설치한 최신 다운로드 번들이 1.3.21이라고 생각했습니다.

안정적인 버전 관리는 공식 AWS 릴리스에만 적용됩니다. 나는 1.3.18에서 리포지토리를 분기하여 보고할 버전이지만 이미 몇 가지 오래된 버전이며 1.3.22가 현재 가장 최신 버전입니다. AWS가 풀 요청을 수락하고 향후 공식 릴리스에 이 기능을 포함하기를 바랍니다. 이는 우리에게 매우 중요하며 꽤 의심스러운 기본 동작을 해결하는 데 도움이 됩니다.

@andrew512 늦어서 죄송합니다. 보내주신 PR은 좋은 생각이며 aws s3 sync 변경 사항이 효과가 있는 부분과 그렇지 않은 부분에 대한 고객 피드백을 받는 것이 정말 도움이 됩니다. 잠시 후 살펴보겠습니다.

내 생각에... 헤더 요청에 신경 쓰지 않는 사람들에게는 MD5에 대한 비교가 옵션이 되어야 합니다. 나는 (두 번째로) --compare-on-etag에 투표할 것입니다. 왜냐하면 한 서버에서 S3으로만 업데이트하기 때문입니다. 따라서 로컬 MD5 리포지토리는 저에게 문제가 되지 않습니다. 그러나 나는 우리가 무언가를 가질 필요가 있다고 확실히 생각합니다. 현재로서는 내 로컬 저장소와 S3 저장소가 동일한지 확신할 수 없습니다. 우리는 이와 같은 상태에 있습니까?

@장고블 +1

우리의 사용 사례는 이러한 파일이 git repo에 있고 구성 파일이므로 수정된 날짜나 파일 크기가 실제로 작동하지 않으므로 성능 영향을 처리할 수 있는 실제 md5 옵션을 보고 싶습니다.

git repo를 체크아웃할 때 파일 수정 날짜는 파일이 작성된 날짜이기 때문입니다. 또한 파일 변경이 다음과 같을 수 있기 때문에 파일 크기가 작동하지 않습니다.

foo="bar"

에게

foo="baz"

따라서 파일 크기가 변경되지 않습니다.

@jamesls 멀티파트 업로드에 대한 md5를 계산하기 위해 여기 에서 방법을 사용할 수 없는 이유는 무엇입니까? 그것은 나를 위해 일했습니다.

안녕하십니까,
또한 foo="bar"/foo="baz"로 잘 설명된 이 문제가 있습니다.
애플리케이션 배포에 S3 버킷을 사용하고 배포가 완료되면 모든 서버가 S3에서 동기화됩니다. 이 버그로 인해 동기화되지 않은 파일에서 연산자 >=의 문제가 <=로 변경된 경우가 몇 번 있었고 이 버그로 인해 동기화 명령이 그다지 안정적이지 않습니다. 크기는 같지만 내용이 다르므로 파일을 동기화해야 합니다.
나는 그것을하는 방법에 대한 특별한 조언이 없습니다. 죄송합니다. 그러나 나는 단지 내 유스 케이스를 공개하고 있습니다 :)

노드-ftpsync를 개발하는 동안 동일한 문제가 발생했습니다. AWS에 이 문제를 해결할 수 있는 마법 같은 솔루션이 있을 것이라고 생각했습니다.

1. 귀찮지만 필요합니다. mtime.equals 비교는 변경 사항을 감지하는 가장 빠르고 더러운 방법입니다. 불행히도 로컬 호스트와 원격 호스트 사이의 클럭 시간은 비교하기 전에 정규화되어야 합니다.

@ngbranitsky가 제안한 것처럼 ' 것이 좋습니다. node.js에서 그렇게 하는 것은 고통스러운 일이지만 파이썬에서는 비트 AND를 사용하여 마지막 몇 비트를 자르는 것만큼 쉬워야 합니다.

1. 부작용과 함께 작동할 수 있습니다. 서버의 MDTM(예: FTP mtime) 값과 일치하도록 로컬 mtime을 변경하여 이 옵션도 살펴보았습니다. 불행히도 FTP 서버 구현은 RFC와 거의 호환되지 않으며 MDTM을 포함하지 않을 수 있습니다. 예를 들어 FTP를 통한 파일 동기화는 클라이언트와 서버가 모두 완전하다는 보장이 없기 때문에 좋지 않습니다.

AWS에는 해당 문제가 없으므로 로컬 호스트에서 mtime이 사용되는 방식도 고려해야 합니다. 모든 동기화에서 mtime 값을 변경하여 해당 파일을 보는 트랜스파일러가 있는 경우 대량 업데이트 이벤트를 트리거하시겠습니까? 파일 변경 사항을 측정하기 위한 메트릭으로 mtime을 사용하는 다른 메타데이터 저장소가 있습니까?

1. 비용을 고려하지 않는다면 최고의 선택입니다. 추가 API 호출은 사용자에게 비용을 발생시킵니다(예: 금전적 비용). MD5는 파일 추가 및 변경된 파일에만 필요하지만 작은 파일 및/또는 자주 변경되는 파일을 많이 저장하는 사용자의 경우 추가될 수 있습니다.
2. 일관성을 보장하기 위한 단연코 최고의 선택이지만 구현하는 데 있어 가장 큰 어려움이기도 합니다.

이것이 일반적인 해결책이 아니라는 것을 알고 있지만 동기화를 위해 다음과 같은 선택적 동작을 보는 것이 매우 좋을 것입니다. 그것은 일종의 아니오와 같습니다. OP의 4는 더 나은 성능을 위해 수정되었습니다.

1. etag의 로컬 캐시는 로컬 파일 시스템에 대해 유지되며 선택적으로 버킷의 파일에 대한 대역 외 변경 사항이 없는 경우 서버는 사용자가 보장할 수 있습니다.
2. 로컬->서버를 동기화할 때 캐시 DB에 대한 mtime/size 비교를 사용하는 첫 번째 패스를 사용하여 로컬 파일의 잠재적 변경 사항을 확인합니다. (이는 fstat에 비해 비용이 많이 드는 md5를 불필요하게 다시 계산하는 것을 방지하기 위해 수행됩니다.)
3. 잠재적으로 변경된 세트의 경우 md5->etag가 다시 계산됩니다. 파일이 실제로 다른 경우 업로드됩니다. 로컬 캐시 DB는 로컬 파일에서 md5를 다시 계산하는 것을 방지하기 위해 어떤 경우에도 업데이트됩니다.

여기에서 사용 사례는 웹 맵 타일을 동기화하는 것입니다. 이 타일의 1% 미만은 일반적으로 매일 변경됩니다. 예외는 소스 데이터에서 삭제가 발생하여 타일의 공간 적용 범위를 변경하여 전체 맵 타일 세트를 재생성해야 하는 경우입니다.

문제는 관련된 엄청난 양입니다. 큰 멀티파트 업로드에 대한 논의는 사용 사례로 볼 수 있지만 많은 개별 작은 파일에 대한 논의는 아닙니다. 얼마나? 현재 약 2m가 있지만 훨씬 더 나빠질 수 있습니다. 예를 들어 확대/축소 수준 16에서 세계에는 1 << 16 x 1 << 16 또는 65536 x 65536 타일 또는 ~4b가 있습니다.

현재 옵션은 다음과 같습니다.

1. 일반적으로 aws-cli와 동기화하여 모든 것을 다시 업로드합니다.
   
   
   
   1. 전체적으로 가장 빠릅니다.
   
   
   2. 아아, 많은 불필요한 업로드가 발생합니다.
   
   
2. mtimes 대신 md5(etag)를 사용하는 s3cmd와 동기화합니다. 안타깝게도:
   
   
   
   1. 실행될 때마다 모든 로컬 파일에 대해 항상 md5를 다시 계산하는데, 이는 상대적으로 비용이 많이 들고 IOPS가 많습니다.
   
   
   2. 단일 스레드 및 메모리 바운드이며 항상 느리지만 많은 개별 파일을 업로드하는 경우 특히 느립니다. 특히 다른 S3 지역에 대기 시간이 긴 경우에 특히 느립니다.
   
   

디렉토리 경로를 걷고, 로컬 sqlite3 캐시 DB를 업데이트하고, 잠재적으로 변경된 설정/업로드 대기열을 구축하는 C 코드를 큰 어려움 없이 작성할 수 있습니다. 불행히도, 저는 파이썬 경험이 없으며 이것을 선택적 동기화 동작에 대한 풀 요청으로 제출할 수 없습니다.

"많은 작은 파일, 대역 외 변경 없음 보장, 로컬-> 서버 전용" 사용 사례가 얼마나 일반적인지 모르겠습니다.

소스의 최신 파일이 대상의 이전 파일을 대체하더라도 동기화가 마지막 수정 시간의 차이 를 업데이트의 이유로 취급하는 것이 직관적이지 않고 위험하다는 것을 알았습니다. 이 이상한 동작은 문서화해야 합니다.

또한 #404와 관련이 있습니다.

증가하는 비 자체 문서화 옵션 대신 단일 자체 문서화 --sync-if 플래그를 추가하는 것은 어떻습니까? (예: --size-only , --exact-timestamps . 이 두 가지를 동시에 적용할 수 있습니까? 문서를 읽어야 하고/이것을 알아내려고 시도해야 하는 이유는 무엇입니까?).

--sync-if 에는 다음과 같은 옵션 목록이 있을 수 있습니다.

--sync-if newer-timestamp,different-md5,different-timestamp,different-size,deleted,...

사용자는 하나 이상(쉼표로 구분된 목록)을 지정할 수 있으며 파일이 기준 중 하나라도 충족하면 대상에서 업데이트(업로드/삭제)됩니다.

이것은 특히 문서에서 기본 동작이 --sync-if different-timestamp,different-size 라고 언급한 경우 동작을 크게 명확하게 합니다.

이 문제를 읽어보면 이 동기화 동작이 아직 수정되었는지 알 수 없습니다.

로컬 빌드를 서버의 빌드와 동기화하기 위해 rsync -avz 처럼 간단하게 작동하는 것을 원합니다.

나는 aws s3 sync 하고 있었지만 큰 파일(동영상인 도움말 파일)이 하나 있고 빌드 단계에서 새 파일에서 모든 파일을 생성하기 때문에 매번 모든 파일을 복사하고 불필요하게 느려졌습니다. 사이트를 업데이트합니다.

그런 다음 속도를 높이기 위해 --size-only 를 사용하기 시작했습니다. 불행히도, 이것은 최근에 저를 물었습니다. 파일 이름을 변경했으며 빌드 단계에는 service-worker.js 파일에 파일 목록이 포함되어 있으므로 sw가 캐시할 항목을 알 수 있습니다. 불행히도 새 파일 이름과 이전 파일 이름의 길이가 동일하여 service-worker.js 파일을 업데이트하지 않고 이전 파일 이름에 계속 404를 제공했습니다. 무슨 일이 일어나고 있는지 알아내는 데 꽤 오랜 시간이 걸렸습니다.

이것은 다른 환경(예: rsync)에서 해결된 문제인 것처럼 보이지만, tbh, 나는 아마도 S3에서 이와 같은 작업을 수행할 때 나타나는 문제에 대해 다소 무지할 것입니다. 어쨌든 최근에 이것에 조금 의아해하면서 다른 클라이언트를 살펴보고 있지만 이 기능에 대해서만 채택하는 데 관심이 없는 종속성이 있는 것 같습니다.

etag 동기화 옵션이 있으면 좋을 것입니다. 실패하는 시나리오가 있다는 것을 알고 있지만 저에게는 매우 가치가 있습니다.

안녕하세요!

AWS CLI와 관련된 기능 요청을 위해 UserVoice 로 마이그레이션하는 과정의 일환으로 GitHub에서 이 문제를 종료합니다.

이렇게 하면 버그 보고서로 대화를 희석하지 않고도 가장 관심 있는 기능을 더 쉽게 검색하고 지원을 표시할 수 있으므로 가장 중요한 기능을 얻을 수 있습니다.

빠른 UserVoice 입문서(아직 익숙하지 않은 경우): 아이디어가 게시된 후 사람들은 아이디어에 투표할 수 있으며 제품 팀은 가장 인기 있는 제안에 직접 응답합니다.

GitHub에서 기존 기능 요청을 가져왔습니다. 여기에서 이 문제를 검색하세요!

그리고 걱정하지 마세요. 이 문제는 후대를 위해 GitHub에 계속 존재합니다. 원본 게시물을 UserVoice로 텍스트 전용으로 가져오기 때문에 GitHub 문제에 대해 이미 존재하는 의견과 토론을 계속 염두에 둘 것입니다.

GitHub는 버그 보고 채널로 남을 것입니다.

다시 한 번, 이 문제는 이제 https://aws.uservoice.com/forums/598381-aws-command-line-interface 에서 제목을 검색하여 찾을 수 있습니다.

-AWS SDK 및 도구 팀

이 항목은 특히 UserVoice( https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168808-aws-s3-sync-issues) 에서 찾을 수 있습니다.

https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168808-aws-s3-sync-issues

github 문제에서 벗어나고 계십니까? 그건 실수인듯...

동의. Microsoft가 문제의 중요성/영향을 판단하는 데 사용하는 방법과 비슷해 보이지만 상당히 짜증납니다.

커뮤니티 피드백을 기반으로 GitHub 문제에 기능 요청을 반환하기로 결정했습니다.

이 백업을 범프!

정상으로!

md5의 비교는 훌륭할 것입니다. 또한 업로드 또는 다운로드 시 md5를 출력하는 것이 도움이 될 것이라고 덧붙입니다. 이것은 우리 자신의 db에 저장될 수 있고 요청을 제한하기 위해 데이터베이스를 통해 동기화가 필요한지 결정하는 데 도움이 될 것입니다.

@jamesls 이 문제에 대해 의견을 말씀해 주시겠습니까?
https://github.com/aws/aws-cli/issues/4460