Re: Asynchronous commit | Transaction loss at server crash
От | Jesper Krogh |
---|---|
Тема | Re: Asynchronous commit | Transaction loss at server crash |
Дата | |
Msg-id | 4BF59CAC.9040200@krogh.cc обсуждение исходный текст |
Ответ на | Re: Asynchronous commit | Transaction loss at server crash (Balkrishna Sharma <b_ki@hotmail.com>) |
Ответы |
Re: Asynchronous commit | Transaction loss at server crash
|
Список | pgsql-admin |
On 2010-05-20 22:26, Balkrishna Sharma wrote: > But if we have write-through setting, failure before the cache can write to disk will result in incomplete transaction(i.e. host will know that the transaction was incomplete). Right > > Two things I need for my system is:1. Unsuccessful transactions with a notification back that it is unsuccessful is okbut telling it is a successful transaction and not being able to write to database is not acceptable (ever).2. My writetime (random access time) should be as minimal as possible. > Can a SSD with write-thru cache achieve this > 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. SSD "might" solve the problem, but comes with a huge range of unknowns at the moment. * Wear over time. * Degraded performance in write-through mode. * Degrading peformance over time. * Writeback mode not robust to power-failures. Plugging your system (SSD's) with an UPS and trusting it fully could solve most of the problems (running in writeback mode). But compared in complexity, I would say that the Battery backed raid controller is way more easy to get right. ... if you had a huge dataset you were doing random reads into and couldn't beef your system with more memory(cheapy) SSD's might be a good solution for that. -- Jesper
В списке pgsql-admin по дате отправления: