Hallo Kollegen,
Nehmen wir an, wir haben eine (PHP) -Website mit Millionen von Besuchern pro Monat und wir betreiben einen SolR-Index auf der Website mit 4 Millionen gehosteten Dokumenten. Solr läuft auf 4 separaten Servern, wobei ein Server der Master ist und weitere 3 Server repliziert werden.
Dort können Tausende von Dokumenten alle fünf Minuten in Solr eingefügt werden. Und außerdem kann der Benutzer sein Konto aktualisieren, was auch eine Aktualisierung von solr auslösen sollte.
Ich suche nach einer sicheren Strategie, um den Index schnell und sicher wiederherzustellen, ohne ein Dokument zu verlieren. Und um eine sichere Delta / Update-Strategie zu haben. Ich habe über eine Strategie nachgedacht und möchte sie hier mit Experten teilen, um ihre Meinung zu hören und ob ich mich für diesen Ansatz entscheiden sollte oder ob sie etwas (total) anderes raten könnten.
Solr-Datenimport
Für alle Operationen möchte ich einen Datenimport-Handler verwenden. Ich möchte Daten und Delta-Import in eine Konfigurationsdatei wie den DataImportHandlerDeltaQueryViaFullImport mischen. Wir verwenden eine MySQL-Datenbank als Datenquelle.
Neuerstellungsindex
Für den Wiederaufbau des Index habe ich folgendes im Hinterkopf; Wir erstellen einen neuen Kern namens "Reindex" in der Nähe des "Live" -Kerns. Mit dem dataimporthandler erstellen wir das gesamte Dokumenten-Set (4 Millionen Dokumente) komplett neu, was insgesamt ca. 1-2 Stunden dauert. Auf dem Live-Index gibt es noch jede Minute ein paar Updates, Einfügungen und Löschungen.
Nach dem Umbau, der ungefähr 1-2 Stunden dauerte, ist der neue Index immer noch nicht wirklich aktuell. Um die Verzögerung zu verringern, machen wir einen Delta-Import gegen den neuen Kern, um alle Änderungen der letzten 1-2 Stunden zu übernehmen. Wenn dies gemacht wird, wird ein Core-Swap durchgeführt. Der normale 'Delta'-Import-Handler, der jede Minute ausgeführt wird, hebt diesen neuen Kern auf.
Updates werden in den Live-Core übernommen
Um unseren Live-Kern in der Spur zu halten, führen wir jede Minute den Delta-Import durch. Aufgrund des Core-Swaps wird der Reindex-Core (der jetzt der Live-Core ist) verfolgt und auf dem neuesten Stand gehalten. Ich nehme an, dass es kein Problem sein sollte, wenn dieser Index für einige Minuten verzögert wird, weil dataimport.properties auch vertauscht wird? Der Delta-Import hat diese Minuten der Verzögerung überholt, sollte aber möglich sein.
Ich hoffe, du verstehst meine Situation und meine Strategie und kannst beraten, ob ich es in deinen Augen richtig mache. Ich würde auch gerne wissen, ob es irgendwelche Engpässe gibt, an die ich nicht gedacht habe? Wir betreiben Solr Version 1.4.
Eine Frage, die ich habe, ist, was ist mit der Replikation? Wenn der Master-Server den Core tauscht, wie gehen die Salves damit um?
Und gibt es Risiken beim Verlust von Dokumenten beim Austausch usw.?
Vielen Dank im Voraus!
Gute (und harte) Frage!
Der vollständige Import ist eine sehr schwere Operation. Im Allgemeinen ist es besser, Delta-Abfragen auszuführen, um Ihren Index nur auf die neuesten Änderungen in Ihrem RDMS zu aktualisieren. Ich habe verstanden, warum Sie den Master austauschen, wenn Sie einen vollständigen Import durchführen müssen: Sie halten den Live-Core mit Delta-Import auf dem neuesten Stand, während der vollständige Import auf dem neuen Core läuft, da es zwei Stunden dauert. Hört sich gut an, solange der Full-Import nicht so häufig genutzt wird.
In Bezug auf die Replikation würde ich sicherstellen, dass keine Replizierung stattfindet, bevor der Hauptkern ausgetauscht wird. Für weitere Details zur Funktionsweise der Replikation können Sie sich das Solr-Wiki ansehen, falls Sie es noch nicht gemacht haben.
Außerdem würde ich sicherstellen, dass kein Delta-Import auf dem Live-Core ausgeführt wird, bevor der Master-Core ausgetauscht wird.
Wir haben eine leicht veränderte Situation an unserem Ende. Es gibt zwei DataImportHandlers - einen für den vollständigen Import, einen anderen für den 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 Millionen Dokumenten dauert ~ 48 Stunden (Wahnsinn!). Ein großer Teil davon betrifft die Netzwerklatenz, da für jedes Dokument eine große Menge an Daten aus einer MySQL-Tabelle abgerufen wird. Diese beiden Tabellen befinden sich auf zwei verschiedenen MySQL-Servern und können nicht verbunden werden.
Wir haben einen "lebenden" Kern, der Delta-Importe hat. Wir führen einen weiteren "Rebuild" -Kern ein und führen einen vollständigen Index aus, der ca. 48 Stunden dauert. Zu diesem Zeitpunkt verfolgen wir alle Dokumente, die aus dem "Live" -Kern aktualisiert / gelöscht wurden, und führen dann einen Delta-Import im "Neuaufbau" -Kern durch, um beide in den gleichen Zustand zu bringen. An einem normalen Tag, wenn beide Kerne im selben Zustand sind, tauschen wir sie aus und dienen dem Wiederaufbau des Kerns. (Wer überwacht, dass der Wiederherstellungskern vollständig indexiert wurde und auch Delta-Patches angewendet hat?)
Manchmal möchten wir, dass sowohl der "Live" - als auch der "Rebuild" -Kern gleichzeitig für das "Ab-Testen" dienen. In diesen Zeiten würden sowohl der "Live" - als auch der "Rebuild" -Kern Delta-Importe zur Konsistenz haben, und beide würden dienen. Basierend auf dem Ergebnis möchten wir eines behalten und das andere durch Austausch entfernen.
Um das gesamte Setup betriebssicher zu machen, planen wir, einen Monitorprozess einzuführen, der prüft, ob der 'rebuild' Kern indexiert oder damit fertig ist. Wenn es indiziert wurde, würde der Überwachungsprozess es mit den Deltadokumenten aktualisieren und das Delta-Indizierungscron für beide Kerne aktivieren. Nach Abschluss der ab-Phase würde einer der Kern entladen und der andere Kern ausgetauscht werden. Die zusätzlichen Crons wären dann deaktiviert.
Es gibt ein paar mehr bewegliche Teile in diesem Design und die Zuverlässigkeit des Monitorprozesses ist entscheidend für den reibungslosen Betrieb. Irgendwelche Vorschläge / Alternativen?
Tags und Links architecture solr high-availability dataimporthandler high-traffic