Zend_Search_Lucene Index in einer Load-Balanced-Umgebung verwalten

Question

Jeder Server im Cluster verfügt über einen Suchindex, der alle 15 Minuten von einem der Server synchronisiert wird. Dies wurde gemacht, weil das Anhängen an einen Index bei einem NFS aufgrund von Flock nicht möglich ist; siehe documentation (andernfalls würde der Index in einem freigegebenen Ordner sein, auf den alle Server zugreifen).

Das Problem, das ich habe, ist, dass, wenn eine Aktion ausgeführt wird, die Änderung des Index erfordert, die Änderungen auf der lokalen Kopie des Indexes erfolgt und ich eine Möglichkeit zum Synchronisieren dieser Änderungen zurück zu dem übergeordneten in benötigen möglichst wenig aufdringlich (so dass die Änderungen bei der nächsten Synchronisierung auf alle Server im Cluster übertragen werden).

Ich habe versucht, den übergeordneten Server-Index über http verweisen, aber das wird nicht funktionieren, weil mkdir nicht über http getan werden kann. Gibt es eine Möglichkeit, den Index eines Remote-Servers zu referenzieren? Wenn es einen völlig anderen Ansatz gibt, der ebenfalls berücksichtigt wird.

Answer 1

Wie ich diese Situation verstehe, wenn einer der Indizes des Servers eine Änderung erfährt, wollen Sie, dass der Hauptindex als Quelle des rsynch das Update vor dem nächsten erhält rsync findet statt - um alle Server mit dem Update zu aktualisieren.

Anstatt rsync-ing der Hauptserver-Index, warum rsync, um das Datum der letzten Änderung als Quelle für die rsync zu nehmen? Wenn also die letzte Aktualisierung des Index auf Server D größer ist als der Index auf Hauptserver A, synchronisieren Sie einfach alle Server auf der Quelle von D

. Habe ich Ihre Situation richtig verstanden?

bearbeiten

dann in diesem Fall bearbeiten Sie den Code, der den Index-es und fügen Sie eine Zeile, die, wenn die vorherige Build des Index anders war, wenn so ein exec Anruf an eine Shell starten überprüft, baut Skript oder erstellen Sie den Befehl manuell, um den zentralen Server zu aktualisieren. Auf diese Weise erhält der zentrale Server Updates im laufenden Betrieb und wenn die große Synchronisation ausfällt, haben Sie Ihr Problem gelöst.

Answer 2

Die beste Lösung, die ich mir vorstellen kann, ist, einem traditionelleren Master/Slave-Replikationsmuster zu folgen. Lassen Sie sich von der RDBMS-Replikation inspirieren: Alle Schreibvorgänge sollten zum Master gehen.

Natürlich können Sie dies nicht direkt tun. Wie Sie bereits erwähnt haben, können Sie nicht direkt in den Remote-Index schreiben.

Sie haben also nur eine Option: Stellen Sie auf Ihrem Master-Server eine API/einen Service zur Verfügung, die die Slaves indirekt zur Indexaktualisierung verwenden können. Dann werden alle Änderungen beim nächsten geplanten Push synchronisiert. Ich bin mir bewusst, dass dies eine signifikante Änderung Ihres Designs sein kann, aber in einer replizierten oder verteilten Umgebung ist dies oft notwendig.