Re: Asynchronous commit | Transaction loss at server crash
От | Greg Smith |
---|---|
Тема | Re: Asynchronous commit | Transaction loss at server crash |
Дата | |
Msg-id | 4BF5B1E6.1020701@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Asynchronous commit | Transaction loss at server crash (Jesper Krogh <jesper@krogh.cc>) |
Ответы |
Re: Asynchronous commit | Transaction loss at server crash
Re: Asynchronous commit | Transaction loss at server crash |
Список | pgsql-admin |
Jesper Krogh wrote: > A Battery Backed raid controller is not that expensive. (in the range > of 1 or 2 SSD disks). > And it is (more or less) a silverbullet to the task you describe. Maybe even less; in order to get a SSD that's reliable at all in terms of good crash recovery, you have buy a fairly expensive one. Also, and this is really important, you really don't want to deploy onto a single SSD and put critical system files there. Their failure rates are not that low. You need to put them into a RAID-1 setup and budget for two of them, which brings you right back to Also, it's questionable whether a SSD is even going to be faster than standard disks for the sequential WAL writes anyway, once a non-volatile write cache is available. Sequential writes to SSD are the area where the gap in performance between them and spinning disks is the smallest. > Plugging your system (SSD's) with an UPS and trusting it fully > could solve most of the problems (running in writeback mode). UPS batteries fail, and people accidentally knock out over server power cords. It's a pretty bad server that can't survive someone tripping over the cord while it's busy, and that's the situation the "use a UPS" idea doesn't improve. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
В списке pgsql-admin по дате отправления: