Concluir carregamento Multipart
Sugerir alterações
PDFs
A operação completa de Upload Multipart completa um upload multipart de um objeto, montando as peças carregadas anteriormente.
Resolver conflitos
As solicitações de cliente conflitantes, como dois clientes escrevendo para a mesma chave, são resolvidas com base em "vitórias mais recentes". O tempo para a avaliação "últimos ganhos" é baseado em quando o sistema StorageGRID completa uma determinada solicitação e não em quando os clientes S3 começam uma operação.
Cabeçalhos de solicitação
O x-amz-storage-class cabeçalho de solicitação é suportado e afeta quantas cópias de objeto criadas pelo StorageGRID se a regra ILM correspondente especificar um comportamento de ingestão de confirmação dupla ou equilibrada.
-
STANDARD(Padrão) especifica uma operação de ingestão de commit duplo quando a regra ILM usa a opção de commit duplo ou quando a opção Balanced retorna à criação de cópias provisórias.
-
REDUCED_REDUNDANCYEspecifica uma operação de ingestão de commit único quando a regra ILM usa a opção de commit duplo ou quando a opção Balanced retorna à criação de cópias provisórias.
Se você estiver ingerindo um objeto em um bucket com o S3 Object Lock ativado, a REDUCED_REDUNDANCYopção será ignorada. Se você estiver ingerindo um objeto em um bucket compatível com legado, aREDUCED_REDUNDANCYopção retornará um erro. A StorageGRID sempre realizará uma ingestão de confirmação dupla para garantir que os requisitos de conformidade sejam atendidos.
|
Se um upload multipart não for concluído dentro de 15 dias, a operação será marcada como inativa e todos os dados associados serã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 ETag valor para objetos multipart.
|
Controle de versão
Esta operação completa um upload de várias partes. Se o controle de versão estiver habilitado para um bucket, a versão do objeto será criada após a conclusão do upload de várias partes.
Se o controle de versão estiver habilitado para um bucket, um exclusivo versionId será gerado automaticamente para a versão do objeto que está sendo armazenado. Isso versionId também é retornado na resposta usando o x-amz-version-id cabeçalho de resposta.
Se o controle de versão estiver suspenso, a versão do objeto será armazenada com um nulo versionId e se já existir uma versão nula, ela será substituída.
|
|
Quando o controle de versão está habilitado para um bucket, concluir um upload multipart sempre cria uma nova versão, mesmo que haja carregamentos simultâneos de várias partes concluídos na mesma chave de objeto. Quando o controle de versão não está habilitado para um bucket, é possível iniciar um upload multipart e, em seguida, ter outro upload multipart iniciado e concluído primeiro na mesma chave de objeto. Em buckets não versionados, o upload multipart que completa o último tem precedência. |
Falha na replicação, notificação ou notificação de metadados
Se o intervalo onde ocorre o upload de várias partes estiver configurado para um serviço de plataforma, o upload de várias partes será bem-sucedido mesmo se a ação de replicação ou notificação associada falhar.
Se isso ocorrer, um alarme é gerado no Gerenciador de Grade em Eventos totais (SMTT). A mensagem último evento exibe "'Falha ao publicar notificações para chave de bucket-naameobject'" para o último objeto cuja notificação falhou. (Para ver esta mensagem, selecione NÓS > Storage Node > Eventos. Veja o último evento no topo da tabela.) As mensagens de evento também são listadas em /var/local/log/bycast-err.log.
Um locatário pode acionar a replicação ou notificação com falha atualizando os metadados ou as tags do objeto. Um locatário pode reenviar os valores existentes para evitar fazer alterações indesejadas.