From: | Steven Lembark <lembark(at)wrkhors(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | lembark(at)wrkhors(dot)com |
Subject: | Re: Basic Question on Point In Time Recovery |
Date: | 2015-03-13 20:03:38 |
Message-ID: | 20150313150338.1b73352c.lembark@wrkhors.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> The thing is you can use desktop class machines for the slave. If you do
> not have spare machines I would suggest a desktop class machine with big
> RAM and whatever disks you need for the DB plus an extra disk to pg_dump to
> ( so pg_dump does not compete with DB for the db disks, this really kills
> performance ). Replication slaves do not need that much RAM ( as the only
> query it is going to run is the pg_dump ones, but desktop ram is cheap ).
> We did this with a not so powerful desktop with an extra sata disk to store
> the pg_dumps and it worked really well, and we are presently using two
> servers, using one of the extra gigabit interfaces with a crossover cable
> for the replication connection plus an extra sata disk to make hourly
> pg_dumps and it works quite well.
If load on the backup server becomes an issue you might be able to
make incremental pg_dump's onto tmpfs. Advantage there is that the
dump iteslf has effectively no write I/O overhead: you can dump to
tmpfs and then [bg]zip to stable storage w/o beating up the disks,
which becomes a real problem with comodity-grade hardware.
--
Steven Lembark 3646 Flora Pl
Workhorse Computing St Louis, MO 63110
lembark(at)wrkhors(dot)com +1 888 359 3508
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-03-13 23:29:40 | Re: Regarding pg_stat_statements |
Previous Message | David G. Johnston | 2015-03-13 19:42:54 | Re: regclass and format('%I') |