You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Kenji Kikuchi (JIRA)" <ji...@apache.org> on 2014/09/24 11:37:34 UTC
[jira] [Created] (SOLR-6557) bandwidth cap for large file
replication
Kenji Kikuchi created SOLR-6557:
-----------------------------------
Summary: bandwidth cap for large file replication
Key: SOLR-6557
URL: https://issues.apache.org/jira/browse/SOLR-6557
Project: Solr
Issue Type: Improvement
Components: replication (java)
Affects Versions: 5.0, Trunk
Reporter: Kenji Kikuchi
Priority: Minor
Fix For: 5.0, Trunk
Sometimes I need to set up a slave server in the rack where a master
server does not exist. In this case, our rack to rack bandwidth is often
saturated during large file transfer, such as initial replication, large
index file merge and optimization. This impairs our other services. So I
think a bandwidth cap for large file replication is helpful for large web service providers and adds flexibility to our Solr slave server setups.
Currently I am limiting replication bandwidth by using a tc command on
the master servers. But to use a tc command, I need to login to an
on-service master server and add tc related settings to add a new slave
server because tc command only shapes outbound traffics. So the feature
of setting up a desired replication bandwidth cap with just one line in
a new slave configuration file reduces our Solr operations and secures
the on-service master servers by avoiding the need to login.
Parsing bandwidth setting in slave solrconfig.xml in ‘bits per
second' is preferable for me. This is because most of our site operators
use ‘bits per second' not ‘bytes per second’ in our network monitoring
metrics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org