Hibernate-Suche + Infinispan + jgroups Back-End-Slave-Sperre Ausgabe

Question

Ich bin neu in der Ruhezustand-Suche. Wir haben uns entschieden, die Hibernate-Suche für meine Anwendung zu verwenden. Wir wählen jgroups als Backend. Hier ist meine Konfigurationsdatei.

<?xml version="1.0" encoding="UTF-8"?> 
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:infinispan:config:7.0 
http://www.infinispan.org/schemas/infinispan-config-7.0.xsd 
        urn:infinispan:config:store:jdbc:7.0 http://www.infinispan.org/schemas/infinispan-cachestore-jdbc-config-7.0.xsd" 
xmlns="urn:infinispan:config:7.0" 
xmlns:jdbc="urn:infinispan:config:store:jdbc:7.0"> 

<!-- *************************** --> 
<!-- System-wide global settings --> 
<!-- *************************** --> 
<jgroups> 
    <!-- Note that the JGroups transport uses sensible defaults if no configuration 
     property is defined. See the JGroupsTransport javadocs for more flags. 
     jgroups-udp.xml is the default stack bundled in the Infinispan core jar: integration 
     and tuning are tested by Infinispan. --> 
    <stack-file name="default-jgroups-tcp" path="proform-jgroups.xml" /> 
</jgroups> 

<cache-container name="HibernateSearch" default-cache="default" statistics="false" shutdown-hook="DONT_REGISTER"> 

    <transport stack="default-jgroups-tcp" cluster="venkatcluster"/> 

    <!-- Duplicate domains are allowed so that multiple deployments with default configuration 
     of Hibernate Search applications work - if possible it would be better to use JNDI to share 
     the CacheManager across applications --> 
    <jmx duplicate-domains="true" /> 

    <!-- *************************************** --> 
    <!-- Cache to store Lucene's file metadata --> 
    <!-- *************************************** --> 
    <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000"> 
     <transaction mode="NONE"/> 
     <state-transfer enabled="true" timeout="480000" await-initial-transfer="true" /> 
     <indexing index="NONE" /> 
     <eviction max-entries="-1" strategy="NONE"/> 
     <expiration max-idle="-1"/> 
     <persistence passivation="false"> 
      <jdbc:string-keyed-jdbc-store preload="true" fetch-state="true" read-only="false" purge="false"> 
       <property name="key2StringMapper">org.infinispan.lucene.LuceneKey2StringMapper</property> 
       <jdbc:connection-pool connection-url="jdbc:mysql://localhost:3306/entityindex" driver="com.mysql.jdbc.Driver" password="pf_user1!" username="pf_user"></jdbc:connection-pool> 
       <jdbc:string-keyed-table drop-on-exit="false" create-on-start="true" prefix="ISPN_STRING_TABLE"> 
        <jdbc:id-column name="ID" type="VARCHAR(255)"/> 
        <jdbc:data-column name="DATA" type="BLOB"/> 
        <jdbc:timestamp-column name="TIMESTAMP" type="BIGINT"/> 
       </jdbc:string-keyed-table> 
      </jdbc:string-keyed-jdbc-store> 
     </persistence> 
    </replicated-cache> 

    <!-- **************************** --> 
    <!-- Cache to store Lucene data --> 
    <!-- **************************** --> 
    <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000"> 
     <transaction mode="NONE"/> 
     <state-transfer enabled="true" timeout="480000" await-initial-transfer="true" /> 
     <indexing index="NONE" /> 
     <eviction max-entries="-1" strategy="NONE"/> 
     <expiration max-idle="-1"/> 
     <persistence passivation="false"> 
      <jdbc:string-keyed-jdbc-store preload="true" fetch-state="true" read-only="false" purge="false"> 
       <property name="key2StringMapper">org.infinispan.lucene.LuceneKey2StringMapper</property> 
       <jdbc:connection-pool connection-url="jdbc:mysql://localhost:3306/entityindex" driver="com.mysql.jdbc.Driver" password="pf_user1!" username="pf_user"></jdbc:connection-pool> 
       <jdbc:string-keyed-table drop-on-exit="false" create-on-start="true" prefix="ISPN_STRING_TABLE"> 
        <jdbc:id-column name="ID" type="VARCHAR(255)"/> 
        <jdbc:data-column name="DATA" type="BLOB"/> 
        <jdbc:timestamp-column name="TIMESTAMP" type="BIGINT"/> 
       </jdbc:string-keyed-table> 
      </jdbc:string-keyed-jdbc-store> 
     </persistence> 
    </distributed-cache> 

    <!-- ***************************** --> 
    <!-- Cache to store Lucene locks --> 
    <!-- ***************************** --> 
    <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000"> 
     <transaction mode="NONE"/> 
     <state-transfer enabled="true" timeout="480000" await-initial-transfer="true" /> 
     <indexing index="NONE" /> 
     <eviction max-entries="-1" strategy="NONE"/> 
     <expiration max-idle="-1"/> 
     <persistence passivation="false"> 
      <jdbc:string-keyed-jdbc-store preload="true" fetch-state="true" read-only="false" purge="false"> 
       <property name="key2StringMapper">org.infinispan.lucene.LuceneKey2StringMapper</property> 
       <jdbc:connection-pool connection-url="jdbc:mysql://localhost:3306/entityindex" driver="com.mysql.jdbc.Driver" password="pf_user1!" username="pf_user"></jdbc:connection-pool> 
       <jdbc:string-keyed-table drop-on-exit="false" create-on-start="true" prefix="ISPN_STRING_TABLE"> 
        <jdbc:id-column name="ID" type="VARCHAR(255)"/> 
        <jdbc:data-column name="DATA" type="BLOB"/> 
        <jdbc:timestamp-column name="TIMESTAMP" type="BIGINT"/> 
       </jdbc:string-keyed-table> 
      </jdbc:string-keyed-jdbc-store> 
     </persistence> 
    </replicated-cache> 

