Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 76FFEB5DD47 for ; Wed, 21 Sep 2011 11:54:55 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 13089-01-2 for ; Wed, 21 Sep 2011 14:54:48 +0000 (UTC) X-Greylist: delayed 00:10:01.595885 by SQLgrey-1.8.0-rc2 Received: from exhub003-1.exch003intermedia.net (exhub003-1.exch003intermedia.net [207.5.74.28]) by mail.postgresql.org (Postfix) with ESMTP id 19FC2B5DCF4 for ; Wed, 21 Sep 2011 11:54:36 -0300 (ADT) Received: from EXVMBX003-1.exch003intermedia.net ([207.5.74.41]) by exhub003-1.exch003intermedia.net ([207.5.74.28]) with mapi; Wed, 21 Sep 2011 07:44:32 -0700 From: Linas Virbalas To: "pgsql-hackers@postgresql.org" CC: "daniel@heroku.com" Date: Wed, 21 Sep 2011 07:44:30 -0700 Subject: Hot Backup with rsync fails at pg_clog if under load Thread-Topic: Hot Backup with rsync fails at pg_clog if under load Thread-Index: Acx4bPgIHvDwd61hO0W6VLY00E7kvg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201109/1030 X-Sequence-Number: 195219 Hello, * Context * I'm observing problems with provisioning a standby from the master by following a basic and documented "Making a Base Backup" [1] procedure with rsync if, in the mean time, heavy load is applied on the master. After searching the archives, the only more discussed and similar issue I found hit was by Daniel Farina in a thread "hot backups: am I doing it wrong, or do we have a problem with pg_clog?" [2], but, it seems, the issue was discarded because of a non-standard backup procedure Deniel used. However, I'm observing the same error with a simple procedure, hence this message. * Details * Procedure: 1. Start load generator on the master (WAL archiving enabled). 2. Prepare a Streaming Replication standby (accepting WAL files too): 2.1. pg_switch_xlog() on the master; 2.2. pg_start_backup(Obackup_under_load=B9) on the master (this will take a while as master is loaded up); 2.3. rsync data/global/pg_control to the standby; 2.4. rsync all other data/ (without pg_xlog) to the standby; 2.5. pg_stop_backup() on the master; 2.6. Wait to receive all WAL files, generated during the backup, on the standby; 2.6. Start the standby PG instance. The last step will, usually, fail with a similar error: 2011-09-21 13:41:05 CEST LOG: database system was interrupted; last known up at 2011-09-21 13:40:50 CEST Restoring 00000014.history mv: cannot stat `/opt/PostgreSQL/9.1/archive/00000014.history': No such fil= e or directory Restoring 00000013.history 2011-09-21 13:41:05 CEST LOG: restored log file "00000013.history" from archive 2011-09-21 13:41:05 CEST LOG: entering standby mode Restoring 0000001300000006000000DC 2011-09-21 13:41:05 CEST LOG: restored log file "0000001300000006000000DC" from archive Restoring 0000001300000006000000DB 2011-09-21 13:41:05 CEST LOG: restored log file "0000001300000006000000DB" from archive 2011-09-21 13:41:05 CEST FATAL: could not access status of transaction 1188673 2011-09-21 13:41:05 CEST DETAIL: Could not read from file "pg_clog/0001" a= t offset 32768: Success. 2011-09-21 13:41:05 CEST LOG: startup process (PID 13819) exited with exit code 1 2011-09-21 13:41:05 CEST LOG: aborting startup due to startup process failure The procedure works very reliably if there is little or no load on the master, but fails very often with the pg_clog error when load generator (fe= w thousands of SELECTs, ~60 INSERTs, ~60 DELETEs and ~60 UPDATES per second) is started up. I assumed that a file system backup taken during pg_start_backup and pg_stop_backup is guaranteed to be consistent and that missing pieces will be taken from the WAL files, generated & shipped during the backup, but is it really? Is this procedure missing some steps? Or maybe this a known issue? Thank you, Linas [1] http://www.postgresql.org/docs/current/static/continuous-archiving.html [2] http://archives.postgresql.org/pgsql-hackers/2011-04/msg01132.php