Etwa dann, wenn weitere Dokumente mit einer anderen Struktur indexiert werden sollen. Ein zusätzlicher Solr Index ist auch dann sinnvoll, wenn man zwischen Entwicklungsindex und Produktivindex trennen möchte; in diesem Zusammenhang auch, um neue Konfigurationen auf einer Instanz zu testen, während die zweite Instanz unverändert weiter läuft.
Im Idealfall kann man ad hoc zwischen beiden Konfigurationsalternativen wechseln.
Natürlich könnte man dazu diverse J2EE Container (tomcat, Jboss, Ant,...) parallel betrieben. Der Administrationsaufwand ist dafür allerdings "oversized", dann für genau diese Anwendungsfälle sind parallel Betriebene Solr Cores geschaffen.
Das Grundgerüst bleibt dabei bestehen mit dem Unterschied, dass die Solr Instanz nicht mehr nur einen, sondern mehrere Solr-Dienste bereit stellt.
Bevor wir mit den Arbeiten starten, muss die Solr Instanz gestoppt werden.
Die Konfiguration dazu ist recht trivial:
- Anlegen eines Basisverzeichnisse für jeden Core unter $SOLR_HOME, also dem Verzeichnis, in dem Solr Installiert ist. Nennen wir diese Basisverzeichnisse solr1 und solr2
- "deaktivieren" der Single-Core Umgebung und Konfigurieren der einzelnen Kernen.
Dazu muss die Konfiguration aus $SOLR_HOME/conf entfernt werden. Am besten verschieben wir dieses Verzeichnis gleich in das neu angelegte Verzeichnisch $SOLR_HOME/solr1 und kopieren es von dort ein weiteres mal nach $SOLR_HOME/solr2.
Die Struktur sieh daher wie folgt aus:
-$SOLR_HOME |-solr1/conf/ |-solr2/conf/ |-lib/ |-solr.xml |-[...]
Wichtig dabei: kein conf-Verzeichnis mehr im $SOLR_HOME. - Die eigentliche Konfiguration paralleler Solr Umgebungen passiert in der solr.xml. Die Datei liegt direkt im $SOLR_HOME.
<solr persistent="true" sharedLib="lib"> <cores adminPath="/admin/cores"> <core name="solr1" instanceDir="solr1"> <property name="solr.data.dir" value="solr/solr1/data"/> </core> <core name="solr2" instanceDir="solr2"> <property name="solr.data.dir" value="solr/solr2/data"/> </core> </cores> </solr>
In diesem Fall erzeugen wir 2 Kerne, solr1 und solr2. Der Name des Kerns ist gleich dem Namen der Instanz. Das wir später interessant, wenn wir die Kerne/Cores tauschen (switchen) wollen um die Anwender ad hoc auf die 2 Instanz zu schicken, ohne den Quellcode der Anwendung abzuändern.
<solr persistent="true" sharedLib="lib">
Mit persistent="true" definieren wir, dass alle Änderungen zur Laufzeit (hinzufügen neuer Cores, tauschen der Cores, etc) persistent sind und von Solr direkt in diese Datei eingetragen werden. Mit sharedLib="lib" definieren wir das gemeinsame Verzeichnis unterhalb von $SOLR_HOME für Bibliotheken. Dort werden Erweiterungen abgelegt, etwa JAVA Bibliotheken zum Data Import Handler, für Carrot2, etc.
Für beide Kerne haben wir ein data Verzeichnis definiert.
<property name="solr.data.dir" value="solr/solr2/data"/>
Das heißt, beide Cores arbeiten autark, mit eigener Konfiguration (unter solr1/conf bzw. solr2/conf) und jeweils eigenem Index - Start des J2EE Containers (tomcat, ant, etc.)
Keine Kommentare:
Kommentar veröffentlichen