</cache-container> 

Das ist mein jgroups-Datei:

<config xmlns="urn:org:jgroups" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="urn:org:jgroups 
    http://www.jgroups.org/schema/JGroups-3.6.xsd"> 
    <TCP bind_addr="${jgroups.tcp.address:127.0.0.1}" 
    bind_port="${jgroups.tcp.port:7801}" 
    enable_diagnostics="false" 
    thread_naming_pattern="pl" 
    send_buf_size="640k" 
    sock_conn_timeout="300" 

    thread_pool.min_threads="${jgroups.thread_pool.min_threads:2}" 
    thread_pool.max_threads="${jgroups.thread_pool.max_threads:30}" 
    thread_pool.keep_alive_time="60000" 
    thread_pool.queue_enabled="false" 
    internal_thread_pool.min_threads= 
    "${jgroups.internal_thread_pool.min_threads:5}" 


    internal_thread_pool.max_threads= 
    "${jgroups.internal_thread_pool.max_threads:20}" 
    internal_thread_pool.keep_alive_time="60000" 
    internal_thread_pool.queue_enabled="true" 
    internal_thread_pool.queue_max_size="500" 

    oob_thread_pool.min_threads="${jgroups.oob_thread_pool.min_threads:20}" 
    oob_thread_pool.max_threads="${jgroups.oob_thread_pool.max_threads:200}" 
    oob_thread_pool.keep_alive_time="60000" 
    oob_thread_pool.queue_enabled="false" 
    /> 
    <S3_PING access_key="" 
     secret_access_key="" 
     location="mybucket" 

/> 
    <MERGE3 min_interval="10000" 
     max_interval="30000" 
    /> 
<FD_SOCK /> 
<FD_ALL timeout="60000" 
     interval="15000" 
     timeout_check_interval="5000" 
/> 
    <VERIFY_SUSPECT timeout="5000" /> 
<pbcast.NAKACK2 use_mcast_xmit="false" 
       xmit_interval="1000" 
       xmit_table_num_rows="50" 
       xmit_table_msgs_per_row="1024" 
       xmit_table_max_compaction_time="30000" 
       max_msg_batch_size="100" 
       resend_last_seqno="true" 
/> 
<UNICAST3 xmit_interval="500" 
     xmit_table_num_rows="50" 
     xmit_table_msgs_per_row="1024" 
     xmit_table_max_compaction_time="30000" 
     max_msg_batch_size="100" 
     conn_expiry_timeout="0" 
/> 
<pbcast.STABLE stability_delay="500" 
       desired_avg_gossip="5000" 
       max_bytes="1M" 
/> 
<pbcast.GMS print_local_addr="false" 
      join_timeout="15000" 
/> 
<MFC max_credits="2m" 
    min_threshold="0.40" 
/> 
<FRAG2 /> 
</config> 

Diese Datei mein Flush-tcp ist: -

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="urn:org:jgroups" 
    xsi:schemaLocation="urn:org:jgroups 
http://www.jgroups.org/schema/jgroups.xsd"> 
<TCP bind_port="7801"/> 
<S3_PING access_key="" 
     secret_access_key="" 
     location="" 

/> 
<MERGE3/> 
<FD_SOCK/> 
<FD/> 
<VERIFY_SUSPECT/> 
<pbcast.NAKACK2 use_mcast_xmit="false"/> 
<UNICAST3/> 
<pbcast.STABLE/> 
<pbcast.GMS/> 
<MFC/> 
<FRAG2/> 
<pbcast.STATE_TRANSFER/> 
<pbcast.FLUSH timeout="0"/> 
</config> 

Dies sind Hibernate Einstellungen:

