> No, I had read some megacli related docs about SSD, and the advice was > to put writethrough on disks. (see > http://wiki.mikejung.biz/LSI#Configure_LSI_Card_for_SSD_RAID), last section. > Disks are already in "No Write Cache if Bad BBU" mode. (wrote on > splitted line on my extract) ==== The advice in that link is for maximum performance e.g. for fileservers where people are dumping documents, temporary working space, and so on. It is not advice for maximum performance of DB systems which have unique demands in terms of persistence of data writes. For postgres, if you use WT with SSDs that are not tested as having data-in-flight protection via capacitors, YOU WILL GET A CORRUPTED DB WITH WRITETHROUGH (the first time the power is cut). It is quite likely you will not be able to recover that DB, except from backups. Potentially, the consequences of corrupted data could affect your slave depending on which version of postgres you're using. Don't believe me? test it yourself with that diskchecker.pl program I linked on the other post. You will see the corruption happening to your data even when the disk assures you that it is safely stored. Do not use WT if you value your data or your uptime. It may still be acceptable to use writethrough if you can accept a DB becoming SILENTLY CORRUPT after a power cut reboot. In some use cases that's ok (we have a experimental machine with software raid0 that we just reclone occasionally from another machine, set for maximum performance, who cares if that db gets corrupt?). Also, relating to your problem. The issue of unexplained load spikes that don't go away, is something I've heard can happen with corrupt dbs. Can anyone else contribute anecdotes? So, I'm sorry to bring bad news, but there is a possibility your DB is already corrupt because of your previous use of WT. Graeme. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
