Como StorageGRID S3 API REST conclui uploads multipartes
A operação CompleteMultipartUpload completa um upload de objeto em várias partes, montando as partes previamente carregadas.
|
|
StorageGRID suporta valores não consecutivos em ordem crescente para o parâmetro de solicitação `partNumber`CompleteMultipartUpload. O parâmetro pode começar com qualquer valor. |
Resolver conflitos
Solicitações conflitantes de clientes, como dois clientes gravando na mesma chave, são resolvidas com base no princípio "latest-wins". O momento da avaliação do "latest-wins" é determinado quando o sistema StorageGRID conclui uma determinada solicitação, e não quando os clientes S3 iniciam uma operação.
Cabeçalhos de solicitação suportados
Os seguintes cabeçalhos de solicitação são suportados:
-
x-amz-checksum-sha256 -
x-amz-storage-classO
x-amz-storage-classcabeçalho afeta quantas cópias de objetos o StorageGRID cria se a regra ILM correspondente especificar o "Opção de confirmação dupla ou ingestão balanceada". -
STANDARD(Padrão) Especifica uma operação de ingestão de confirmação dupla quando a regra ILM usa a opção Dual commit ou quando a opção Balanced recorre à criação de cópias intermediárias.
-
REDUCED_REDUNDANCYEspecifica uma operação de ingestão de confirmação única quando a regra ILM usa a opção de confirmação dupla ou quando a opção balanceada recorre à criação de cópias intermediárias.
Se você estiver ingerindo um objeto em um bucket com S3 Object Lock ativado, a REDUCED_REDUNDANCYopção será ignorada. Se você estiver ingerindo um objeto em um bucket legado Compliant, aREDUCED_REDUNDANCYopção retornará um erro. StorageGRID sempre realizará uma ingestão com confirmação dupla para garantir que os requisitos de conformidade sejam atendidos.
|
|
Se um upload multipart não for concluído em 15 dias, a operação é marcada como inativa e todos os dados associados são excluídos do sistema. |
|
|
O `ETag`valor retornado não é uma soma MD5 dos dados, mas segue a implementação da API do Amazon S3 do valor `ETag`para objetos multipartes. |
Cabeçalhos de solicitação não suportados
Os seguintes cabeçalhos de solicitação não são suportados:
-
If-MatchO
If-Match headeré aceito, mas não funcional. -
If-None-MatchO
If-None-Match headeré aceito, mas não funcional. -
x-amz-sdk-checksum-algorithm -
x-amz-trailer
Controle de versões
Esta operação conclui um upload multipart. Se o versionamento estiver habilitado para um bucket, a versão do objeto é criada após a conclusão do upload multipart.
Se o versionamento estiver habilitado para um bucket, um identificador único versionId é gerado automaticamente para a versão do objeto armazenado. Esse versionId também é retornado na resposta usando o x-amz-version-id cabeçalho da resposta.
Se o versionamento estiver suspenso, a versão do objeto será armazenada com um valor nulo versionId e, se já existir uma versão nula, ela será sobrescrita.
|
|
Quando o versionamento está habilitado para um bucket, a conclusão de um upload multipart sempre cria uma nova versão, mesmo que haja uploads multipart simultâneos concluídos na mesma chave de objeto. Quando o versionamento não está habilitado para um bucket, é possível iniciar um upload multipart e depois outro upload multipart pode ser iniciado e concluído primeiro na mesma chave de objeto. Em buckets sem versionamento, o upload multipart que for concluído por último terá precedência. |
Falha na replicação, notificação ou notificação de metadados
Se o bucket onde ocorre o upload multipart estiver configurado para um serviço de plataforma, o upload multipart será bem-sucedido mesmo que a replicação ou notificação associada falhe.
Um locatário pode acionar a falha na replicação ou a notificação atualizando os metadados ou as tags do objeto. Um locatário pode reenviar os valores existentes para evitar alterações indesejadas.