propertyMap.put("hibernate.search.default.directory_provider", 
"infinispan"); 
propertyMap.put("hibernate.search.lucene_version", 
KeywordUtil.LUCENE_4_10_4); 
propertyMap.put("hibernate.search.infinispan.configuration_resourcename", 
"hibernate-search-infinispan-config.xml"); 
propertyMap.put("hibernate.search.default.​worker.execution","sync"); 
propertyMap.put("hibernate.search.default.​worker.backend","jgroups"); 
propertyMap.put("hibernate.search.services.jgroups.configurationFile", 
"flush-tcp.xml"); 
propertyMap.put("hibernate.search.default.exclusive_index_use","true"); 

Zunächst starten wir den Cluster mit einem Knoten mit der obigen Konfiguration. Abhängig von der Last fügen wir dem Cluster Knoten hinzu. Das ist unsere Architektur. Angenommen, dass wir 10-00 AM den Cluster gestartet haben. Nur der Knoten wird zum Hauptknoten. und alles ist in Ordnung. 10-10 Bin ein weiterer Knoten zum Cluster hinzugefügt mit leichter Konfigurationsänderung. Hier ist die Änderung

propertyMap.put("hibernate.search.default.exclusive_index_use","false"); 

Ich habe einen Index über den zweiten Knoten erstellt. Dann kommt der Sperrfehler auf. Hier ist der Fehler.

Problem: - In der Theorie sollte der zweite Knoten Slave werden und es sollte nie Sperre für den Index erwerben. Es sollte den Master-Knoten angeben, um den Index über den jgroups-Kanal zu erstellen. Aber es passiert nicht. Kann einer von euch mir bitte dabei helfen? Unser Produktionssystem ist in Problem. Bitte helfen Sie mir dabei.

Answer 1

Problem: - In der Theorie sollte zweiten Knoten Slave werden und es sollte nie Sperre auf den Index erwerben. Es sollte den Master-Knoten zu den Index über Jgroups-Kanal erstellen.

Hier können zwei Probleme auftreten.

1. Verwenden Sie unterschiedliche Werte für exclusive_index_use

Vielleicht kann jemand anderes bestätigen, aber es sei denn, Ihr neuer Knoten nur mit einer völlig separaten persistenten Einheit mit ganz anderen Indizes beschäftigt, ich bezweifle, dass es eine gute Idee, einen anderen Wert zu verwenden, für exclusive_index_use auf verschiedenen Knoten.

exclusive_index_use geht es nicht darum, keine Sperren zu erhalten, sondern diese so schnell wie möglich zu veröffentlichen (nach jedem Änderungssatz). Wenn Ihre anderen Knoten im exklusiven Knoten arbeiten, werden sie niemals Sperren freigeben, und Ihr neuer Knoten wartet darauf, dass er auf die Sperre wartet.

Beachten Sie auch, dass die Deaktivierung von exclusive_index_use eine sichere Möglichkeit ist, die Schreibleistung zu verringern, da Index-Writer ständig geschlossen und geöffnet werden müssen. Verwenden Sie mit Vorsicht.

Und schließlich, wie Sie darauf hingewiesen haben, sollte immer nur ein Knoten in den Index schreiben (der JGroups-Master), so dass die Deaktivierung exclusive_index_use in Ihrem Fall nicht erforderlich sein sollte. Es muss ein anderes Problem geben ...

2.Master/Slave-Wahl

Wenn ich mich richtig erinnere, wählen die Standard-Master/Knoten-Wahlstrategie einen neuen Master, wenn Sie einen neuen Knoten hinzufügen. Außerdem haben wir ein paar Fehler im Zusammenhang mit dynamischen Master-Wahlen in der letzten Hibernate-Search-Version (noch nicht veröffentlicht) behoben, so dass Sie möglicherweise von einer dieser Änderungen betroffen sind.

Sie können versuchen, das Backend jgroupsMaster auf Ihrem ersten Knoten und jgroupsSlave auf Ihrem zweiten Knoten zu verwenden. Es wird keine automatische Master-Wahl mehr geben, so dass Sie die Fähigkeit verlieren, den Service beizubehalten, wenn der Master-Knoten ausfällt, aber von dem, was ich verstehe, geht es hauptsächlich um die Skalierung, sodass Sie eine temporäre Lösung erhalten.

Auf dem Master-Knoten:

propertyMap.put("hibernate.search.default.​worker.backend","jgroupsMaster"); 

Auf dem Slave-Knoten:

propertyMap.put("hibernate.search.default.​worker.backend","jgroupsSlave"); 

WARNUNG werden Sie gleich einen vollständigen Neustart benötigen! Wenn Sie das aktuelle jgroups Backend auf Ihrem Master beibehalten, während Sie einen weiteren Knoten mit dem Backend hinzufügen, wird zu Problemen führen!

Möglicherweise müssen Sie auch einige Konfigurationsänderungen in Bezug auf Ihr Infinispan-Verzeichnis vornehmen, aber ich kenne dieses Verzeichnis nicht. Sie können die Dokumentation überprüfen: https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#jgroups-backend