Solr Safe DataImport and Core Swap no site de alto tráfego

Question

olá companheiros técnicos,

Vamos assumir que temos um site (PHP) com milhões de visitantes por mês e nós executamos um índice SOLR no site com 4 milhões de documentos hospedados. O Solr está sendo executado em 4 servidores separados, onde um servidor é o mestre e outros 3 servidores são replicados.

lá pode ser inserido milhares de documentos em solr a cada 5 minutos. E além disso, o usuário pode atualizar sua conta que também deve acionar uma atualização do SOLR.

Eu estou procurando uma estratégia segura para reconstruir o índice rápido e seguro sem perder qualquer documento. E ter uma estratégia de delta / update. Eu pensei em uma estratégia e quero compartilhá-lo com especialistas aqui para ouvir sua opinião sobre e se eu deveria ir para essa abordagem ou se eles podem aconselhar algo (totalmente) diferente.

solr dataMport

Para todas as operações que quero usar um manipulador de importação de dados. Eu quero misturar dados e Delta importar para um arquivo de configuração como o DataMporthandlerdeltaqueryViafullimport . Estamos usando um banco de dados MySQL como DataSource.

índice de reconstrução

Para reconstruir o índice, tenho o seguinte em mente; Criamos um novo núcleo chamado 'Reindex' perto do núcleo 'ao vivo'. Com o dataMporthandler, reconstruindo completamente todo o conjunto de documentos (4 milhões de documentos) que leva cerca de 1-2 horas no total. No índice ao vivo, ainda há cada minuto algumas atualizações, inserções e exclusões.

Após a reconstrução, que demorou cerca de 1-2 horas, o novo índice ainda não é mais atualizado. Para tornar o atraso menor, fazemos uma importância "delta" contra o novo núcleo para cometer todas as alterações das últimas 1-2 horas. Quando isso é feito, o que faz um swap de core. O manipulador de importação 'delta' normal que é executado a cada minuto escolherá este novo núcleo.

Atualizações emitindo para Live Core

Para manter nosso núcleo ao vivo na faixa, corremos a importação do delta a cada minuto. Por causa do núcleo troca o núcleo Reindex (que é agora o núcleo ao vivo) será rastreado en mantido atualizado. Eu estou supondo que não deve ser realmente um problema se este índice estiver atrasado por alguns minutos, porque o dataMport.Properties também será trocado também? A Delta-Import supera esses minutos de atraso, mas deve ser possível.

Espero que você entenda minha situação e minha estratégia e possa aconselhar se estou fazendo isso do jeito certo em seus olhos. Também gostaria de saber se há algum gargalo onde eu não pensei? Estamos executando o SOLR versão 1.4.

Alguma pergunta que eu tenho é, sobre a replicação? Se o servidor principal trocar o núcleo como as salvas lidar com isso?

e existem riscos com a perda de documentos ao trocar, etc.

Obrigado antecipadamente!

Answer 1

boa (e difícil) pergunta!

A importação completa é uma operação muito pesada, em geral, é melhor executar consultas delta para atualizar apenas seu índice para as últimas alterações em seus rdms.Eu tenho por que você troca o mestre quando você precisa fazer uma importação completa: você mantém atualizado o núcleo ao vivo usando a Delta-Import enquanto a importação completa está sendo executada no novo núcleo, uma vez que leva duas horas.Soa bem, desde que a importação completa não seja usada que freqüentemente.

Em relação à replicação, certificar-se de que não haja qualquer replicação em andamento antes de trocar o núcleo mestre.Para mais detalhes sobre como funciona a replicação, você pode dar uma olhada no Solr Wiki Se você não tiverfeito ainda.

Além disso, teria certeza de que não há qualquer importação delta em execução no núcleo ao vivo antes de trocar o núcleo mestre.

Answer 2

Temos uma situação ligeiramente modificada no nosso final. Existem dois dataMporthandlers - um para importação completa, outros para a importação delta. A Importação Delta é acionada por um cron a cada 3 horas e leva alguns minutos para ser concluído. A importação completa de cerca de 10m documentos leva ~ 48hrs (insano!). Uma grande parte disso envolve latência de rede, uma vez que uma enorme quantidade de dados é buscada de uma tabela MySQL para cada documento. Essas duas tabelas residem em dois servidores MySQL diferentes e não podem ser unidos.

Temos um núcleo "ao vivo", que é aquele que tem importações delta. Nós introduzimos outro núcleo de 'reconstrução' e realizamos um índice completo que leva ~ 48hrs para terminar. Por esta altura, mantemos uma faixa de todos os documentos que foram atualizados / excluídos do núcleo "ao vivo" e, em seguida, faça uma importação delta em "reconstruir" núcleo, para obter os dois para o mesmo estado. Em um dia normal, uma vez que ambos os núcleos estão no mesmo estado, os trocaríamos e serviríamos da reconstrução do núcleo. (Quem monitorará que o núcleo de reconstrução é feito indexando e aplicou também patches delta?) Às vezes, às vezes, gostaríamos de ter os núcleos 'ao vivo' e 'reconstrução' ao mesmo tempo para 'testing ab'. Naquela época, tanto o núcleo 'ao vivo' e 'reconstrução' teria as importações delta para consistência, e ambos serviriam. Com base no resultado, gostaríamos de manter um e remover o outro trocando.

Para tornar toda essa configuração operacionalmente estável, planejamos introduzir um processo de monitor que verificaria se o núcleo 'reconstrução' é indexação ou feito com isso. Se tiver indexado, o processo de monitor a atualizaria com os documentos Delta e ativaria o Delta Indexing CRON para os núcleos. Após a conclusão da fase AB, um dos núcleos seria descarregado e o outro núcleo trocou. Os crack extra então seriam desativados. Há mais algumas partes móveis neste projeto e a confiabilidade do processo do monitor é fundamental para a operação suave. Quaisquer sugestões / alternativas?