Обсуждение: Move db files from one pgsql instance to another

Hi,

I am working right now in an strategy to improve the performance on my
server. The situation is this:

I have a very large database that it is only update once a month, but
when is updated I have to process a lot of things on the data to
create caches, aditional tables, etc.

The processing of the data can take up to 2 days in my machine so I
was considering the following strategy.

I have another machine that takes the new data, process it and when is
done I replace the files from the production server with the ones of
the processing server.

In this way I avoid my production server to become really slow for 2
days every month.

Does this sound reasonable? Am I going to find any trouble just moving
the db files inside the data/base folder? I thought I would stop
PostgreSQL, do the replacement of files, actually just changing a
symbolyc link, and start the server again. I will only have my db
stopped for 5 sec. once a month.

Has anybody experince on something like this?

Thanks in advance.

Javier.

On Wed, 2006-08-16 at 20:04 +0200, Javier de la Torre wrote:
> I am working right now in an strategy to improve the performance on my
> server. The situation is this:
>
> I have a very large database that it is only update once a month, but
> when is updated I have to process a lot of things on the data to
> create caches, aditional tables, etc.
>
> The processing of the data can take up to 2 days in my machine so I
> was considering the following strategy.
>
> I have another machine that takes the new data, process it and when is
> done I replace the files from the production server with the ones of
> the processing server.
>

Start out here:
http://www.postgresql.org/docs/8.1/static/backup-online.html

You might also look into Slony-I:
http://www.slony.info

Do those seem like they will solve your problem?

Regards,
    Jeff Davis

Yes!

Thanks. It pointed me out to File system level backup. And there I
found a very important hint... you have to restore the whole database
cluster. I suppose this means that I have to transfer all databases in
my postgresql...

What is actually a pity because there is a db on the production site
that will be lost... well, I can backup this one without ptoblems and
reinsert it after.

Thanks again.

Javier.



On 8/16/06, Jeff Davis <pgsql@j-davis.com> wrote:
> On Wed, 2006-08-16 at 20:04 +0200, Javier de la Torre wrote:
> > I am working right now in an strategy to improve the performance on my
> > server. The situation is this:
> >
> > I have a very large database that it is only update once a month, but
> > when is updated I have to process a lot of things on the data to
> > create caches, aditional tables, etc.
> >
> > The processing of the data can take up to 2 days in my machine so I
> > was considering the following strategy.
> >
> > I have another machine that takes the new data, process it and when is
> > done I replace the files from the production server with the ones of
> > the processing server.
> >
>
> Start out here:
> http://www.postgresql.org/docs/8.1/static/backup-online.html
>
> You might also look into Slony-I:
> http://www.slony.info
>
> Do those seem like they will solve your problem?
>
> Regards,
>         Jeff Davis
>
>

On Wed, 2006-08-16 at 20:37 +0200, Javier de la Torre wrote:
> Yes!
>
> Thanks. It pointed me out to File system level backup. And there I
> found a very important hint... you have to restore the whole database
> cluster. I suppose this means that I have to transfer all databases in
> my postgresql...
>
> What is actually a pity because there is a db on the production site
> that will be lost... well, I can backup this one without ptoblems and
> reinsert it after.

If you look at Slony, that's a table-level backup solution that may fit
your needs. Online backup and PITR operate on the entire database
cluster, but with Slony you can replicate on a per-table basis.

Regards,
    Jeff Davis