Archivio dati raccolta oggetti inattivi data-store-garbage-collection

Quando una risorsa WCM convenzionale viene rimossa, il riferimento al record dell'archivio dati sottostante può essere rimosso dalla gerarchia dei nodi, ma il record dell'archivio dati stesso rimane. Questo record dell'archivio dati senza riferimento diventa quindi "spazzatura" che non deve essere conservata. Nei casi in cui esistono diverse risorse di rifiuti, è utile sbarazzarsene per preservare lo spazio e ottimizzare le prestazioni di backup e manutenzione del file system.

Nella maggior parte dei casi, un'applicazione WCM tende a raccogliere informazioni ma non a eliminarle con la stessa frequenza. Anche se vengono aggiunte nuove immagini, anche in sostituzione delle versioni precedenti, il sistema di controllo delle versioni mantiene quello vecchio e supporta il ripristino, se necessario. Pertanto, la maggior parte dei contenuti che consideriamo come aggiunta al sistema viene effettivamente conservata in modo permanente. Quindi qual è la fonte tipica di "spazzatura" nel deposito in cui potremmo voler ripulire?

AEM utilizza l’archivio come archivio per una serie di attività interne e di gestione delle risorse:

Quando uno qualsiasi di questi oggetti temporanei è sufficientemente grande da richiedere l'archiviazione nell'archivio dati e quando l'oggetto alla fine smette di essere utilizzato, il record dell'archivio dati stesso rimane come "spazzatura". In una tipica applicazione di authoring/pubblicazione WCM, la più grande fonte di rifiuti di questo tipo è comunemente il processo di attivazione di pubblicazione. Quando i dati vengono replicati in Pubblica, vengono raccolti per la prima volta nelle raccolte in un formato di dati efficiente chiamato "Durbo" e memorizzati nell'archivio sotto /var/replication/data. I bundle di dati sono spesso più grandi della soglia di dimensione critica per l'archivio dati e quindi vengono archiviati come record dell'archivio dati. Al termine della replica, il nodo in /var/replication/data viene eliminato, ma il record dell'archivio dati rimane come "spazzatura".

Un'altra fonte di rifiuti recuperabili sono i pacchetti. I dati del pacchetto, come tutto il resto, vengono memorizzati nell’archivio e quindi per i pacchetti di dimensioni superiori a 4 KB, nell’archivio dati. Nel corso di un progetto di sviluppo o nel tempo durante la manutenzione di un sistema, i pacchetti possono essere generati e ricostruiti più volte, ogni build determina un nuovo record dell'archivio dati, orfando il record della build precedente.

Come funziona la raccolta degli oggetti inattivi nell’archivio dati? how-does-data-store-garbage-collection-work

Se il repository è stato configurato con un archivio dati esterno, la raccolta degli oggetti inattivi dell'archivio dati viene eseguita automaticamente come parte della finestra Manutenzione settimanale. L'amministratore di sistema può anche eseguire manualmente la raccolta degli oggetti dell'archivio dati se necessario. In generale, si consiglia di eseguire periodicamente la raccolta degli oggetti inattivi nell’archivio dati, ma di tenere conto dei seguenti fattori nella pianificazione delle raccolte di oggetti inattivi nell’archivio dati:

Il Garbage Collector dell'archivio dati nota prima la marca temporale corrente all'inizio del processo. La raccolta viene quindi eseguita utilizzando un algoritmo di pattern a punti/sweep multipli.

Nella prima fase, il Garbage Collector dell’archivio dati esegue un attraversamento completo di tutto il contenuto dell’archivio. Per ogni oggetto di contenuto che ha un riferimento a un record dell'archivio dati, ha individuato il file nel file system, eseguendo un aggiornamento dei metadati — modificando l'attributo "last modified" o MTIME. A questo punto i file a cui si accede da questa fase diventano più recenti della marca temporale iniziale della linea di base.

Nella seconda fase, il Garbage Collector dell'archivio dati attraversa la struttura di directory fisica dei dati archiviati nello stesso modo di un "find". Ha esaminato l'attributo "last modified" o MTIME del file ed effettua la seguente determinazione:

Questo approccio funziona bene per un singolo nodo con un archivio dati privato. Tuttavia l'archivio dati può essere condiviso e, se ciò significa che i riferimenti live potenzialmente attivi ai record dell'archivio dati di altri archivi non sono controllati e i file di riferimento attivi possono essere rimossi erroneamente. È fondamentale che l’amministratore di sistema comprenda la natura condivisa dell’archivio dati prima di pianificare qualsiasi raccolta di oggetti inattivi e utilizzi solo il semplice processo integrato di raccolta degli oggetti inattivi dell’archivio dati quando è noto che l’archivio dati non è condiviso.

Esecuzione della raccolta degli oggetti inattivi dell'archivio dati running-data-store-garbage-collection

Esistono tre modi per eseguire la raccolta degli oggetti inattivi dell’archivio dati, a seconda della configurazione dell’archivio dati in cui AEM in esecuzione:

Se TarMK viene utilizzato sia come archivio nodi che come archivio dati, allora Revision Cleanup può essere utilizzato per la raccolta degli oggetti inattivi sia dell'archivio nodi che dell'archivio dati. Tuttavia, se un archivio dati esterno è configurato, ad esempio Archivio dati del file system, la raccolta degli oggetti inattivi dell'archivio dati deve essere attivata in modo esplicito separatamente dal cleanup delle revisioni. La raccolta degli oggetti inattivi dell’archivio dati può essere attivata tramite il dashboard delle operazioni o la console JMX.

La tabella seguente mostra il tipo di raccolta degli oggetti inattivi dell’archivio dati che deve essere utilizzato per tutte le distribuzioni di archiviazione dati supportate nel AEM 6:

Esecuzione della raccolta degli oggetti inattivi dell’archivio dati tramite il dashboard delle operazioni running-data-store-garbage-collection-via-the-operations-dashboard

Finestra di manutenzione settimanale integrata, disponibile tramite Dashboard delle operazioni, contiene un'attività incorporata per attivare la Raccolta rifiuti dell'archivio dati all'1 del mattino della domenica.

Se devi eseguire la raccolta degli oggetti inattivi dell’archivio dati al di fuori di questo periodo di tempo, puoi attivarla manualmente tramite il dashboard delle operazioni.

Prima di eseguire la raccolta degli oggetti inattivi dell'archivio dati è necessario verificare che non siano in esecuzione backup in quel momento.

Esecuzione della raccolta degli oggetti inattivi dell’archivio dati tramite la console JMX running-data-store-garbage-collection-via-the-jmx-console

Questa sezione descrive come eseguire manualmente la raccolta degli oggetti inattivi dell’archivio dati tramite la console JMX. Se l'installazione è configurata senza un archivio dati esterno, questo non si applica all'installazione. Vedi invece le istruzioni su come eseguire la pulizia delle revisioni in Manutenzione dell’archivio.

Per eseguire la raccolta degli oggetti inattivi:

Automazione della raccolta degli oggetti inattivi nell’archivio dati automating-data-store-garbage-collection

Se possibile, è necessario eseguire la raccolta degli oggetti inattivi dell'archivio dati quando il sistema non è caricato, ad esempio la mattina.

Finestra di manutenzione settimanale integrata, disponibile tramite Dashboard delle operazioni, contiene un'attività incorporata per attivare la Raccolta rifiuti dell'archivio dati all'1 del mattino della domenica. È inoltre necessario verificare che al momento non siano in esecuzione backup. L'inizio della finestra di manutenzione può essere personalizzato tramite il dashboard, a seconda delle necessità.

Se non desideri eseguire la raccolta oggetti inattivi dell'archivio dati con la finestra Manutenzione settimanale nel Dashboard delle operazioni, puoi anche automatizzarla utilizzando i client HTTP wget o curl. Di seguito è riportato un esempio di come automatizzare il backup utilizzando curl:

Ecco un esempio di comando curl per richiamare l'archivio dati garbage collection tramite la riga di comando:

curl -u admin:admin -X POST --data markOnly=true  http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

Il comando curl ritorna immediatamente.

Verifica della coerenza dell’archivio dati checking-data-store-consistency

Il controllo di coerenza dell'archivio dati segnalerà tutti i file binari dell'archivio dati mancanti ma a cui si fa ancora riferimento. Per avviare un controllo di coerenza, effettua le seguenti operazioni:

Al termine del controllo di coerenza, un messaggio mostra il numero di binari segnalati come mancanti. Se il numero è maggiore di 0, controlla il error.log per maggiori dettagli sui binari mancanti.

Di seguito trovi un esempio di come vengono segnalati i file binari mancanti nei registri:

11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs

11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243