Wir verwenden die Hibernate-Suche für die Volltext-Indizierung unserer Entitäten in Wildfly 8.2 (unter Verwendung der Hibernate / Hibernate-Search- und Infinspan-Bibliotheken, die in Wildfly 8.2 enthalten sind). Ausführung als eigenständiger Knoten oder in einer Domäne mit einem dedizierten Suchmaster im Ruhezustand und demorg.hibernate.search.store.impl.FSDirectoryProvider das funktioniert schon seit einigen jahren (und jboss-versionen).

Wir möchten dieses System jetzt in einer HA-Clusterumgebung bereitstellen, in der Wildfly 8.2 hinter einem Proxy für den Lastenausgleich ausgeführt wird. Wir wollen einen dynamisch skalierbaren Cluster ohne Ausfallstelle im Sinne eines Domain-Masters oder eines Hibernate-Search-Masters und haben diesen mit Standalone-Knoten ohne Domain konfiguriert. Zur Wahl des HS-Masters verwenden wir das Backend von jgroups und zur Replikation der Daten für die Suche im Ruhezustand verwenden wir den Infinispan-Provider mit einemfile-store, um Daten zwischen Neustarts beizubehalten.

Ich habe es schnell zum Laufen gebracht und war ziemlich aufgeregt, da es ein robustes und skalierbares Szenario zu sein scheint, aber ich bin etwas zögerlich, diese Konfiguration in Produktion zu bringen, da das Backend von jgroups als "experimentell" (und in einigen Fällen als "experimentell") bezeichnet wurde Foren "extrem experimentell"). Wie ist der aktuelle Status des Backends? Verwenden die Leute es derzeit in der Produktion? Was können wir mit dieser Konfiguration tun, um das Risiko zu minimieren?

Auch hat jemand Erfahrung mit der Verwendung von Infinispan zusammen mit der Suche im Ruhezustand in dieser Konstellation? Die meisten Einstellungen zureplicated-cache wurde einfach aus vorhandenen Beispielen wiederverwendet, wenn jemand Tipps oder Ratschläge zu diesen Einstellungen hat, z. B. wird es mit Indizes ~ 50 GB skaliert? Für Feedback oder Erfahrungen mit ähnlichen Szenarien wäre ich Ihnen sehr dankbar.

Die Konfiguration wurde größtenteils mit Referenzmaterial von hier zusammengestellt:

http: //docs.jboss.org/hibernate/stable/search/reference/en-US/html_singlehttps: //forum.hibernate.org/viewtopic.php? f = 9 & t = 1035437

Die detaillierten Schritte, die wir unternommen haben, sind unten aufgeführt.

ls Basis haben wir das @ genommen und erweitestandalone-ha-full.xmlconfigure jgroups zur Verwendung des TCP-Stacksrun TCPPING anstelle von MPing (wir planen, dies in einem Cloud-Kontext auszuführen, in dem Multicast / udp Probleme verursacht - wir könnten zu JDBCPing wechseln, um dies irgendwann flexibler zu machen). Wir führen mit den folgenden Systemeigenschaften pro Knoten aus (Name / Port ändert sich natürlich pro Knoten)

Systemeigenschaften

<system-properties>        
   <property name="jboss.node.name" value="node2" />  
   <property name="jboss.socket.binding.port-offset" value="889" />  
   <!-- Automatic master election via JGroups, requires Infinispan directory provider -->
   <property name="hibernate.search.default.worker.backend" value="jgroups"/>
   <!-- Enable cluster-replicated index, but the default configuration does not enable any 
   form of permanent persistence for the index, we do this with cache-container/file-store below  -->
   <property name="hibernate.search.default.directory_provider" value="infinispan" />
   <property name="hibernate.search.infinispan.chunk_size" value="300000000" />
   <property name="hibernate.search.reader.strategy" value="shared" />
   <property name="hibernate.search.worker.execution" value="sync" />
   <property name="hibernate.search.default.optimizer.operation_limit.max"    value="10000"/>
   <property name="hibernate.search.default.optimizer.transaction_limit.max"    value="1000"/>
   <!-- Use CacheManager defined in WildFly configuration file, e.g., standalone.xml -->
   <property name="hibernate.search.infinispan.cachemanager_jndiname" value="java:jboss/infinispan/container/hibernate-search"/>
</system-properties>     

Wir haben folgendes definiert<cache-container> für infinispan:

<!-- BEGIN HIBERNATE INFINISPAN CACHE -->
<cache-container name="hibernate-search" jndi-name="java:jboss/infinispan/container/hibernate-search" start="EAGER">
    <transport lock-timeout="330000"/>
    <replicated-cache name="LuceneIndexesMetadata" start="EAGER" mode="SYNC" remote-timeout="330000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
        <file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
            <write-behind/>
        </file-store>
        <indexing index="NONE"/>
    </replicated-cache>
    <replicated-cache name="LuceneIndexesData" start="EAGER" mode="SYNC" remote-timeout="25000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
       <file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
            <write-behind/>
        </file-store>
        <indexing index="NONE"/>
    </replicated-cache>
    <replicated-cache name="LuceneIndexesLocking" start="EAGER" mode="SYNC" remote-timeout="25000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
        <indexing index="NONE"/>
    </replicated-cache>
</cache-container>
<!-- END HIBERNATE INFINISPAN CACHE -->

s ist mein Verständnis (und es scheint in der Praxis mit meinen Tests zu funktionieren), dass infinispan seine Daten zu dem konfigurierten @ serialisier<file-store> und die Daten bleiben dann zwischen den Neustarts des Knotens erhalten. Sogar einige katastrophale Tests (z. B.kill -9 <jboss-pid>) hat gezeigt, dass der Index sauber wiederhergestellt wird, wenn der Knoten wieder hochgefahren wird. Während der Offline-Phase übernimmt ein anderer Knoten die Funktion des Masters und der Cluster läuft reibungslos.