Caricamento multiparte completo
Suggerisci modifiche
PDF
L'operazione completa di caricamento multiparte completa un caricamento multiparte di un oggetto assemblando le parti precedentemente caricate.
Risolvi i conflitti
Le richieste dei client in conflitto, come due client che scrivono sulla stessa chiave, vengono risolte in base alle "ultime vincite". La tempistica per la valutazione degli "ultimi successi" si basa sul momento in cui il sistema StorageGRID completa una data richiesta e non sul momento in cui i client S3 iniziano un'operazione.
Intestazioni delle richieste
Il x-amz-storage-class L'intestazione della richiesta è supportata e influisce sul numero di copie di oggetti create da StorageGRID se la regola ILM corrispondente specifica un comportamento di Ingest di doppio commit o bilanciato.
-
STANDARD(Impostazione predefinita) specifica un'operazione di ingest dual-commit quando la regola ILM utilizza l'opzione Dual commit o quando l'opzione Balanced (bilanciamento) torna alla creazione di copie interinali.
-
REDUCED_REDUNDANCYSpecifica un'operazione di ingest a commit singolo quando la regola ILM utilizza l'opzione di commit doppio o quando l'opzione di bilanciamento ritorna alla creazione di copie interinali.
Se si sta inserendo un oggetto in un bucket con il blocco oggetti S3 attivato, il REDUCED_REDUNDANCYl'opzione viene ignorata. Se si sta acquisendo un oggetto in un bucket compatibile legacy, ilREDUCED_REDUNDANCYl'opzione restituisce un errore. StorageGRID eseguirà sempre un ingest dual-commit per garantire che i requisiti di conformità siano soddisfatti.
|
Se un caricamento multiparte non viene completato entro 15 giorni, l'operazione viene contrassegnata come inattiva e tutti i dati associati vengono cancellati dal sistema. |
|
|
Il ETag Il valore restituito non è una somma MD5 dei dati, ma segue l'implementazione dell'API Amazon S3 di ETag valore per oggetti multiparte.
|
Versione
Questa operazione completa un caricamento multiparte. Se la versione è abilitata per un bucket, la versione dell'oggetto viene creata al termine del caricamento multiparte.
Se il controllo delle versioni è attivato per un bucket, viene visualizzato un valore univoco versionId viene generato automaticamente per la versione dell'oggetto memorizzato. Questo versionId viene inoltre restituito nella risposta utilizzando x-amz-version-id intestazione della risposta.
Se il controllo delle versioni è sospeso, la versione dell'oggetto viene memorizzata con un valore nullo versionId se esiste già una versione nulla, questa verrà sovrascritta.
|
|
Quando il controllo delle versioni è attivato per un bucket, il completamento di un caricamento multiparte crea sempre una nuova versione, anche se ci sono caricamenti multipli simultanei completati sulla stessa chiave a oggetti. Quando il controllo delle versioni non è abilitato per un bucket, è possibile avviare un caricamento multiparte e fare in modo che un altro caricamento multiparte venga avviato e completato prima sulla stessa chiave a oggetti. Nei bucket senza versione, il caricamento multiparte che completa l'ultimo ha la precedenza. |
Replica, notifica o notifica dei metadati non riuscite
Se il bucket in cui si verifica il caricamento multiparte è configurato per un servizio di piattaforma, il caricamento multiparte riesce anche se l'azione di replica o notifica associata non riesce.
In questo caso, viene generato un allarme in Grid Manager on Total Events (SMTT). Il messaggio Last Event (ultimo evento) visualizza “Failed to publish notifications for bucket-nameobject key” (Impossibile pubblicare le notifiche per la chiave bucket-nameobject) per l'ultimo oggetto la cui notifica non (Per visualizzare questo messaggio, selezionare NODES > Storage Node > Events. Visualizza ultimo evento nella parte superiore della tabella.) I messaggi degli eventi sono elencati anche nella /var/local/log/bycast-err.log.
Un tenant può attivare la replica o la notifica non riuscita aggiornando i metadati o i tag dell'oggetto. Un tenant può reinviare i valori esistenti per evitare modifiche indesiderate.