{"_id":"576c339a74a8640e004cedfe","version":{"_id":"56be3388be55991700c3ca10","project":"56be3387be55991700c3ca0d","__v":8,"createdAt":"2016-02-12T19:33:28.313Z","releaseDate":"2016-02-12T19:33:28.313Z","categories":["56be3389be55991700c3ca11","57646709b0a8be1900fcd0d8","5764671c89da831700590782","57646d30c176520e00ea8fe5","5764715d4f867c0e002bc8e3","57698fa2e93bfd190028815c","576c2af16c24681700c902da","5787da96b008c91900aae865"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"56be3389be55991700c3ca11","__v":2,"pages":["56be338abe55991700c3ca13","56be34fa37d84017009de5f7"],"project":"56be3387be55991700c3ca0d","version":"56be3388be55991700c3ca10","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-12T19:33:29.389Z","from_sync":false,"order":2,"slug":"documentation","title":"Documentation"},"parentDoc":null,"user":"5633ec9b35355017003ca3f2","project":"56be3387be55991700c3ca0d","__v":8,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-06-23T19:08:10.301Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"All of our plans, from Chromium and higher, are provisioned using a master-replica data model. The default behavior is to route all requests to the master core, and use Solr's replication mechanism to pull changes into the replica. This behavior is designed to facilitate near real time (NRT) searches and improve availability.\n\nHowever, there are certain use cases in which this default behavior needs to be changed. Websolr offers a mechanism to handle how traffic is routed for your application. We provide a parameter, `X-Websolr-Routing`, which can be included in the header of a request and supports three possible settings: `prefer-master`, `prefer-replica`, `prefer-random`. These options are discussed in detail below. Note that update traffic will always be made to the master index.\n\n\n## prefer-master\n\nThis is the default behavior. A common reason for using this setting would be to use near real time searches and improve availability. Under this behavior, if the master server becomes unavailable, the replica is automatically used instead. The worst case scenario is a loss of up to a minute of writes.\n\n\n## prefer-replica\n\nIn some high-load applications that don't require NRT searches, it makes more sense to distribute the load in such a way that heavy writes don't affect search speed. Update traffic can be routed to the master, while search traffic is routed to the replica and Solr's replication mechanisms pull in fresh updates every minute. The benefit here is that search speed remains relatively consistent, regardless of what sort of volume of writes are occurring at any given time. The downside is that near real time search is not possible; writes will become available after a minute or so.\n\n\n## prefer-random\n\nThis option is a trade off between the other two. Updates are still routed to the master index, but search traffic is randomly distributed between the master and replica. This has the benefit of shifting some load off the master server, while reducing the *average* time before a newly-added document becomes available for search. The downside again is that near real time searches are not possible.\n\n\n# Using these headers\n\nThere are a few ways that these parameters can be used. This section covers some common ways of doing it. If you need something else, please [let us know](mailto:support:::at:::onemorecloud.com).\n\n\n## curl\n\nThe request headers can be included in a curl command like so:\n\n```\n$ curl -H \"X-Websolr-Routing:prefer-replica\" http://index.websolr.com/solr/a1b2c3d4e5/select\n```\n\n\n## Sunspot\n\nYou can include a new initializer `rsolr_with_default_headers.rb` with the following:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"class RSolrWithDefaultHeaders\\n  attr_accessor :default_headers\\n\\n  def initialize(default_headers = {})\\n    self.default_headers = default_headers\\n  end\\n\\n  def connect(opts = {})\\n    RSolr::Client.new(ConnectionWithDefaultHeaders.new(default_headers), opts)\\n  end\\n\\n  class ConnectionWithDefaultHeaders < ::RSolr::Connection\\n    attr_accessor :default_headers\\n\\n    def initialize(default_headers)\\n      self.default_headers = default_headers\\n    end\\n\\n    def setup_raw_request_with_default_headers(request_context={})\\n      setup_raw_request_without_default_headers(request_context).tap do |raw_request|\\n        default_headers.each do |key,val|\\n          raw_request[key] = val\\n        end\\n      end\\n    end\\n    alias_method_chain :setup_raw_request, :default_headers\\n  end\\nend\\n\\nSunspot::Session.connection_class = RSolrWithDefaultHeaders.new({\\n  'X-Websolr-Routing' => 'prefer-replica'\\n})\",\n      \"language\": \"ruby\",\n      \"name\": \"solr_with_default_headers.rb\"\n    }\n  ]\n}\n[/block]","excerpt":"Learn about the headers Websolr provides while interacting with your Solr index.","slug":"routing-headers","type":"basic","title":"Routing headers"}

Routing headers

Learn about the headers Websolr provides while interacting with your Solr index.

All of our plans, from Chromium and higher, are provisioned using a master-replica data model. The default behavior is to route all requests to the master core, and use Solr's replication mechanism to pull changes into the replica. This behavior is designed to facilitate near real time (NRT) searches and improve availability. However, there are certain use cases in which this default behavior needs to be changed. Websolr offers a mechanism to handle how traffic is routed for your application. We provide a parameter, `X-Websolr-Routing`, which can be included in the header of a request and supports three possible settings: `prefer-master`, `prefer-replica`, `prefer-random`. These options are discussed in detail below. Note that update traffic will always be made to the master index. ## prefer-master This is the default behavior. A common reason for using this setting would be to use near real time searches and improve availability. Under this behavior, if the master server becomes unavailable, the replica is automatically used instead. The worst case scenario is a loss of up to a minute of writes. ## prefer-replica In some high-load applications that don't require NRT searches, it makes more sense to distribute the load in such a way that heavy writes don't affect search speed. Update traffic can be routed to the master, while search traffic is routed to the replica and Solr's replication mechanisms pull in fresh updates every minute. The benefit here is that search speed remains relatively consistent, regardless of what sort of volume of writes are occurring at any given time. The downside is that near real time search is not possible; writes will become available after a minute or so. ## prefer-random This option is a trade off between the other two. Updates are still routed to the master index, but search traffic is randomly distributed between the master and replica. This has the benefit of shifting some load off the master server, while reducing the *average* time before a newly-added document becomes available for search. The downside again is that near real time searches are not possible. # Using these headers There are a few ways that these parameters can be used. This section covers some common ways of doing it. If you need something else, please [let us know](mailto:support@onemorecloud.com). ## curl The request headers can be included in a curl command like so: ``` $ curl -H "X-Websolr-Routing:prefer-replica" http://index.websolr.com/solr/a1b2c3d4e5/select ``` ## Sunspot You can include a new initializer `rsolr_with_default_headers.rb` with the following: [block:code] { "codes": [ { "code": "class RSolrWithDefaultHeaders\n attr_accessor :default_headers\n\n def initialize(default_headers = {})\n self.default_headers = default_headers\n end\n\n def connect(opts = {})\n RSolr::Client.new(ConnectionWithDefaultHeaders.new(default_headers), opts)\n end\n\n class ConnectionWithDefaultHeaders < ::RSolr::Connection\n attr_accessor :default_headers\n\n def initialize(default_headers)\n self.default_headers = default_headers\n end\n\n def setup_raw_request_with_default_headers(request_context={})\n setup_raw_request_without_default_headers(request_context).tap do |raw_request|\n default_headers.each do |key,val|\n raw_request[key] = val\n end\n end\n end\n alias_method_chain :setup_raw_request, :default_headers\n end\nend\n\nSunspot::Session.connection_class = RSolrWithDefaultHeaders.new({\n 'X-Websolr-Routing' => 'prefer-replica'\n})", "language": "ruby", "name": "solr_with_default_headers.rb" } ] } [/block]