Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C7F6811126 for ; Tue, 9 Sep 2014 03:55:11 +0000 (UTC) Received: (qmail 21745 invoked by uid 500); 9 Sep 2014 03:55:06 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 21662 invoked by uid 500); 9 Sep 2014 03:55:06 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 21637 invoked by uid 99); 9 Sep 2014 03:55:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Sep 2014 03:55:05 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 209.85.223.182 is neither permitted nor denied by domain of salman.akram@northbaysolutions.net) Received: from [209.85.223.182] (HELO mail-ie0-f182.google.com) (209.85.223.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Sep 2014 03:54:39 +0000 Received: by mail-ie0-f182.google.com with SMTP id tr6so2512522ieb.13 for ; Mon, 08 Sep 2014 20:54:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=JT2AXNSNXjfprteoBQo3YFf0j5UIiYg94zQ6NcL/Uzs=; b=OGZdFDdFCSRGx3QGcFn0PalMkEbVDVI2Kcd1AadpEOK6ZTHS5RkTNp+QPqjori2Wot r5pVDrGuX2TS1GAtsRHQ+PJDBRsOIdO16YvS2rM8AAS/tmJHGFeLXsu2DT2hBZF/qYTN +KJWdfZ69V95nyQmT53yhEHAMG+w8UElmubCvbhCXhCi0fC69jg845hUPVsoo3x9a/hj k549m+Hx3z9n9NRHQsiFgPd/8Uj5xSKrWNzF+/TQpxKwXKStYjuKZv/Wq9aunccqBK1r wG8aoqVevrwLu/ew5J/Q99jWFi7Zrol9adXGjY6OvG/pXKMAtc3tAjT8npxh+b7NGcq/ F47A== X-Gm-Message-State: ALoCoQmTPViBVu2PHIdA0PEDswk4bvd4iqo4DITnEgST+0AN8vsB8B5H2GiM48Y3rZjRZ/hnLAII X-Received: by 10.50.122.99 with SMTP id lr3mr28229450igb.10.1410234877616; Mon, 08 Sep 2014 20:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.194 with HTTP; Mon, 8 Sep 2014 20:54:17 -0700 (PDT) From: Salman Akram Date: Tue, 9 Sep 2014 08:54:17 +0500 Message-ID: Subject: Master - Master / Upgrading a slave to master To: Solr Group Content-Type: multipart/alternative; boundary=089e0153835aee2be5050299e4c5 X-Virus-Checked: Checked by ClamAV on apache.org --089e0153835aee2be5050299e4c5 Content-Type: text/plain; charset=UTF-8 We have a redundant data center in case the primary goes down. Currently we have 1 master and multiple slaves on primary data center. This master also replicates to a slave in secondary data center. So if the primary goes down at least the read only part works. However, now we want writes to work on secondary data center too when primary goes down. - Is it possible in SOLR to have Master - Master? - If not then what's the best strategy to upgrade a slave to master? - Naturally there would be some latency due to data centers being in different geographical locations so what are the normal data issues and best practices in case primary goes down? We would also like to shift back to primary as soon as its back. Thanks! -- Regards, Salman Akram --089e0153835aee2be5050299e4c5--