Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VxKsi-0004QR-GC for pgsql-general@arkaria.postgresql.org; Sun, 29 Dec 2013 18:14:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VxKsh-0004DN-UO for pgsql-general@arkaria.postgresql.org; Sun, 29 Dec 2013 18:14:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VxKsg-0004DE-Fc for pgsql-general@postgresql.org; Sun, 29 Dec 2013 18:14:30 +0000 Received: from mail-qe0-f50.google.com ([209.85.128.50]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VxKsd-00030K-Dl for pgsql-general@postgresql.org; Sun, 29 Dec 2013 18:14:29 +0000 Received: by mail-qe0-f50.google.com with SMTP id 1so10644326qec.37 for ; Sun, 29 Dec 2013 10:14:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XOB3PZl9XtrkpC9Q2KebGbNUTWa7GBT6Z5A5QBxlCR8=; b=B+GA+g3c7Eug0qPzEnnklnKFdwCbAbRlY1wgW2EldE3/P9JiIkj9QortIRv2bmzKXT xzeDDiCVncrkxgBCVNX9Gdnm+/7Ird0iKYvvzQne4G+1SsFU56Aza3eGU2nOGKqzAkhu 9Xdh1WRBldSvkvMQ4htcXopSczMl27/0S4Vbbb8w+c3jJ8kdvoMocVyCMzQLLHUTrmoU zPE/LhwIYsTe/6D6kWLhusdGx0qzAGw+UV866ZWAYkkn3o0KjOkaACbo1p2GTTfrWRhz 2r/oekWY3HJLb+eHXyAHE7UDHljbziXUJ1tTxf8KCRK6eqQ/VayzRTX1FmqI4nm9kysE OXpA== X-Gm-Message-State: ALoCoQkrypd5r/W2UgoDy5/BdWH4BMfor5kQkGiW2ni678lP0bKYxamm3xyauth2Iqtv6SxKabwP X-Received: by 10.224.161.75 with SMTP id q11mr21971251qax.69.1388340864896; Sun, 29 Dec 2013 10:14:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.191.134 with HTTP; Sun, 29 Dec 2013 10:13:44 -0800 (PST) X-Originating-IP: [124.197.103.118] In-Reply-To: <20131229120846.ecedab9bc2a61b937871c170@potentialtech.com> References: <52A5EB31.7070505@nybeta.com> <20131210063742.86b78bf34f9fbb968454fed3@potentialtech.com> <20131229081927.ee3d1638e65f0f8e1d35b509@potentialtech.com> <20131229120846.ecedab9bc2a61b937871c170@potentialtech.com> From: Sameer Kumar Date: Mon, 30 Dec 2013 02:13:44 +0800 Message-ID: Subject: Re: PG replication across DataCenters To: Bill Moran Cc: Thomas Harold , Albe Laurenz , "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary=089e015375b014605704eeb04c1b X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org --089e015375b014605704eeb04c1b Content-Type: text/plain; charset=ISO-8859-1 > > What I don't see streaming working for is DR drills. I need to, in a > controlled manner, move the entire application to the secondary datacenter, > while keeping all the nodes in sync, make sure everything operates properly > from there (which means allowing database updates), then move it all back > to the primary datacenter, without losing sync on any slaves (this is a 2T > database, which I'm sure isn't the largest anyone has dealt with, but it > means that reseeding slaves is a multi-hour endeavour). With Slony, these > drills are easy: a single slonik command relocates the master to the DR > datacenter while keeping everything in sync, and when testing is complete, > another slonik command puts everything back the way it was, without any > data loss and with minimal chance for human error. I guess I got your point :) Agree to you now! :) With v9.3 I think I would be easy to swap the roles for primary and DR. (I need to test this before I can say for sure). But still it will be a pain if one needs to shift all the operations to DR (which is a a valid case, e.g. you would do that for testing the readiness of your DR site by doing a mock failover) and then shift back to Primary Site (assuming while operations were going on on DR site, primary site was kept down purposefully). This will involve taking a backup from DR to primary and then swapping the roles. I guess this limitation will be soon waived off. I guess v9.4 or next one should have this feature (no backups as long as your wal_keep_segment is high enough to cater to your testing/mock failover window). I agree slonik and few other utilities/tool around it administration/management is quite easy. If you feel that the current implementation of streaming replication is > able to do that task, then I'll have to move up my timetable to re-evaluate > it. It _has_ been a few versions since I've taken a good look at it. Given your expectation above, v9.3 is a good candidate. But you can afford to give it a miss. You must try once v9.4 is out. Regards Sameer Ashnik Pte. Ltd. Singapore --089e015375b014605704eeb04c1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What I don't see= streaming working for is DR drills. =A0I need to, in a
controlled manner, move the entire application = to the secondary datacenter,
while keeping a= ll the nodes in sync, make sure everything operates properly
from there (which means allowing database updat= es), then move it all back
to the primary da= tacenter, without losing sync on any slaves (this is a 2T
database, which I'm sure isn't the larg= est anyone has dealt with, but it
means that= reseeding slaves is a multi-hour endeavour). =A0With Slony, these
drills are easy: a single slonik command reloca= tes the master to the DR
datacenter while ke= eping everything in sync, and when testing is complete,
another slonik command puts everything back the= way it was, without any
data loss and with = minimal chance for human error.

I guess I got your point :)
Agree to you now! :)
With v9.3 I think I woul= d be easy to swap the roles for primary and DR. (I need to test this before= I can say for sure).

But still it wi= ll be a pain if one needs to shift all the operations to DR (which is a a v= alid case, e.g. you would do that for testing the readiness of your DR site= by doing a mock failover) and then shift back to Primary Site (assuming wh= ile operations were going on on DR site, primary site was kept down purpose= fully). This will involve taking a backup from DR to primary and then swapp= ing the roles.
I guess this limitation will be soon waived off. I= guess v9.4 or next one should have this feature (no backups as long as you= r wal_keep_segment is high enough to cater to your testing/mock failover wi= ndow).

I agree slonik = and few other utilities/tool around it administration/management is quite e= asy.=A0


If you feel that the current implementation of streami= ng replication is
able to do that task, then= I'll have to move up my timetable to re-evaluate
it. =A0It _has_ been a few versions since I'= ;ve taken a good look at it.

Given your expectation above, v9.3 is a = good candidate. But you can afford to give it a miss.
You must try once v9.4 is out.


Regards
Sa= meer
Ashnik Pte. Ltd.
Sin= gapore
--089e015375b014605704eeb04c1b--