SOLR SICURO DATA DATATIMPORT AND NORE SWAP SU SITO WEB-TRAFFICO

Question

Ciao colleghi tecnici,

Assumiamo che abbiamo un sito Web (PHP) con milioni di visitatori al mese e che eseguiamo un indice solr sul sito web con 4 milioni di documenti ospitati. SOLR è in esecuzione su 4 server separati in cui un server è replicato il master e altri 3 server.

là può essere inseriti migliaia di documenti in solr ogni 5 minuti. E inoltre, l'utente può aggiornare il proprio account che deve anche attivare un aggiornamento SOLR.

Sto cercando una strategia sicura per ricostruire l'indice veloce e sicuro senza mancare alcun documento. E avere un sicuro delta / strategia di aggiornamento. Ho pensato a una strategia e voglio condividerlo con esperti qui per ascoltare la loro opinione su e se dovrei andare per questo approccio o se potessi consigliare qualcosa (totalmente) diverso.

SOLR DataMport

Per tutte le operazioni voglio utilizzare un gestore di importazione dati. Voglio mescolare i dati e l'importazione delta in un unico file di configurazione come il dataIstporthandlerdeltaqueryviafullimport . Stiamo utilizzando un database MySQL come DataSource.

Indice di ricostruzione

Per ricostruire l'indice ho in mente quanto segue; Creiamo un nuovo nucleo chiamato "Reindex" vicino al nucleo "Live". Con DataIstporthandler ricostriamo completamente l'intero documento (4 milioni di documenti) che richiedono circa 1-2 ore in totale. Sull'indice dal vivo ci sono ancora ogni minuto alcuni aggiornamenti, inserti ed eliminazioni.

Dopo la ricostruzione, che ha richiesto circa 1-2 ore, il nuovo indice non è ancora molto aggiornato. Per rendere il ritardo più piccolo, facciamo un 'delta' importazione contro il nuovo nucleo per impegnare tutte le modifiche dalle ultime 1-2 ore. Quando questo è fatto che fanno uno scambio di core. Il normale gestore di importazione "delta" che funziona ogni minuto sceglierà questo nuovo nucleo.

impegnarsi aggiornamenti a Live Core

Per mantenere il nostro nucleo vivo in pista, eseguiamo l'importazione del delta ogni minuto. A causa dello swap del nucleo il nucleo Reindex (che ora è il nucleo vivo) sarà tracciato EN tenuto aggiornato. Immagino che non dovrebbe essere un problema se questo indice è ritardato per alcuni minuti perché DATAIMPORT.Properties sarà scambiata anche? Il delta-import ha sorpasso questi minuti di ritardo ma dovrebbero essere possibili.

Spero che tu capisca la mia situazione e la mia strategia e potessi consigliare se lo sto facendo nel modo giusto nei tuoi occhi. Inoltre vorrei sapere se ci sono colli di bottiglia in cui non pensavo? Stiamo eseguendo la versione SOLR 1.4.

Qualche domanda che ho è, per quanto riguarda la replica? Se il server master sposta il nucleo, come fa i salotti?

E ci sono dei rischi con i documenti perdenti durante lo scambio, ecc.

Grazie in anticipo!

Answer 1

Buona (e difficile) domanda!

L'importazione completa è un'operazione molto pesante, in generale è meglio eseguire query delta per aggiornare solo il tuo indice alle ultime modifiche dei tuoi RDMS.Ho il motivo per cui riesci a scambiare il master quando è necessario eseguire un'importazione completa: si tiene aggiornati il nucleo live usando delta-import mentre l'importazione completa è in esecuzione sul nuovo nucleo, poiché ci vogliono due ore.Sembra buono, purché la piena importazione non venga utilizzata frequentemente.

Per quanto riguarda la replica, sarei sicuro che non ci sia alcuna replicazione in corso prima di scambiare il nucleo master.Per ulteriori dettagli su come funziona la replica è possibile dare un'occhiata al solr wiki se non lo hai fattofatto ancora.

Inoltre, avrei assicurato che non ci sia alcuna delta-import in esecuzione sul nucleo vivo prima di scambiare il nucleo master.

Answer 2

Abbiamo una situazione leggermente modificata alla nostra parte. Esistono due dati di dati di dati - uno per la piena importazione, altro per l'importazione del delta. L'importazione delta viene attivata da un cron ogni 3 ore e richiede minuti da completare. L'intera importazione di documenti di circa 10 m prendere ~ 48 ore (folle!). Gran parte di ciò comporta la latenza di rete, poiché un'enorme quantità di dati è recuperata da una tabella MySQL per ogni documento. Queste due tabelle risiedono su due diversi server MySQL e non possono essere uniti.

Abbiamo un nucleo "dal vivo", che è quello che ha delle importazioni delta. Presentiamo un altro core "ricostruzione" ed eseguiamo un indice completo che richiede ~ 48 ore per finire. A questo punto, manteniamo una traccia di tutti i documenti che sono stati aggiornati / cancellati dal nucleo "Live", quindi eseguire un'importazione del delta nel nucleo 'Ricostruid', per ottenere entrambi allo stesso stato. In una giornata normale, una volta che entrambi i nuclei sono allo stesso stato, li scambiamo e serviremo dal nucleo di ricostruzione. (Chi monitorerà che il nucleo di ricostruzione è fatto di indicizzazione completa e ha anche applicato patch delta?)

A volte, vorremmo avere sia il nucleo del 'Live' e 'Ricostrud' che servono allo stesso tempo per "AB test". In quei tempi, sia il nucleo "Live" e il "ricostruzione" avrebbero le importazioni delta per la coerenza, ed entrambi sarebbero serviti. Sulla base del risultato, vorremmo tenerne uno e rimuovere l'altro scambiando.

Per rendere l'intera configurazione operativamente stabile, prevediamo di introdurre un processo di monitoraggio che controllerebbe se il nucleo "Ricostruid" è indicizzato o fatto con quello. Se ha indicizzato, il processo del monitor lo aggiornerà con i documenti Delta e attiva il cron di indicizzazione delta per entrambi i nuclei. Al completamento della fase AB, uno dei nuclei sarebbe scaricato e l'altro core scambiato. I film extra sarebbero quindi disabilitati.

Ci sono alcune parti più mobili in questo design e l'affidabilità del processo di monitor è fondamentale per il funzionamento regolare. Eventuali suggerimenti / alternative?