<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>replication &#8211; Solr.pl</title>
	<atom:link href="https://solr.pl/en/tag/replication/feed/" rel="self" type="application/rss+xml" />
	<link>https://solr.pl/en/</link>
	<description>All things to be found - Blog related to Apache Solr &#38; Lucene projects - https://solr.apache.org</description>
	<lastBuildDate>Sat, 14 Nov 2020 13:50:22 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>Solr 5: replication throttling</title>
		<link>https://solr.pl/en/2015/01/26/solr-5-replication-throttling/</link>
					<comments>https://solr.pl/en/2015/01/26/solr-5-replication-throttling/#respond</comments>
		
		<dc:creator><![CDATA[Rafał Kuć]]></dc:creator>
		<pubDate>Mon, 26 Jan 2015 13:49:49 +0000</pubDate>
				<category><![CDATA[Solr]]></category>
		<category><![CDATA[5]]></category>
		<category><![CDATA[5.0]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[solr]]></category>
		<category><![CDATA[throttling]]></category>
		<guid isPermaLink="false">http://sematext.solr.pl/?p=853</guid>

					<description><![CDATA[In case our collection is very large (or there are a few of them) in a case when full replication is needed, Solr can use all the bandwidth of our network (if the disks are fast enough). This is good]]></description>
										<content:encoded><![CDATA[<p>In case our collection is very large (or there are a few of them) in a case when full replication is needed, Solr can use all the bandwidth of our network (if the disks are fast enough). This is good in some situations, but bad in others. Imagine that you have some collections being queried and of them starts to replicate a tens of gigabytes of data &#8211; all the other collections would suffer. Thankfully with the release of Solr 5 we got replication throttling and we can use it to limit the amount of data allowed to be transferred by Solr.</p>
<p><span id="more-853"></span></p>
<p>To show you how replication throttling works we will compare two use cases &#8211; one will copy 2GB index without any limits and the other will copy the same index, but with throttling enabled. To illustrate that we will use SolrCloud deployment, with very simple configuration. Please note, that replication throttling is not limited to SolrCloud deployments and can be used successfully in old master &#8211; slave architecture.</p>
<h3>Replication without throttling</h3>
<p>To show you how network bandwidth has been used we will use the following, standard replication handler configuration:
</p>
<pre class="brush:xml">&lt;requestHandler name="/replication" class="solr.ReplicationHandler"&gt;
&lt;/requestHandler&gt;
</pre>
<p>Network usage in that case looked as follows:</p>
<p><a href="http://solr.pl/wp-content/uploads/2015/01/replication_not_throttled.png"><img fetchpriority="high" decoding="async" class="aligncenter wp-image-3537 size-full" src="http://solr.pl/wp-content/uploads/2015/01/replication_not_throttled.png" alt="replication_not_throttled" width="552" height="192"></a></p>
<h3>Replication with throttling enabled</h3>
<p>Now let&#8217;s compare it to replication that is setup to use throttling:
</p>
<pre class="brush:xml">&lt;requestHandler name="/replication" class="solr.ReplicationHandler"&gt;
 &lt;lst name="defaults"&gt;
  &lt;str name="maxWriteMBPerSec"&gt;0.1&lt;/str&gt;
 &lt;/lst&gt;
&lt;/requestHandler&gt;
</pre>
<p>Network usage in this case looks as follows:</p>
<p><a href="http://solr.pl/wp-content/uploads/2015/01/replication_throttled.png"><img decoding="async" class="aligncenter wp-image-3532 size-large" src="http://solr.pl/wp-content/uploads/2015/01/replication_throttled-1024x347.png" alt="replication_throttled" width="512" height="173"></a>As we can see the difference is large and throttling works as intended <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f642.png" alt="🙂" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
<h3>Short summary</h3>
<p>As we can see the configuration itself is very simple and it just works. Again, it does work in master &#8211; slave and in SolrCloud deployments, so no matter which way you go, you can use replication throttling. The only thing that is missing now, at least for me, is dedicated API that I could use to change the replication configuration without core reload. Maybe in the future? <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f609.png" alt="😉" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
]]></content:encoded>
					
					<wfw:commentRss>https://solr.pl/en/2015/01/26/solr-5-replication-throttling/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Backing Up Your Index</title>
		<link>https://solr.pl/en/2012/08/13/backing-up-your-index/</link>
					<comments>https://solr.pl/en/2012/08/13/backing-up-your-index/#respond</comments>
		
		<dc:creator><![CDATA[Rafał Kuć]]></dc:creator>
		<pubDate>Mon, 13 Aug 2012 21:51:12 +0000</pubDate>
				<category><![CDATA[Solr]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[handler]]></category>
		<category><![CDATA[index]]></category>
		<category><![CDATA[replication]]></category>
		<guid isPermaLink="false">http://sematext.solr.pl/?p=472</guid>

					<description><![CDATA[Did you ever wonder if you can create a backup of your index with the tools available in Solr ? For exmaple after every commit or optimize operation ? Or may you would like to create backups with the HTTP]]></description>
										<content:encoded><![CDATA[<p>Did you ever wonder if you can create a backup of your index with the tools available in Solr ? For exmaple after every <em>commit</em> or <em>optimize</em> operation ? Or may you would like to create backups with the HTTP API call ? Lets see what possibilities Solr has to offer.</p>
<p><span id="more-472"></span></p>
<h3>The Beginning</h3>
<p>We decided to write about index backups even though this functionality is fairly simple. We noticed that many people tend to forget about this functionality, not only when it comes to Apache Solr. We hope that this blog entry, will help you remember about backup creation functionality, when you need it. But now, lets start from the beginning &#8211; before we started the tests, we looked at the directory where Solr keeps its indices and this is what we saw:
</p>
<pre class="brush:bash">drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:17 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker</pre>
<h3>Manual Backup</h3>
<p>In order to create a backup of your index with the use of HTTP API you have to have replication handler configured. If you have it, then you need to send the <em>command</em> parameter with <em>backup</em> value to the master server replication handler, for example like this:
</p>
<pre class="brush:xml">curl 'http://localhost:8983/solr/replication?command=backup'</pre>
<p>The above will tell Solr to create a new backup of the current index. Lets now look how the directory where indices live looks like after running the above command:
</p>
<pre class="brush:bash">drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:18 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:19 snapshot.20120812201917
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker</pre>
<p>As you can see, there is a new directory created &#8211; <em>snapshot.20120812201917</em>. We can assume, that we got what we wanted <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f642.png" alt="🙂" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
<h3>Automatic Backup</h3>
<p>In addition to manual backup creation, you can also configure Solr to create indices after <em>commit</em> or <em>optimize</em> operation. Please remember though, that if your index is changing rapidly it is usually a bad idea to create backup after each&nbsp;commit operation.&nbsp; But lets get back to automatic backups. In order to configure Solr to create backups for us, you need to add the following line to replication handler configuration:
</p>
<pre class="brush:xml">&lt;str name="backupAfter"&gt;commit&lt;/str&gt;</pre>
<p>So, the full replication handler configuration (on the <em>master</em> server) would look like this:
</p>
<pre class="brush:xml">&lt;requestHandler name="/replication" &gt;
 &lt;lst name="master"&gt;
  &lt;str name="replicateAfter"&gt;commit&lt;/str&gt;
  &lt;str name="replicateAfter"&gt;startup&lt;/str&gt;
  &lt;str name="confFiles"&gt;schema.xml,stopwords.txt&lt;/str&gt;
  &lt;str name="backupAfter"&gt;commit&lt;/str&gt;
 &lt;/lst&gt;
&lt;/requestHandler&gt;</pre>
<p>After sending two <em>commit</em> operation our dictionary with indices looks like this:
</p>
<pre class="brush:bash">drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 index
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 snapshot.20120812211203
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 21:12 snapshot.20120812211216
drwxrwxr-x 2 gr0 gr0 4096 2012-08-12 20:16 spellchecker</pre>
<p>As you can see, Solr did what we wanted to be done.</p>
<h3>Keeping Order</h3>
<p>It is possible to control the maximum amount of backups that should be stored on disk. In order to configure that number you need to add the following line to your replication handler configuration:
</p>
<pre class="brush:xml">&lt;str name="maxNumberOfBackups"&gt;10&lt;/str&gt;</pre>
<p>The above configuration value tells Solr to keep maximum of ten backups of your index. Of course you can delete created backups (manually for example) if you don&#8217;t need them anymore.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://solr.pl/en/2012/08/13/backing-up-your-index/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
