SolrのクラスタReplicationの構成と実践

11847 ワード
Solr Lucene 全文検索
Solrは検索サーバとして、同時に検索要求を行う場合、1台のサーバが簡単に崩壊する可能性があります.これはクラスタ技術を使用して、複数のSolr検索サーバを設置し、同時に対外的に検索サービスを提供し、フロントエンドでNginxのような負のロードバランスソフトウェアを使用することができます.同時に到着した検索要求をSolrクラスタ内の各サーバに均一に逆エージェントするように構成することで、各Solr検索サーバの検索要求の圧力を大幅に低減し、各サーバがサーバを継続的に提供できる能力を向上させることができる.
しかし、このとき私たちが直面している問題は、クラスタ内の各サーバがオンラインでインデックスデータをよく同期させることを保証し、各検索サーバのインデックスデータが一定の程度で一貫性を保つことです.クラスタ内のあるサーバはダウンタイムでオフラインになり、手動で再起動した後もクラスタ内の他のサーバインデックスデータと一致し続け、検索サービスを提供し続ける.クラスタ内のあるサーバのインデックスデータは、ハードディスクの故障や人為的な原因で検索サービスを提供できないため、データ復旧メカニズムが必要である.クラスタ内で最初にデータ更新を受けたMasterサーバは、インデックス更新をSlaveサーバに伝播する際に、複数のSlaveサーバが同じ時間に大量のネットワーク帯域幅を占有することを回避し、Masterの検索サービス提供に影響を及ぼす.
実際、Solrフレームワークは上記のいくつかの面で優れたサポートを行い、柔軟性があります.上記のいくつかの問題に基づいて,SolrクラスタのReplicationを構成し,クラスタレプリケーションの機能を実践する.
スタンドアロンインスタンスReplication
Solrは、単一マシン上で複数のインスタンス(MultiCore)を構成することをサポートし、各インスタンスは独立して外部にサービスを提供し、同じネットワーク帯域幅を共有することができる.また、単一マシンインスタンス間のReplicationを実現し、インスタンス間でデータをコピーし、データの可用性を保証し、システムのサービス能力を向上させることができる.
Solrの複数のインスタンスを起動し、これらのインスタンスを(Coreによって区別される)単一マシン上の擬似分散クラスタとして、これらのCoreインスタンスは同じJVMに存在する.いずれかのインスタンスCore 0をMasterとして選択し、インデックス更新のたびに、MasterインスタンスCore 0がSlaveインスタンスCore 1、Core 2、Core 3上のデータと同期するまで、まずこのインスタンスCore 0から伝播する.ここで、各インスタンスは独立して外部に提供することができるこのモードは、複数のインスタンス上のデータが同じデータであることを保証するため、データバックアップの役割を果たすため、通常、複数のインスタンスに同時にサービスを提供することは推奨されません.上図のコピーモードでのSolrの構成を示します.
Core 0はMasterとして対応するsolconfig.xmlの構成内容は、次のとおりです.
<?xml version="1.0" encoding="UTF-8" ?>  
<config>  
    <luceneMatchVersion>LUCENE_35</luceneMatchVersion>  
    <directoryFactory name="DirectoryFactory" class="${solr.directoryFactory:solr.StandardDirectoryFactory}" />  
 
    <updateHandler class="solr.DirectUpdateHandler2" />  
 
    <requestDispatcher handleSelect="true">  
        <requestParsers enableRemoteStreaming="false" multipartUploadLimitInKB="2048" />  
    </requestDispatcher>  
 
    <requestHandler name="standard" class="solr.StandardRequestHandler" default="true" />  
    <requestHandler name="/update" class="solr.JsonUpdateRequestHandler" />  
    <requestHandler name="/admin/" class="org.apache.solr.handler.admin.AdminHandlers" />  
 
    <queryParser name="dismax" class="solr.DisMaxQParserPlugin" />  
    <requestHandler name="/dismax" class="solr.SearchHandler">  
        <lst name="defaults">  
            <str name="defType">dismax</str>  
            <str name="qf">title content</str>  
            <bool name="hl">true</bool>  
            <str name="hl.fl">title content</str>  
            <int name="hl.fragsize">200</int>  
            <int name="hl.snippets">1</int>  
            <str name="fl">*,score</str>  
            <str name="qt">standard</str>  
            <str name="wt">standard</str>  
            <str name="version">2.2</str>  
            <str name="echoParams">explicit</str>  
            <str name="indent">true</str>  
            <str name="debugQuery">on</str>  
            <str name="explainOther">on</str>  
        </lst>  
    </requestHandler>  
 
    <requestHandler name="/replication" class="solr.ReplicationHandler">  
        <lst name="master">  
            <str name="replicateAfter">startup</str>  
            <str name="replicateAfter">commit</str>  
            <str name="commitReserveDuration">00:00:10</str>  
        </lst>  
    </requestHandler>  
 
    <admin>  
        <defaultQuery>solr</defaultQuery>  
    </admin>  
 
