Solr Safe DataImport- und Core Swap auf der High-Traffic-Website

Question

Hello-Mittechniker,

Nehmen wir an, wir haben eine (PHP) -Website mit Millionen von Besuchern pro Monat und wir führen einen Solr-Index auf der Website mit 4 Millionen Dokumenten, die gehostet werden. Solr läuft auf 4 separaten Servern, in denen ein Server der Master ist und andere 3 Server repliziert werden.

Dort kann Tausende von Dokumenten alle 5 Minuten in Solr eingefügt werden. Außerdem kann der Benutzer ihr Konto aktualisieren, das auch ein solRR-Update auslösen soll.

Ich suche nach einer sicheren Strategie, um den Index FAST und SAFE zu wieder aufzubauen, ohne jedes Dokument zu fehlen. Und eine sichere delta / update-Strategie. Ich habe an eine Strategie gedacht und möchte es hier mit Experten hier teilen, um ihre Meinung zu hören, und wenn ich für diesen Ansatz gehen sollte oder wenn sie etwas (total) anders raten könnte.

solr matasImport

Bei allen Vorgängen möchte ich einen Datenimport-Handler verwenden. Ich möchte Data- und Delta-Import in eine Konfigurationsdatei mischen, wie der datasImportHandlerdeltaqueryViafullInport . Wir verwenden eine MySQL-Datenbank als DataSource.

Wiederaufbau index

Zum Wiederaufbau des Index habe ich das folgende Beachten; Wir erstellen einen neuen Kern namens 'REINDEX' in der Nähe des "Live-Kerns". Mit dem DataImportHandler haben wir den gesamten Dokumentsatz (4 Millionen Dokumente) vollständig wieder aufgebaut, der insgesamt etwa 1-2 Stunden dauert. Auf dem Live-Index gibt es immer noch jede Minute einige Updates, Einfügungen und Löschungen.

Nach dem Wiederaufbau, das etwa 1-2 Stunden dauerte, ist der neue Index noch nicht mehr auf dem neuesten Stand. Um die Verzögerung kleiner zu gestalten, führen wir einen "Delta" -Importen gegen den neuen Kern, um alle Änderungen in den letzten 1-2 Stunden zu begehen. Wenn dies getan ist, was einen Kernwechsel machen. Der normale "Delta" -Import-Handler, der jede Minute läuft, wählt diesen neuen CORE auf.

Begegnerische Updates für Live-Kern

Um unseren Live-Kern im Track aufzubewahren, führen wir den Delta-Import jede Minute aus. Aufgrund des Kernwechsels wird der REINDEX-Kern (nun, der der Live-Core ist) verfolgt wird, um auf dem neuesten Stand zu bleiben. Ich vermute, es sollte nicht wirklich ein Problem sein, wenn dieser Index für einige Minuten verzögert wird, da DataImport.Properties auch ausgetauscht wird? Der Delta-Import hat diese Minutenverzögerung überholt, sollte jedoch möglich sein.

Ich hoffe, Sie verstehen meine Situation und meine Strategie und könnten beraten, wenn ich es in den Augen richtig mache. Ich möchte auch wissen, ob es irgendwelche Engpässe gibt, an die ich nicht darüber nachgedacht habe? Wir führen Solr-Version 1.4 aus.

Einige Frage, die ich habe, ist, was ist mit der Replikation? Wenn der Master-Server den Kern ausgibt, wie werden die Salven dies behandeln?

Und gibt es Risiken, wenn Sie Dokumente verlieren, wenn Sie tauschen usw.?

Vielen Dank im Voraus!

Answer 1

Gute (und harte) Frage!

Der vollständige Import ist ein sehr starker Betrieb, im Allgemeinen ist es besser, DELTA-Abfragen auszuführen, um Ihren Index nur auf die neuesten Änderungen in Ihrem RDMs zu aktualisieren.Ich habe, warum Sie den Master tauschen, wenn Sie einen vollständigen Import durchführen müssen: Sie behalten den Live-Core mit Delta-Import auf dem neuesten Stand, während der vollständige Import auf dem neuen Kern läuft, da er zwei Stunden dauert.Klingt gut, solange der vollimport nicht häufig verwendet wird.

In Bezug auf die Replikation würde ich sicherstellen, dass es keine Replikation läuft, bevor Sie den Master-Core tauschen.Weitere Informationen zu der Funktionsweise von Replikation können Sie auf die Solr Wiki sehen, wenn Sie dies nicht tunes noch getan.

Darüber hinaus würde ich sicherstellen, dass es keinen Delta-Import auf dem Live-Core läuft, bevor er den Master-Core tauscht.

Answer 2

Wir haben an unserem Ende eine leicht modifizierte Situation. Es gibt zwei DataImportHandlers - eine für den vollständigen Import, andere für Delta-Import. Der Delta-Import wird alle 3 Stunden von einem Cron ausgelöst und dauert nur wenige Minuten. Der vollständige Import von etwa 10 m-Dokumenten dauert ~ 48 Stunden (verrückt!). Ein großer Teil davon beinhaltet die Netzwerklatenz, da für jedes Dokument eine große Datenmenge von einer MySQL-Tabelle abgerufen wird. Diese beiden Tabellen befinden sich auf zwei verschiedenen MySQL-Servern und können nicht miteinander verbunden werden.

Wir haben einen "live" -Kern, der derjenige, der Delta-Importe hat. Wir führen einen anderen "Rebuild" -Kern ein und führen einen vollständigen Index aus, der ~ 48 Stunden dauert, um fertigzustellen. Zu diesem Zeitpunkt behalten wir alle Dokumente, die von 'Live'-Kern aktualisiert / gelöscht wurden, und dienen dann einen Delta-Import in "Rebuild" -Kern, um beide auf den gleichen Zustand zu bringen. An einem normalen Tag, sobald beide Kerne in demselben Zustand sind, würden wir sie austauschen und dienen von dem Rebuild-Kern. (Wer überwacht, dass der Rebuild-Kern voller Indizierung erfolgt und auch Delta-Patches angewendet hat?)

Manchmal möchten wir sowohl den "Live" als auch "Live" und "Rebuild" -Kern-Kern zur gleichen Zeit für 'AB-Tests' haben. In diesen Zeiten hätten sowohl der "Live- und 'Rebuild" -Kern Delta-Importe für Konsistenz, und beide würden dienen. Basierend auf dem Ergebnis möchten wir eins behalten und den anderen durch Wäsche entfernen.

Um diesen ganzen Setup operativ stabil zu machen, planen wir, einen Monitorprozess einzuführen, der prüfen würde, ob der Kern "Rebuild" -Kern indexiert oder mit diesem fertig ist. Wenn es indexiert ist, aktualisiert der Monitorprozess es mit den Delta-Dokumenten und aktiviert den Delta-Indexing-Cron für beide Kerne. Nach Beendigung der AB-Phase würde ein der Kern entladen und der andere Kern ausgetauscht. Die zusätzlichen Crons wären dann deaktiviert.

In diesem Design gibt es einige weitere bewegliche Teile und die Zuverlässigkeit des Monitorprozesses ist für den reibungslosen Betrieb von entscheidender Bedeutung. Alle Vorschläge / Alternativen?