Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b3ZbD-0000Yi-H5 for pgsql-admin@arkaria.postgresql.org; Fri, 20 May 2016 01:51:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b3ZbC-000082-EO for pgsql-admin@arkaria.postgresql.org; Fri, 20 May 2016 01:51:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b3ZbA-00007e-Ko for pgsql-admin@postgresql.org; Fri, 20 May 2016 01:51:32 +0000 Received: from mail-pf0-x22e.google.com ([2607:f8b0:400e:c00::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1b3Zb0-00069d-Td for pgsql-admin@postgresql.org; Fri, 20 May 2016 01:51:31 +0000 Received: by mail-pf0-x22e.google.com with SMTP id c189so36954647pfb.3 for ; Thu, 19 May 2016 18:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=1ccyPjw/cxGn7ktjmhzXRHyuZVFYdFsbuDoNMIAGdEM=; b=UfQM1bjjTFj6Tu0bcSFWoQqZwA3NvFH8HZBOHEegZxhFplNwOezg6j4fGy0+hLihke JIFotqP7Zn7glKyeByevmR3a6EQhseAjnbNwhlM96UuXUGAHQ5Krf35UUxePZvJk8J70 ONfgPSPr4iVoo1P36g85BeAqUv35gSVaAO5tB0enL6LcVm+DdGGWGDKmxKbpnCCEmLJe a/nsB6nZYHH6WisgjOW/zjblc1R2wARcyPld1/enEJkZvY5pMliKcFA4UPeLhoOIz0nc bO5NQmuv48Oo1MNuQCjxtAQcGXSkZekCvhKXLaQ/bGDQp85ZSSQIbm6zQ7WvyCllKVJ7 qj3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1ccyPjw/cxGn7ktjmhzXRHyuZVFYdFsbuDoNMIAGdEM=; b=I1zALRKxLAOl7ExT5MlyDfMO6Khtg3+PqrERfOxijPoF5QVTC+f7aEsajN50QooKaJ uVXt/MKr/mmvqpXmkOcbIa2lgY8Wq0vhOTqYI/cOo++5tAiKmzBpsViYz8xILcRLmHbt aC/zVsUECYOx4AUTAelqQjzEzw1IfWqhCSqhj9mc8EiSkpRy0tcj1vpre1RF2+Y8qaaN p7Fomkn0HclJwwkl7DhS+qmqyI/b1h9qGhtxNFbOd3x5vtMf4l8LrRoBVNku9W0+q54L jptxiFmGTt/E1JIS6OKaMQjUTW8XzzH6reaVxup6lCP7SzJTuDAr11BxE971uu8+EyJU WXFQ== X-Gm-Message-State: AOPr4FXr2jhZWakxye5dngLPY1YABS6HJTmHsBv1inHqpBEzqbd02+gCVbaakCw74NuQcFSPz0VNn3DapwN2jtRIPleGztI7thLT2eoyAdjDFan0lgf5N0jksKF4N6dxpwb+F3VMzKezG/qTQ98kL5dLrh0PWdMBVYPayfoJSXxg9Ym53X5EGh7WZ8P/Jw== X-Received: by 10.98.104.6 with SMTP id d6mr709150pfc.77.1463709080346; Thu, 19 May 2016 18:51:20 -0700 (PDT) Received: from [192.168.1.2] (p7231-ipngn6601marunouchi.tokyo.ocn.ne.jp. [153.163.110.231]) by smtp.gmail.com with ESMTPSA id u63sm22676553pfu.18.2016.05.19.18.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 May 2016 18:51:19 -0700 (PDT) Subject: Re: read-only remote replica To: Jon Hancock , pgsql-admin@postgresql.org References: From: Ian Barwick Message-ID: <573E6D95.5010007@2ndquadrant.com> Date: Fri, 20 May 2016 10:51:17 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org On 05/20/2016 08:11 AM, Jon Hancock wrote: > Hi list, > I need a read only replica of my postgres server (assume > current/recent stable release). > The master is in a reliable data center in California. The read-only > replica would be in an office in New Zealand. Bandwidth can be > challenging from our office. It works but bandwidth is highly > variable. > > The reason for the read-only replica is we have an old reports system > in our office that connects directly to the db via ODBC. Simply too > much work to replace this system for now. Its not an option to do > nightly dumps/download/imports as we need closer to real time replica. > A few minutes delay is ok. > > Any thoughts would be appreciated on how to have a stable/reliable method. In a previous job I worked with servers running Postgres in different locations, including New Zealand (have they upgraded the modem used to connect to the rest of the world yet? ;) ) - if you can live with occasional lag, streaming replication works pretty well. However it does of course depend on how much data you'll be receiving - any idea how many WAL files your master generates in a given period? One issue to look out for with intercontinental connections is occasional problems with routing, some router goes down between you and the data centre and there's nothing you can do but wait until it's fixed and the route gets updated. To work around that you could set up WAL archiving using something like Barman [*] which ships WAL to a different datacentre and set up your replica to pull files from there if streaming replication is not available. [*] http://www.pgbarman.org/ Regards Ian Barwick -- Ian Barwick http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin