Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Z0t3V-0004Yd-CM for pgsql-admin@arkaria.postgresql.org; Fri, 05 Jun 2015 14:57:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Z0t3U-00065k-7I for pgsql-admin@arkaria.postgresql.org; Fri, 05 Jun 2015 14:57:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Z0t3T-00065d-7a for pgsql-admin@postgresql.org; Fri, 05 Jun 2015 14:57:07 +0000 Received: from mailout.easymail.ca ([64.68.201.169]) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Z0t3P-0004Bv-84 for pgsql-admin@postgresql.org; Fri, 05 Jun 2015 14:57:06 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 4FE69E259; Fri, 5 Jun 2015 10:56:57 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.686, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692, FS_REPLICA=1.041] Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCffdXsN6J+F; Fri, 5 Jun 2015 10:56:56 -0400 (EDT) Received: from [192.168.2.16] (unknown [8.39.228.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id AE86BE25D; Fri, 5 Jun 2015 10:56:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: replication consistency checking From: Scott Ribe In-Reply-To: Date: Fri, 5 Jun 2015 08:56:54 -0600 Cc: hydra , pgsql-admin Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Igor Neyman X-Mailer: Apple Mail (2.2098) 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 Jun 5, 2015, at 8:42 AM, Igor Neyman wrote: >=20 > The problem I see with =E2=80=9Cchecksum utility=E2=80=9D is that for it = to work both compared servers should be =E2=80=9Cstatic=E2=80=9D: not tran= sactions while it does its job. Indeed, and that was brought up before and OP seems to be ignoring it. What= magic does MySQL (supposedly) use to compare databases without interfering= with updates? One could imagine a built-in feature in PG which depends on using MVCC and = having both sides look at the same snapshot. (Which would require repeatabl= e reads.) But for an external utility, that's quite a bit harder. One suggestion whic= h would involve minimal interruption to processing: if you have a snapshott= able file system, shut down master, take snapshot, shut down replica, bring= master back up, snapshot replica, bring it back up. You *still* have the i= ssue of making sure that at the moment you take master down all changes hav= e been streamed to replica, and the (easier) issue of making sure replica h= as applied them before taking its snapshot... But if you can manage to pull= that off, then you can checksum & compare as much as you want, *IF* you ca= n actually pull that off correctly ;-) --=20 Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice --=20 Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin