Solr Safe DataImport et Core Swap sur le site Web à haut trafic

Question

Bonjour les autres techniciens,

Supposons que nous ayons un site Web (PHP) avec des millions de visiteurs par mois et nous exécutons un indice SOLR sur le site Web avec 4 millions de documents hébergés. SOLR s'exécute sur 4 serveurs distincts où un serveur est le maître et les 3 autres serveurs sont reproduits.

Là boîte être inséré des milliers de documents dans SOLR toutes les 5 minutes. Et en plus de cela, l'utilisateur peut mettre à jour son compte qui devrait également déclencher une mise à jour SOLR.

Je recherche une stratégie sûre pour reconstruire l'index vite et sûr sans manquer de document. Et pour avoir un sûr Delta / Stratégie de mise à jour. J'ai pensé à une stratégie et je veux le partager avec des experts ici pour entendre leur opinion et si je dois aller pour cette approche ou s'ils pouvaient conseiller quelque chose (totalement) différent.

Solr dataImport

Pour toutes les opérations, je souhaite utiliser un gestionnaire de données-import. Je souhaite mélanger les données et l'importer de Delta dans un seul fichier de configuration comme le Dataimporthandlerdeltaqueryviaufullimport. Nous utilisons une base de données MySQL en tant que source de données.

Index de reconstruction

Pour reconstruire l'indice, j'ai à l'esprit ce qui suit; Nous créons un nouveau noyau appelé «Reindex» près du noyau «live». Avec le DataI-Importhandler, nous reconstruisons complètement l'ensemble de l'ensemble de documents (4 millions de documents) qui prend environ 1 à 2 heures au total. Sur l'index en direct, il y a encore chaque minute des mises à jour, des inserts et des suppressions.

Après la reconstruction, qui a pris environ 1 à 2 heures, le nouvel index n'est plus vraiment à jour. Pour rendre le retard plus petit, nous faisons une importation «Delta» contre le nouveau noyau pour commettre tous les changements par rapport aux 1 à 2 dernières heures. Lorsque cela est fait qui fait un échange de noyau. Le gestionnaire d'importation «Delta» normal qui s'exécute chaque minute ramassera ce nouveau noyau.

Commiter les mises à jour de Live Core

Pour garder notre noyau en direct sur la piste, nous exécutons l'importation de Delta chaque minute. En raison de l'échange de noyau, le noyau de Reindex (qui est maintenant le noyau en direct) sera suivi en main à jour. Je suppose que cela ne devrait pas vraiment être un problème si cet index est retardé pendant quelques minutes car DataImport.Properties sera également échangée? L'important delta a dépassé ces minutes de retard mais devrait être possible.

J'espère que vous comprenez ma situation et ma stratégie et que vous pourriez conseiller si je le fais de la bonne façon dans vos yeux. Je voudrais également savoir s'il y a des goulots d'étranglement où je ne pensais pas? Nous exécutons SOLR version 1.4.

Une question que j'ai, c'est: qu'en est-il de la réplication? Si le serveur Master échange le noyau, comment les SILVES gère-t-il cela?

Et y a-t-il des risques avec des documents perdants lors de l'échange, etc.?

Merci d'avance!

Answer 1

Bonne (et dure) question!

L'important complet est une opération très lourde, en général, il est préférable d'exécuter des requêtes Delta pour mettre à jour votre index des dernières modifications de votre SHRM. J'ai compris pourquoi vous échangez le maître lorsque vous devez faire un import complet: vous vous tenez au courant du noyau en direct en utilisant le Delta-Import pendant que l'important complet fonctionne sur le nouveau noyau, car cela prend deux heures. Cela semble bon, tant que l'importance complète n'est pas utilisée fréquemment.

En ce qui concerne la réplication, je m'assurerais qu'il n'y a pas de réplication en cours avant d'échanger le noyau maître. Pour plus de détails sur le fonctionnement de la réplication, vous pouvez jeter un œil Solr Wiki Si vous ne l'avez pas encore fait.

De plus, je m'assurerais qu'il n'y a pas de Delta-Import sur le noyau en direct avant d'échanger le noyau maître.

Answer 2

Nous avons une situation légèrement modifiée à notre fin. Il existe deux DataI-Importhandlers - l'un pour l'importation complète, un autre pour Delta Import. L'importation Delta est déclenchée par un cron toutes les 3 heures et prend des minutes. L'importation complète d'environ 10 m de documents prend ~ 48 heures (folle!). Une grande partie de cela implique la latence du réseau, car une énorme quantité de données est récupérée à partir d'une table MySQL pour chaque document. Ces deux tables résident sur deux serveurs MySQL différents et ne peuvent pas être joints.

Nous avons un noyau «en direct», qui est celui qui a des importations delta. Nous présentons un autre noyau «reconstruire» et effectuons un index complet qui prend ~ 48 heures pour terminer. À ce moment-là, nous gardons une trace de tous les documents qui ont été mis à jour / supprimés du noyau «live», puis faisons une importation delta dans le noyau «Rebuild», pour les amener tous les deux au même état. Par une journée normale, une fois que les deux noyaux sont au même état, nous les échangerions et servrions de la reconstruction du noyau. (Qui surveillera que le noyau de reconstruction est fait d'indexation complète et a également appliqué les correctifs Delta?)

Parfois, nous voudrions avoir le noyau «en direct» et «reconstruire» en même temps pour «AB Testing». À cette époque, le noyau «live» et «reconstruire» aurait des importations delta pour la cohérence, et les deux seraient en service. Sur la base du résultat, nous aimerions en garder l'un et en retirer l'autre en échangeant.

Afin de rendre toute cette configuration stable sur le plan opérationnel, nous prévoyons d'introduire un processus de moniteur qui vérifierait si le noyau «reconstruire» est indexé ou fait avec cela. S'il a indexé, le processus de moniteur le mettrait à jour avec les documents Delta et activrait le Delta Indexing Cron pour les deux cœurs. À la fin de la phase AB, l'un des noyaux serait déchargé et l'autre noyau échangé. Les Cons supplémentaires seraient alors désactivés.

Il y a quelques pièces mobiles supplémentaires dans cette conception et la fiabilité du processus de moniteur est essentielle au fonctionnement fluide. Des suggestions / alternatives?