Re: Minimizing Recovery Time (wal replication)
От | Greg Smith |
---|---|
Тема | Re: Minimizing Recovery Time (wal replication) |
Дата | |
Msg-id | alpine.GSO.2.01.0904092005090.12261@westnet.com обсуждение исходный текст |
Ответ на | Re: Minimizing Recovery Time (wal replication) (Bryan Murphy <bmurphy1976@gmail.com>) |
Ответы |
Re: Minimizing Recovery Time (wal replication)
|
Список | pgsql-general |
On Thu, 9 Apr 2009, Bryan Murphy wrote: >> 1) Decrease the maximum possible segment backlog so you can never get this >> far behind > > I understand conceptually what you are saying, but I don't know how to > practically realize this. :) Do you mean lower checkpoint_segments? Theoretically, every time the archive_command writes a new segment out you can immediately move that to your standby, and setup the standby to regularly look for those and apply them as they come in. The fact that you're getting so many of them queued up suggests there's something in that path that isn't moving that pipeline along aggressively enough, without knowing more about what you're doing it's hard to say where that is. > It actually is an 8 drive raid 10, BUT, it's on virtualized > infrastructure up in Amazon's cloud running on 8 EBS volumes. I've > found performance to be... inconsistent at best. Yeah, EBS is not exactly a high-performance or predictable database storage solution, particularly when you get to where you're calling fsync a lot--which is exactly what is happening during the period you note your system is frozen. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-general по дате отправления: