Heine Ferreira wrote:
> Are there any best practices for avoiding database corruption?
First and foremost, do not turn off fsync or full_page_writes in your
configuration. After that the most common causes for database
corruption I've seen are bad RAM (ECC RAM is a requirement, not an
option for
On 10/18/2012 01:06 AM, Daniel Serodio wrote:
Craig Ringer wrote:
On 10/14/2012 05:53 AM, Heine Ferreira wrote:
Hi
Are there any best practices for avoiding database
corruption?
* Maintain rolling backups with proper ageing. For example, keep one a
day for the last 7 days, then one a week fo
Craig Ringer wrote:
On 10/14/2012 05:53 AM, Heine Ferreira wrote:
Hi
Are there any best practices for avoiding database
corruption?
* Maintain rolling backups with proper ageing. For example, keep one a
day for the last 7 days, then one a week for the last 4 weeks, then
one a month for the
Craig Ringer wrote:
On 10/14/2012 05:53 AM, Heine Ferreira wrote:
Hi
Are there any best practices for avoiding database
corruption?
* Maintain rolling backups with proper ageing. For example, keep one a
day for the last 7 days, then one a week for the last 4 weeks, then
one a month for the
On Sun, Oct 14, 2012 at 11:26:40AM +0800, Craig Ringer wrote:
> On 10/14/2012 11:00 AM, John R Pierce wrote:
> >On 10/13/12 7:13 PM, Craig Ringer wrote:
> >>
> >>* Use a good quality hardware RAID controller with a battery backup
> >>cache unit if you're using spinning disks in RAID. This is as muc
On 10/14/2012 12:02 PM, Chris Angelico wrote:
Is there an article somewhere about how best to do a plug-pull test?
Or is it as simple as "fire up pgbench, kill the power, bring things
back up, and see if anything isn't working"?
That's what I'd do and what I've always done in the past, but oth
On Sun, Oct 14, 2012 at 1:13 PM, Craig Ringer wrote:
> * Never, ever, ever use cheap SSDs. Use good quality hard drives or (after
> proper testing) high end SSDs. Read the SSD reviews periodically posted on
> this mailing list if considering using SSDs. Make sure the SSD has a
> supercapacitor or
On 10/14/2012 05:53 AM, Heine Ferreira wrote:
Hi
Are there any best practices for avoiding database
corruption?
I forgot to mention, you should also read:
http://www.postgresql.org/docs/current/static/wal-reliability.html
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-gene
On 10/14/2012 11:00 AM, John R Pierce wrote:
On 10/13/12 7:13 PM, Craig Ringer wrote:
* Use a good quality hardware RAID controller with a battery backup
cache unit if you're using spinning disks in RAID. This is as much for
performance as reliability; a BBU will make an immense difference to
d
On 10/13/12 7:13 PM, Craig Ringer wrote:
* Use a good quality hardware RAID controller with a battery backup
cache unit if you're using spinning disks in RAID. This is as much for
performance as reliability; a BBU will make an immense difference to
database performance.
a comment on this o
On 10/14/2012 05:53 AM, Heine Ferreira wrote:
Hi
Are there any best practices for avoiding database
corruption?
* Maintain rolling backups with proper ageing. For example, keep one a
day for the last 7 days, then one a week for the last 4 weeks, then one
a month for the rest of the year, the
On 10/13/12 3:04 PM, Leif Biberg Kristensen wrote:
Lørdag 13. oktober 2012 23.53.03 skrev Heine Ferreira :
>Hi
>
>Are there any best practices for avoiding database
>corruption?
In my experience, database corruption always comes down to flaky disk drives.
Keep your disks new and shiny eg. les
Lørdag 13. oktober 2012 23.53.03 skrev Heine Ferreira :
> Hi
>
> Are there any best practices for avoiding database
> corruption?
In my experience, database corruption always comes down to flaky disk drives.
Keep your disks new and shiny eg. less than 3 years, and go for some kind of
redundanc
Hi
Are there any best practices for avoiding database
corruption? I suppose the most obvious one is
to have a ups if it's a desktop machine.
How do you detect corruption in a Postgresql
database and are there any ways to fix it besides
restoring a backup?
Thanks
H.F.
14 matches
Mail list logo