Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 183342E00AF for ; Sun, 25 Nov 2007 14:18:11 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86616-03 for ; Sun, 25 Nov 2007 14:18:07 -0400 (AST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by postgresql.org (Postfix) with ESMTP id 7FE2D2E00BD for ; Sun, 25 Nov 2007 14:18:06 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id j3so787405ugf for ; Sun, 25 Nov 2007 10:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=JoSqAOvgjwakBWpOOfEy8r1nCBGufItsHBBCLfUkqfE=; b=aCcr2LXzbpd2FJoknrSkbInPg6p8lSTAohefKVc0dYZbQarUwfC9jLuGv0plVi1qVcZycm04b+sb7HZCXgh3Ed4LCKfsu/E500WM2HWGXDLbfLVWxoQhGmio0RRhTI0+NSuERE1Udg+FLEvrnmNZ/kzLlNwGzHuFrDq9Nyx8Qnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=BBc54Y4p/ErLDyDRxa/tJIUlMjcG0pDeZOIh9TJfDEe2Ka/Mn7n1pxJk+pocv+RQWuzT9LDdBINY1TJNz+scq9zG+m5KJpPnQ3hvn+CFbxyon1VvUTUDmOPBN9HHjk6Y6RXrpGlkBinsPAl39czywRzyPac0IZ5noFtJDQpAkyo= Received: by 10.67.116.9 with SMTP id t9mr3266133ugm.1196014685269; Sun, 25 Nov 2007 10:18:05 -0800 (PST) Received: from ?192.168.1.33? ( [86.31.61.208]) by mx.google.com with ESMTPS id u1sm1988260uge.2007.11.25.10.18.01 (version=SSLv3 cipher=RC4-MD5); Sun, 25 Nov 2007 10:18:04 -0800 (PST) Message-ID: <4749BC57.3030003@enterprisedb.com> Date: Sun, 25 Nov 2007 18:17:59 +0000 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.14pre (X11/20071020) MIME-Version: 1.0 To: Pablo Alcaraz CC: pgsql-performance@postgresql.org Subject: Re: doubt with pg_dump and high concurrent used databases References: <4749A6ED.2010005@laotraesquina.com.ar> In-Reply-To: <4749A6ED.2010005@laotraesquina.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/292 X-Sequence-Number: 27707 Pablo Alcaraz wrote: > I read that pg_dump can run while the database is being used and makes > "consistent backups". > > I have a huge and *heavy* selected, inserted and updated database. > Currently I have a cron task that disconnect the database users, make a > backup using pg_dump and put the database online again. The problem is, > now there are too much information and everyday the database store more > and more data, the backup process needs more and more time to run and I > am thinking about to do the backup using a process that let me to do it > with the minimal interruptions for the users. > > I do not need a last second backup. I could the a backup with "almost > all" the data but I need the information on it to be coherent. For > example, if the backup store information about an invoice it *must* to > store both header and items invoice information. I could live if the > backup does not store some invoices information when is ran, because > they ll be backuped the next time the backup process run. But I can not > store only a part of the invoices. That is I call a coherent backup. > > The best for me is that the cron tab does a concurrent backup with all > the information until the time it starts to run while the clients are > using the database. Example: if the cron launch the backup process at > 12:30 AM, the backup moust be builded with all the information *until* > 12:30AM. So if I need to restore it I get a database coherent with the > same information like it was at 12:30AM. it does not matter if the > process needs 4 hours to run. > > Does the pg_dump create this kind of "consistent backups"? Yes, pg_dump is exactly what you need. It will dump the contents of the database as they were when it started, regardless of how long it takes, and there's no need to shut down or disconnect concurrent users. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com