</config>

上記構成では、/dismax検索インタフェースが提供され、対外的に検索サービスが提供される.構成のnameは/ReplicationのrequestHandler、すなわちSolrに提供されるレプリケーション要求処理インタフェースであり、構成のreplicateAfterはstartupとcommitの後にSlaveのレプリケーション要求を許可することを示す.
SolrはインデックスデータReplicationをサポートし、構成データのコピーもサポートします.構成データをコピーして構成バックアップを行う必要がある場合は、Masterのsolconfig.xmlでは、次のように構成されています.
schema.xml,stopwords.txt,solrconfig.xml,synonyms.txt
マスターからコピーするプロファイル名を指定します.
Core 1~Core 3はいずれもSlave、すなわちレプリケーションデータを要求する場合、Core 1を例にとると、他の構成は同じであるが、Slaveインスタンスが外部にサービスを提供することを望まないため、Slaveの/replicationレプリケーション要求処理インタフェースを構成するだけでよい.構成内容は以下の通りである.
<?xml version="1.0" encoding="UTF-8" ?>  
<config>  
    <luceneMatchVersion>LUCENE_35</luceneMatchVersion>  
    <directoryFactory name="DirectoryFactory" class="${solr.directoryFactory:solr.StandardDirectoryFactory}" />  
 
    <updateHandler class="solr.DirectUpdateHandler2" />  
 
    <requestDispatcher handleSelect="true">  
        <requestParsers enableRemoteStreaming="false" multipartUploadLimitInKB="2048" />  
    </requestDispatcher>  
 
    <requestHandler name="standard" class="solr.StandardRequestHandler" default="true" />  
    <requestHandler name="/update" class="solr.JsonUpdateRequestHandler" />  
    <requestHandler name="/admin/" class="org.apache.solr.handler.admin.AdminHandlers" />  
 
    <requestHandler name="/replication" class="solr.ReplicationHandler">  
        <lst name="slave">  
            <str name="masterUrl">http://192.168.0.195:8080/solr35/core0/replication</str>  
            <str name="pollInterval">00:00:20</str>  
            <str name="compression">internal</str>  
            <str name="httpConnTimeout">5000</str>  
            <str name="httpReadTimeout">10000</str>  
            <str name="httpBasicAuthUser">username</str>  
            <str name="httpBasicAuthPassword">password</str>  
        </lst>  
    </requestHandler>  
 
    <admin>  
        <defaultQuery>solr</defaultQuery>  
    </admin>  
 
</config>

Slave構成ではmasterUrlとpollIntervalが必須であり、masterUrlはcore 0のレプリケーション要求インタフェースとして指定され、pollIntervalはSlaveが周期的にMasterにデータが更新されたかどうかを問い合わせ、変更が発生した場合にレプリケーションを行うことを意味する.その他のパラメータは必要に応じて構成できます.一般に、単一マシンの複数のインスタンス間のReplicationは、上記httpBasicAuth*のパラメータを構成する必要はありません.
Solrを起動するまでインデックスデータはありません.起動後、http://blog.csdn.net/shirdrn/article/details/7054633の中で設計した小道具は、Masterにデータ要求インデックスを送信し、postの過程でcommitとoptimize操作が実行されたため、SlaveがMasterのインデックスデータをコピーすることをトリガーし、ログを見ることができます.
MasterとSlaveデータが同期している場合、MasterはSlaveのReplication要求を受信する.
2011-12-9 15:18:00 org.apache.solr.core.SolrCore execute
  : [core0] webapp=/solr35 path=/replication params={command=indexversion&wt=javabin} status=0 QTime=0
2011-12-9 15:18:20 org.apache.solr.core.SolrCore execute
  : [core0] webapp=/solr35 path=/replication params={command=indexversion&wt=javabin} status=0 QTime=0
2011-12-9 15:18:40 org.apache.solr.core.SolrCore execute
  : [core0] webapp=/solr35 path=/replication params={command=indexversion&wt=javabin} status=0 QTime=0
2011-12-9 15:19:00 org.apache.solr.core.SolrCore execute
  : [core0] webapp=/solr35 path=/replication params={command=indexversion&wt=javabin} status=0 QTime=0

20 s間隔ごとに、Slaveは1回要求し、この間隔は必要に応じて構成することができる.私たちがMasterにインデックスデータ更新インデックス要求を送信した後、MasterとSlaveの間で実行したデータのコピーから、処理ログの内容は後述の付録の内容を参照することができる.ログ情報を見ると、SlaveはMasterでインデックスを更新する(addにより5件の文書が更新され、ログには文書番号が与えられている.更新時には、2件の文書を送信するたびにcommitが1回実行され、すべての送信が完了した後にcommitとoptimize操作が1回実行される)後、要求を送信することによってコピーファイルのリストが取得され、その後コピープロセスが実行され、最後にSlaveインデックスデータが変化し、リアルタイムで最新の検索が可能になるを選択して、IndexSearcherインスタンスを再度開きます.ログの一番後ろの部分では、SlaveのインデックスデータはMasterと同期しており、コピーする必要はありません.
クラスタノードReplication
Solrクラスタでの構成は、上記のシングルマシンマルチインスタンスの場合とほぼ一致しています.基本的な特徴は、各ノードのインスタンス(Core)が同じJVM内で、異なるノード間でコピーされることです.実際には、異なるノードのインスタンス間でReplicationが行われることです.クラスタコピーパターンアーキテクチャ図は、次のように示されています.
1つのSolrクラスタでReplicationを実行し、レプリケーション要求とアクションがネットワーク内で発生します.一方、replicationのエンドポイントは異なるノード上のインスタンス(Core)であり、Slaveノード上の他のインスタンスが他のサービスを提供している可能性が高い.上図から分かるように、1つのMasterのみのSolrクラスタにおいて、大量のSlave要求Replicationが存在する場合、Masterサーバに対する圧力は必ず生じる(ネットワーク帯域幅、システムIO、システムCPU).外部からの大量の検索要求により、Masterがサービスを継続的に提供する能力が低下したり、ダウンタイムになったりする可能性が高い.Solrもこの点を考慮して、MasterとSlaveの間にエージェントのノードを確立することで、単一の障害を改善し、エージェントノードはMasterのSlaveを行い、Masterのデータを同期し、同時にSlaveのMasterを行う.最新のデータをSlaveノードに同期してコピーします.このノードはRepeaterと呼ばれ、アーキテクチャ図は次のようになります.
図から分かるように、Masterの圧力は一気にRepeaterノードに移行し、Masterの単点問題をある程度解決した.Reaperノードについては、二重の役割を果たしており、構成時にMasterとSlaveの両方が持つ属性を構成する必要があることは明らかです.Repeaterの構成例を示します.Master構成:
<requestHandler name="/replication" class="solr.ReplicationHandler">  
        <lst name="master">  
                <str name="replicateAfter">startup</str>  
                <str name="replicateAfter">commit</str>  
                <str name="confFiles">schema.xml,stopwords.txt,solrconfig.xml,synonyms.txt</str>  
                <str name="commitReserveDuration">00:00:10</str>  
        </lst>  
</requestHandler>

Solrは、このチェーンReplication構成をサポートし、さらにマルチレベルを構成することもできますが、具体的にどのように構成するかは、アプリケーションの特徴やリソース条件の制限に基づいています.要するに、Solr Replicationの目標は、システムのデータ可用性を向上させることです.マシン障害、ハードディスク(HDD)障害、データエラーが発生した場合は、他のバックアップからデータを同期できます.
Repeater構成:
<requestHandler name="/replication" class="solr.ReplicationHandler">  
        <lst name="master">  
                <str name="replicateAfter">startup</str>  
                <str name="replicateAfter">commit</str>  
                <str name="commitReserveDuration">00:00:10</str>  
        </lst>  
        <lst name="slave">  
                <str name="masterUrl">http://192.168.0.184:8080/masterapp/master/replication</str>  
                <str name="pollInterval">00:00:20</str>  
                <str name="compression">internal</str>  
                <str name="httpConnTimeout">5000</str>  
                <str name="httpReadTimeout">10000</str>  
                <str name="httpBasicAuthUser">username</str>  
                <str name="httpBasicAuthPassword">password</str>  
        </lst>  
</requestHandler>

Slave構成:
<requestHandler name="/replication" class="solr.ReplicationHandler" >  
   <lst name="slave">  
       <str name="masterUrl">http://192.168.0.174:8080/repeaterapp/repeater/replication</str>  
       <str name="pollInterval">00:00:20</str>  
       <str name="compression">internal</str>  
       <str name="httpConnTimeout">5000</str>  
       <str name="httpReadTimeout">10000</str>  
        <str name="httpBasicAuthUser">username</str>  
        <str name="httpBasicAuthPassword">password</str>  
     </lst>  
</requestHandler>
に移動:http://www.chepoo.com/solr-cluster-replication-configuration-and-practice.html
goroutineを使って高速TCP ポートスキャン
Java開発における文字化けし